 Thanks everyone for joining, hope you're enjoying the conference so far, first couple of sessions starting now, I'm really excited. Here today we're going to talk about planning for Crap and entity revisions in core, and we're going to explain a little bit what this is, but more importantly we're going to focus on the planning part here today. A bit more on the agenda, so as I just said, we're going to talk a little bit about what and why we're interested in these things, we're going to talk about the status of some modules in contrib that are relevant to the solution, we're going to talk about a use case for this in core that perhaps could help drive this feature, the planning aspect of it as well and then hopefully at the end we can have a little bit of a discussion in Q&A. I really would like to leave some room for the discussion part at the end, I think that's important, especially this being a core conversation track, so at the end please feel free to step up to the mic in the middle and ask your questions or throw tomatoes. Okay, so first, who are we here on stage, my name is Dick Wilson, you can find me on Twitter, I'm a long time contributor in both core and contrib, I'm maintaining the UID module and deploy and currently working for Pfizer. And I'm Tim Mildred, I work for Atnovation and I'm one of the core maintainers of the statistics module. So what and why, what are we talking about here today, a brief background, so Crap is an acronym and it stands for create, read, archive and purge, as opposed to what many people are used to called CRUD, create, read, update, delete. This is an alternative way to look at storing data. For more detail, technical details, have a look at the Amsterdam session and the LA core conversation, we're not going to dive very deep into the technical details there because we've been over that before, but we're going to briefly go through it just to make sure that everyone is up to speed here. So basically what we're looking for here is to enable revisions for all content entity types in core, so things like nodes, nodes already have revisions, right, but we want to introduce it for terms, block content, users, files, basically every content entity type that we have in core. The create and read aspect of the storage model will be very much the same. We're introducing the archive aspect of it, which is a new revision that we mark as deleted. So what you previously would think about as the delete operation is a new revision that we just archive away. And then we introduce another concept called perch that actually empties the database if so needed. Obviously the space will grow having revisions for everything in core, so there's also a concept called compaction that would remove old or unnecessary data. This particular compaction concept is not introduced in the contrib modules yet, we're still working around the details on that, but that's in essence what we're talking about here today. Revisions for all content entity types. So why do we need this? Well without revisions content can only exist or not exist. You kind of lose the sort of aspect, the content management aspect in a CMS or a content management framework if you want, whatever you want to call it. If it's one thing that we should do right as a CMS or a CMF, it's content and it's storage model. And we really sort of lose the content management part of it if we don't have revisions. Revisions obviously improves the user experience. If you make a change, you did the wrong change, you want to roll back, you want to revert, today that's not possible. You lose your changes if you want to change a block content for instance. Revisions is also the common denominator for many use cases, workflows, I think workbench moderation in Drupal 7, synchronous editing for legal reasons. You might need to provide an audit trail. There are ISO standards that require you to provide full logs of all the changes. Content staging, sharing content across network, this all requires revisions in order to handle things like conflicts and so on. So it does make sense to have a solid API for this and core to support all of these use cases. Traditionally we haven't really implemented things in core without a use case. We're going to talk about a concrete use case in core as well because we don't just want to introduce this new thing or change everything for no reason in core, we want to have a use case as well. But first before we cover that, just a quick note on the status of this in Contrib. So we're working on this very solution in a module called multiversion which enables revisions for all content entity types, it also enables this crap storage way of thinking. So deletes actually is a new revision, a new flag revision. Then we also have the relaxed web services module that extends the REST module in core and exposes this full data model over REST including with revisions. And it follows a standard API spec that is compatible with other software libraries and projects out there, such as Hoody or Pouch2D. Which opens up a whole other use case that we're not going to cover here today, but that's just an interesting note there. So how could we make use of this in core? What could be a driver to introduce some of these concepts into core? And what we're going to introduce here is perhaps one of the oldest concepts of computer systems or file and content systems. And in 1984 it looked something like this. It's not the guided tour. We actually have that in Drupal 8 now, 30 years later. But it's a trash bin or a recycle bin. One of the most basic concepts that exists in every desktop computer that you use. Existed since 1984 in Mac as we saw on the other slide. Windows had it since 1995. WordPress and Joomla has had it since, I think WordPress had it since 2008. Joomla I think was even earlier. It's a concept that people are very, very used to. So this could be a driver for us. We need somewhere to put our crap, pardon the pun. So I'll hand over and Tim will introduce the trash model and how this is relevant to what we're talking about. So the trash module is basically just a UI for the multi-vision because as it was saying we're just flagging content as deleted. All the trash module does is show that content, allow you to see what's in your trash. This works on all content entities. So whether it's a taxonomy term or a block or a node, whatever, you can get them in your trash. And we can then restore content entities. So these get put back exactly as they were with all their revisions. You can bring back nodes, bring back the comments, four nodes. Then you can also purge the trash. So completely removing any existence of the content entity. And this allows us to do this workflow and probably stage the content. So I think it's time for a quick demo. So yeah, just deleted foobar 11. So that was a node. It's now been flagged as deleted. And we can go to the trash. You've got all the different trash bins for the different entity types. And there's foobar 11 in the trash. You can then go back to the content. And we've got another node here. We'll see that this node has got a comment. And we can delete the comment. So we've now got a comment that's moved to the trash. And we can go ahead and delete the node as well that used to have that comment. So now we've got all these node entities within the trash. We can go ahead and restore one of those. And that will bring back the node in its entirety. And then we can also restore the comment related to that. And we'll go back to the home page and we see the nodes back just as it was before. We've got the comment and exactly as it was in the first place. So we're not just doing this on comments and nodes. We're also doing it on taxonomy terms. So we can go into our tag list and we're able to just delete a node. I have to delete a tag. And you'll notice when they delete, you don't get any confirmation. We don't need that anymore. They're just gone. We remove that step and they just go straight into your trash. So we can now purge items from the trash. And this will remove them just like the old delete removed them. We give quite a big warning there because of the replication issues. If you have your data replicated on another machine and you replicate it back. So this one you may get your deleted content back and you may get other sort of issues if the content has been purged. So they would just purged a node as well. So that's the demo on the trash module. So just looking at then how do we get this final goal of moving some of this stuff into core. And there's a great quote here. And what it's talking about is just sort of looking at what we've got at the moment. What we have sort of taking stock of that and moving forward. And we've already got revisions in core the moment. So we're looking to enable them by default. And if we can do that in 8.0 that'd be great. If there's any core committers then we could do with this patch here getting committed. And then we'd have revisions on by default. And this patch enables revisions for the standard article and page node types that you already have when you install a D8 site. And then it also enables it by default when you create a new node type as well. So then moving on to 8.1. We can start looking at adding some of the other items in as well. We can look at improving the performance of revisions. And a lot of the stuff in multi-vision will help move that forward. And we're looking to add revisions to all content entity types. So as you saw in the demo, we've got not just nodes that are revisions. We've got all these different content entity types. We'll need to add a revision hash, a parent and a tree to give the full spectrum of the revision. And we can start looking at the data migration as well. Because the existing content that you'd have in your 8.0 site will need to be moved over to this new model. And there's just a note here that none of these require API changes. It's all just sort of data changes. So it should be a fairly straightforward process. And another note here is that the revision API that we have in core already supports this perfectly fine. We have a very, very nice generic revision API in core. And we can just enable it for additional content entity types. And I think as a content management system that makes sense. To have in core. So again, to the north down below, it's not really an API change. Because these are things that we already have in core, but we're not using. So moving on to 8.2. I think the top point here is quite a big one. And removing the ability to not have a revision. So every content entity is revisioned and you can't turn that off. It's not optional. Just everything is revisioned. Then we can start looking at putting this delete flag in and making a delete a new revision. We can look at adding purging in. Because obviously you may accidentally create a new item of content and you may need to purge it. And then we can look at adding the trash module in. As I said earlier, the trash module is very much just a UI for all of this stuff. So we're thinking the trash module will stay a separate module. And all of the stuff that is now the multi-vision won't be a module in core. It will just be the revision system and will go straight into the entity API. So, I don't know, summarize. Thanks. So to quickly summarize what we talked about. What we're looking to do here is not necessarily only to introduce a trash module into core, right? We're doing this fundamentally to improve our content management abilities. The trash module would just be a driver, an additional feature that sort of would demonstrate part of these abilities to use it as a concrete example. By doing so, we're improving user experience. Content editors, they do expect to be able to work with revisions. I believe that the trash module can improve some user experience too in terms of the confidence in dealing with Drupal. And then with these underlying changes, we do get a comments very solid revision API for all these other use cases that we've discussed. Workflows, content staging, content sharing, synchronous editing. Lots of exciting use cases. So that's a quick summary what we talked about today. And I hope there are great questions or concerns or simply discussion. Thank you. I have a few questions. I saw there was a different interface in the administration of trash. I haven't seen any multi-selects. Is it a choice? Is it not finished? Why have a different interface there than the standard content management? So to the point, is it not finished? Yes, it's not finished. It's going to be a sort of ever-evolving thing. And there is a standard table that we could use in Core, but because we're looking at deleted entities rather than proper entities, it's a little bit more complex. So when this does go into Core, we could possibly look at patching the way these pages are generated. My use case would be to purge all entities or all content nodes from a certain age, older than a month, whatever, manually. Things like that. Currently in 7, there's nothing like... There's no interface, anything for purging old revisions. And from there, there's often a request to be able to purge them. And I haven't seen it yet in the interface. So the trash module itself just looks at the entity as a whole and you can't, at the moment, delete revisions from within an entity via the trash module. It just will purge the whole entity. Ah. And to Tim's earlier point there, look at this as a proof of concept. It's by no means the end of the... Tell me also just a point of discussion. It's not a hard remount and I can't put any money on it either. Some other questions. Why do you want it in Core? Why not live happily ever after in Contrib? It can definitely live in Contrib. I think that... So trash module would be a driver for, you know, would be a service and example as we covered. But the efficient part of it is needed for so many other things as well. And I really do believe that something like a trash module even, you know, it brings a lot of value, I think, to a content management system. It hasn't really been possible to do it in an efficient way. There has been a module for Drupal 5, Drupal 6, Drupal 7, but it's not really worked. And people have sort of given up on it a little bit. But they have it in all other content management systems, WordPress, Joomla, there's in desktop. So I think it's generally a good thing for CMS to have something like this. And then, you know, at the same time, we can cater for all these other use cases as well. So I think it makes sense to have it in Core for a product like Drupal. Okay. And in the same direction, one of the notes was, I think, in Phase 2, that you don't want to be able to have revisions. Why not have revisions? Isn't that an assumption that everyone has a large site and everyone wants to, don't want to delete their content? I think it's just similar to everyone needs a menu. No, that's not every content type needs a menu. No, I think dealing with content, I think there are certain expectations that people expect from a content management system. And that to the user experience part, I think there is an expectation there. And then to sort of the underlying pieces to the APIs, there are great simplifications that we can do to the API if we assume that we do revisions by default always, because at the moment there's lots of conditional logic for entities without revisions, entities with revisions, entities with multilingual with revisions, entities with multilingual without revisions. We have all of these various different storage models. There's a lot of complex code in our schema handlers and our storage handlers. It could also simplify a lot of logic without necessarily bringing any big performance implications or things like this. So I think there are certainly some cons to it. We do build in an assumption, but I think it might be worth the trade-off there. It's definitely a great point of discussion to carry on. You say it's good for user experience, but on the other hand you're adding more complexity to the interface because there's logic and there's an interface for the revisions, etc. So it's a good point. Both also user experience has pros and cons. Yeah. Thank you. So, casually, my first remark or question was related to this part. Actually, I'm not sure I saw it right because it was very quick, but I noticed that when deleting an entity, as you mentioned, there was no confirmation and there was just a message on top. Now, I'm seeing very infrequently in the APIs that such notification messages often feature a link to river depth operation. And I think that could be a great UX improvement that would address Starson's concerns because it would be very easy to undo that. Very good suggestion. Yeah. Aside from that, I was wondering, just from the technical point of view, which kind of strategy did you use to replace confirmation form and actually get rid of them? You don't want to know. Okay. I suspect there was something like that going on. Okay. So, do you think we should, the horrible hack that's behind that should be a driver for doing something better in core to allow that or there's no clear solution that's allowed to do that in a better way? If we look at putting the entity revisions into core, then we're not going to need these confirmation messages because you can just restore the content and the suggestion you made with the message is a great one. And other than that, I don't see a big driver towards removing the confirmation messages. I don't think a contract module, for example, should be able to remove these contracts. Okay, so actually, I guess it was a bit more general because I guess you somehow overridden the content entity forms. I did a root subscriber to override the root. Okay. And all the forms have a similar root name with the entity name in it. So it just looks at the entity and overrides that. And then just sends it to a new controller. So instead of calling the form, it calls the controller as a delete. Okay. Fair enough. And building this into core, obviously, we can streamline that assumption, right? Yes. And last question, I guess, sorry, I shouldn't guess. I was wondering whether you took a multilingual into account when I guess since this is still work in progress, this was not a priority, right? Right. For the trash itself, there was no multilingual taken into account, but for multi-vision. Yeah, multi-version supports revisions exactly the same way that core does for multilingual entities with revisions. So there's no real change there. Yeah. So multilingual is supported from that perspective. To your point, it might be a very good idea to look at providing perhaps a user interface to archive or trash translations individually. Yeah. Because we already have a couple of open issues about improving the UX around that area in core. So I was supposing that it wasn't easy that a contrib module still work in progress was already in doing what core is not doing actually. That's a great suggestion. Okay. Thank you. You said something about that you did compacting to avoid old revisions taking up too much space. What exactly are you doing there? So the concept hasn't been implemented yet. We're still thinking about good ways of doing it. There are several different strategies that you could use. It probably makes sense to make that pluggable. There are other systems that have very similar revision storage solutions. They provide an option that compact or remove revisions that's older than just keep the 10 last revisions essentially. You could do things like compact or remove every fourth revision that is older than something. However, what's needed here in order to take benefit of this crap storage methodology is actually to keep some trivial metadata still about every revision. So that you still have a revision tree so that when revisions come from other sources either being replicated from a network sharing site or from a editorial staging environment. We can actually see where revisions come from. We have a revision tree and you can do things like conflict detection and so on. So there needs to be some basic metadata still even after the compaction state. So this is still something that we're solving in the contrib solution. Have you considered looking into more like a storage model? No, not necessarily using it. But the thing is that when you make revisions in Git it actually only stores the changes between the two whereas Drupal currently stores the full copy of the full text for each revision. The storage model that we're using is similar to Git in the sense that we're treating so everything has a parent very much like Git and you could actually build revision branches or trees. So that's very similar to your point with the differences. We have thought about it. It would require some quite significant changes to the entity API and how we load and, you know, content. We took the easy way out this time. But it might be worth considering. Hiya. So I've got a question about the UI of Trash and it goes back to where we saw that the trash can has been around for a long time on the desktop. So but having your trash bins is a bit of a departure from one trash can that has everything in it. If I throw out a movie and a folder and a Word document, they all end up in the same trash. I want to take a guess that those are built with views or no, no, no, they're not used. They probably will be right. But we also need to cater for the people that have views installed. So that was the first step of non views version. Right. Okay. So I think my question is then is it going to be possible to have a sort of unified trash bin so that people won't need to know whether something was a node or a block. When they go and try and find it. The issue is that there isn't a good way in the entity query to query multiple entities. Right. Multiple entities, yeah. Yeah. So yeah, we pretty much have to split them out. And the other issue is that each entity is slightly different. So for example on a taxonomy term, you don't have a created date and on a node you do. So yeah, we need to cater for those kind of use cases as well. But it's something to look at and iterate on. Okay. Thanks. Yeah, I have a question regarding the revision and the revision tree. You said today they can come from different places, but they could also come from like a workflow on the same site. So like different people having making different divisions with the same parent. What about the merging these revisions back together or like say someone edits the title and someone edits the tag and then you want to have both of them and not select. One that wins, let's say. So merging is a very, very complex topic. So what we've done at the moment is that we have the ability to detect where you have conflicts. And we are looking at ways to make a merge or conflict resolution API plugable so that you could pick and choose different merging strategy because every company, every site, every organization is going to want to have it different. So, you know, providing a plugability there is probably a good idea. You could then write a plug-in that uses the Git merge algorithm. You could use a lot simpler merging algorithms too. I don't think that there's one solution there, but certainly making it plugable and it's certainly something that needs to make it in to the module. It's certainly in contrib, perhaps not in core. The plugability is of course a very good solution, but the first step to be even able to do that is to have several parents. You have the revision parent, but you need to also have several to graph the tree then. Because if you merge two revisions, then you need to know that you did that. Otherwise, you have a new one and you base it off either one. Yeah, so I think a merge should always be a new revision. Of course, of course. Very much like the Git does it, and that's certainly supported. So you can have a revision with several parents? A revision can have, so your merge fix would be a child of a parent, and that parent will have multiple shades, some of them being conflicts and another one being the solution. So I'm not sure you need multiple parents because a parent will have multiple children instead. I think that's what needed. I'm not sure I follow your reasoning. No, because if you have several parents and then you only branch the trees, and then the way you select the version that's the one that wins, you go along this tree and then you say, okay, this one is the newest and this one follows the other newest. And so if you make a new revision in one of the branches, and then the other revision can still win, you need to be able to resolve the tree in the same way Git basically does when you make a merge commit that has several other parent. I see, yeah. It's a good point. I think, yeah, let's sit down and discuss it. I'm not familiar enough with all the technical things. So mentioned earlier, merging and conflict resolution is a very complex topic. So I think it definitely needs more thought. I think it's great points that you're bringing up, so let's discuss it for sure. So are there any considerations to have around references, like entity reference, when you say you delete a node that has references or the other way around, or when you purge a reference, is there anything special that you have to think about here in your particular use case or does it work the same? So we haven't changed anything of how it currently works in core in that aspect. So I don't believe core cleans up, if there's a reference to a deleted entity, core doesn't do any cleaning up there, and we have not changed that. And we have not had to change that either. At least we haven't run into a use case yet. There might be some, and then we definitely need to tackle it. Probably what's needed, just as a related thing here, probably what's needed along with a more elaborate revision API is also having the ability to reference certain revisions. Because at the moment when you put in an entity reference, you're only referencing a default revision to an entity. We probably need the support to reference certain revisions. Group entities into the same revision. Like a field collection, for example, is a good use case or paragraphs, where if you make a change to a node, you probably want to keep the revision of that reference together because you were looking at it the same form. That in particular is not something that we've looked at yet. I do think we definitely need to think harder about how we do revisions because when we're more elaborate with this, these use cases are exactly going to come up. So we need solutions for them for sure. And I think that there are working contrib to look at this. I think, Andre, you've been working on references to revisions, is that true? Or am I getting that wrong? Okay, so there is working contrib to start exploring these things. I think it needs more exploration for sure. I was wondering, do you support contrib entities out of the box, or do you have the contrib modules need to do something, or how is that? You were talking about core entities, but if you're looking at commerce, commerce and all the thrill on order can be really good, but does it come out of the box or should it be in commerce or should it be in your module? So the way that it currently works is that we iterate over all content entity types and we enable revisions for it. So this would include even contrib entity types. It works great in core. The entity API and the revision API has perfect support for switching around the storage handlers. Multiversion needs to provide the sort of migration part of it, the data migration. So we still need to explore how this actually will work with contrib. We need to do more testing there, and perhaps have test cases in the contrib multiversion module where we actually test this properly. Because it's a little bit unknown how the quality of contrib, how that will work and what the impact will be. If there are built-in assumptions that there shouldn't be revisions for some reason, that could certainly be problematic. So as Drupal 8 adoption grows, I think that we need to explore this and we need to learn this as we go. Another question was how about the security? Normally something is deleted. You know for sure it doesn't show up on the website. How you make sure a deleted content is not shown to a user? So it's actually quite trivial to make sure that a archived or deleted entity is not loaded. Because what we do is that we change the storage handler, and the storage handler has full power of how entities are loaded or shown. So at the moment all core tests actually pass with these changes made. So we don't see any security concerns at the moment. There are however security concerns in regards to how you use the functionality. So deleting or purging an entity in one environment, if you purge completely remove it from your site, let's say stage one, let's say that you have multiple stage environments at the total stage environment. If you purge an entity from stage one, that deletion will not be propagated. So if you have legal issues with something or security issues with Node, you need to actually make sure that you only delete it or archive it so that that can propagate through your environments. Because if you purge it, that will not propagate if you do a replication. So there are some educations to be done to use this in a multi-environment situation. This is one of the use cases where it actually will be used for. So we need to take that into consideration. Thank you. More questions? What do you see as the risks and the challenges of getting this on the core? There's a pretty obvious use case. So to repeat the question, what do you see as the risks and the challenges to get this into core? Obviously getting the challenge to start with that is obviously to get people's buy-in. That revisions is something that we need as a content management system. And that's going to be a big challenge. Even turning on revisions for nodes by default have spurred quite a big tree of discussions. So that's going to be a big challenge getting people to align around this. Risks? Obviously we don't want to build in assumptions. Too many assumptions into core. There's a risk there that we build in too many assumptions for sure. There was a question early on raised around that. That's definitely a risk. It might turn out to be the wrong assumptions down the line. So that's definitely a risk. And this is something that we need to iterate on and discuss and make sure that we do take the right decisions. I'm not sure if that answers your question, but that's my take on it, I think. Hi guys. It looks brilliant. Just in terms of the naming being used to say as a content strategist I'll write a blog post later on and say a group later is full of crap. And that's going to be nice and funny. It gets tweets. As a business development officer next week I'm going to write a tender proposal for a government contract. And I don't want to say a group later is full of crap. So what's the nice name, let's say? Are we talking trash? Are we talking crap? Are we talking multi-version? What's the business name, let's say? I think when... Congratulations. Thanks. A very good point and a valid concern for sure. I think that when it makes into core it will be an elaborate revision API. So I think that perhaps we should talk about it as a more elaborate, a more fully featured revision API, simply. I think that the trash terminology exists almost everywhere. It exists in your desktop computers. Sure, Windows names it a recycle bin. Perhaps, what? In your discussion about it. Oh really? Okay. And both WordPress and Joomla uses the trash name for the trash bin. I think to your point crap is probably something we should just call it an elaborate revision API once it gets into core. So a question about the complete purging of entities you were mentioning earlier. So if I understood it right a full purge won't be propagated through systems, right? A purge will not be propagated because then the entity is gone and there's nothing that you can propagate. So a delete or what we should call an archive perhaps that will be able to propagate because that's just a new revision that you propagate through your editorial environments or your staging environments or your multiple production environments. What it might be. Okay, so my question was, was this a technical limitation that you hit or was it made on purpose? I'd say it's definitely made on purpose. Okay. There are definitely use cases for purging. Let's say in your, if you play around in the staging environment and you do some hello world testing things, you do want to purge that, you do want that to be gone forever because it's just testing. So it's a conscious decision. Okay, because I was wondering, you can always, to take your example, you can always not migrate a deletion for an entity, a test entity that is not available in the production environment but what I was wondering, would it make sense to have a final delete purged revision that once propagated fully deletes the entity in the other environment and maybe deletes the entity also in the environment being migrated? I think that's a very good point and it would address some of the security implications of if you have something that needs to be taken away for security reasons or something like this, you want to have a way to be able to securely purge across your whole network or your whole array of staging environments, for instance. So that's a very good feature. Whether it lives in core or in contrib, not sure, but it's a very good point actually and probably something. Yeah, so the way that we have it at the moment is that the replication process is a separate Drush command so you would need to set up your business logic or do your replication, how you choose the environments by default they actually don't know about each other. Yeah, it could automatically sort of propagate. That is a problem indeed. Another question? Yeah, it's a question. Something occurred to me when we talked about the entity references in the earlier question and so I'm going to ask is it possible or do you envisage having a way to customize or respect constraints that are in the content model? So let's say you've got some kind of reference, it could be node references, a user or something like that but you have a mandatory required entity reference and then somebody comes along and tries to delete something which is required. It's kind of a dependency in your content model. Would you say no that can't be deleted because some other entity has it as a mandatory reference or would you permit that and then sort of make it what would happen to the entity which has now lost its mandatory reference? How would it be indicated there? Any thoughts on that? I think it depends hugely on specific circumstances around the use case. It's certainly possible to implement those types of restrictions. There are multiple entry points where you could go in and alter and do that whether it belongs in core or not, not sure. My thoughts of it in general sounds like something useful. I can see that you have the situation where you do have dependencies and you want to implement those constraints. I think I'd need to discuss it in more detail to understand exactly why or how things would work around it to answer that question fully. Okay, thanks. Related, would you see this as being part of the revision API or would it be farmed out to another system like rules? It sounds like a quite specific use case so I would probably say they would be farmed out to some sort of contrib module. Okay. Thanks. Can you use the microphone to record it? I work with Andrew so I'll back him up. I wouldn't consider it a very specific use case because I think everyone of us has a website that says, here's our clients and every client has a reference. Here's a portfolio piece I've done from that and that's probably 100% of the people in the room and I think it's a use case that certainly will need to be solved probably sooner rather than later. What is the... My rule. That's more a question back to you. What would be the Drupal 7 solution? What's the current solution and can we still use that maybe simpler solution in 8.2? It's like tennis. There's no Drupal 7 solution. If I delete a portfolio page and I've got a client page and every portfolio must have a client attached to it because we built that website for some client, it allows me to delete a client or the portfolio and nothing breaks but it just means my content model isn't satisfied but it still works. It's a very good point. Bringing up that concrete use case it makes a lot of sense to me. Yeah, it makes a lot of sense and there are definitely ways to implement that and I think it's a discussion point that we should have as a community to say as part of this phase to get this piece into core what are the exact scopes that we should be tackling? Yeah, I think it requires more discussion I think but it's a very concrete and good use case there actually. Another question? Just one. A lot of your challenges for the future seem to have to do with content entities that reference versions of other content entities and if we delete this why it references that, what happens and all that kind of stuff. Have you looked at seeing if the content entity reference module could be expanded to handle a lot of these use cases? Because that's really what it's built for except it doesn't handle versions yet. I'm not familiar with the model. It says that you have any reference from content A to content B and whenever you change something content A B has to be updated and vice versa. It helps you manage those relationships and if it was expanded to handle your versions of content it sounds like it would help a lot of use cases. Yeah, if these things or I would say regardless of these things get into core or not, if they live in contrib either way I think that would be good additions to that particular module to make use of the full spectrum of functionality in the revision API. It's a good point, we should take note of that and make sure that that happens. Okay, we're slowly running out of time actually. Thanks for all your great questions and enjoy DrupalCon.