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.  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.  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.


So, here's the difference between the old Rife Machine and the new Rife Machine. The crazy leap from the huge old school machine to sleek pocket sized gadgets. These old Rife Machines were no joke, you would see these huge gadgets. And it was quite stressful to use, you have to dial in the frequencies one at a time, you'd have to stand there, turning knobs to get the right frequency. Say you're trying to tackle something specific, let's say intestinal inflammation or for diabetes or something, you'd need like 10 frequencies. So, you'd have to start flipping switches, dialing in one frequency at a time, and then just sitting there for a few minutes before you have to do it all over again for the next one. It literally takes a lot of manual operation and to learn how to use it. So, here's what I did. I've been developing software for a few years now and one day it just hit me. I thought, why not make this whole thing a lot simpler for people? Why don't I just make a software and make it easy for people to get this therapy wherever they are?


What's up everybody Jason from jazby's casebase.com. So we sold out the first filler guys for picketing number 11 of one football this filler Rnb style serial number break includes the Patriots Jaguars 49ers Colts Giants commanders Now we only sold nine spots if you bought a full spot in this break You will have a chance to win a free spot. We actually didn't have to sell any fillers Everybody bottom straight up a little pricey guys, but a lot of great teams You can potentially pull out of here, especially the big quarterback teams So Carl Carl James Logan mark Carl chat and Brian. Thank you guys for buying in straight up So with the same dice roller here, we're gonna use to randomize the customer names number one gets a free full spot We're gonna paste your guys's names here and then randomize the customer names and numbers for the Rnb We still have to sell out one more random number blog that's on the website That's down to three left, which I'm pretty sure we will tonight. So that would sell it out Here's a dice roll is roll It is a three and a man throw a lot of sevens today Three and a four seven times. Good luck customer number one gets a free full spot one two three four five six seven and Boom Carl at the top. So there you go three and a four seven times top three, but all you need it is one So let's paste your name here. I'm gonna put a little character sign there letting you know that you got that as a free spot and Here we go seven times down the names and numbers one two three four five six seven Chad down a Brian crouch. I Don't honestly. I don't really play table games. I'll be honest. I'm a little shy guy like I really don't I Just I have to go with someone that does it to get me into it You know anytime I've ever gone to the casino at family. They're just more of a let's just drink and and Some of them gamble some of them don't but my mom's just straight-up slot machine So I didn't really get to experience tables, but maybe at the national this year one of you guys can just take me Throw me to the wolves All right, so seven times there. Let's paste in the names. There we go and seven times here one two three four five six seven Bow Six down a nine So Chad it was about six Logan any and all redemptions would be yours for these teams Of course mark with three car with two and four for two James was seven car with five One any one of ones and eight and then Brian crouch with nine So there you go guys with this so one more R&B out which I'm pretty sure we will later tonight But again, thank you guys for filling this. Good luck to everybody You get a piece of all these teams in the breakdown and thank you guys appreciate it You


Hi, welcome to CCTV channel 17 live 525 the preservation Burlington show preservation Burlington is a Non-profit 501c3 organization whose mission is to preserve and protect the historic architecture and livability of Burlington It's a it's a big task And we do that through education and advocacy. I would like to thank everybody for tuning in this month We have a pretty great show lined up and we'll introduce our guests in about a second Do we have any upcoming events or anything that we want to talk about? Yeah, we had Well, we had a lovely tour earlier this week was it last week. I can't remember a blur It's a but actually it was on Monday So Champlain not Champlain st. Michael's College has an advanced history class you and Ryan did that Ryan and Krista came out And we led them up church treated a little tour And it was really great and one thing that came out and what just occurred to me as you were reading What we are is we are an all-volunteer board an organization. There is no paid person behind us and the students were really Marvelling at that like everything that we do we're all volunteer and so I think you know, we need to recognize that from time to time Yeah, remind ourselves and we feel like we're dropping the ball or something Yeah, so we did that that was a really great tour and just just before I came out got some great feedback on that And then last night Karen did the webinar on historic architecture of Burlington neighborhood by neighborhood I'm I unfortunately couldn't see it. I don't think you you were able to attend to but hopefully it was recorded and the replay will be Yeah, we'll put that back on the website. Yeah, sure. We did last time. She did one. So and it was well attended last time. I think 40 people or something for you uppers of 40 almost 50 people last time It's pretty yeah, it's pretty fun when we get pull those things together, you know, I'll keep people engaged that way You know, I'm still not very tech savvy. So I'm not when it's webinars I've never been I tried to you know all through not to bring up the pandemic or anything But you know when we're doing everything from remotely from home. I signed up for all these webinars. I swear I didn't do any of them. Okay, I couldn't Talk about the beautiful thing on your leg. Well, this is hiding the hole in my knees But yeah, this was in our newsletter. Yes, right Last month well not month this winter. Yeah, there's the winter newsletter and it's also I think up on our website. So people are What do they call it a raffle? We're having a raffle for this beautiful quilt by Mary Ann Koch And it is going to be a wonderful fundraiser for us. We are taking Or selling raffle tickets. Mm-hmm one ticket for five bucks six for 25 And I believe we're going to raffle it off at our home store in June and she's like the head of the quilters will Guild guild Neither of us can talk today. I know And she does this a lot. She does these makes these beautiful quilts to raffle off and help Organizations and causes she believes in and supports and raise funds. So we are really grateful to her Yeah, it was very generous of her to donate this for that. It's beautiful. It really is So let's get on what we've got one thing before we introduce our guest, right? Which is what is on your preservation bookshelf? Oh the bookshelf segment the bookshelf segment Do you want to go first whip right there? Well, I bought One of we'll motor right through this. It's a great book. It's called where we lift it is a national historic trust Publication it's by Jack Larkin and it's discovering the places we once called home the American home from 1775 to 1880 it's beautiful storytelling and illustrations You know black-and-white photographs, but it really tells the story of early America Why people built what they did where they did and how they lived in their homes and sort of helps explain Some of the features and architectural styles that we see In that early American period. So it's a beautiful book. I highly recommend this jealous. I don't have that one I think I yeah, I'll write my name in it. You can borrow it So anyway just quickly because especially because we're in the midst of a big zoning ordinance Consideration right now and a change where we're increasing density and you know as a present as preservationist We're all for infill housing and but you know again. It just gets says in our Livability of Burlington. It's all about community and sense of place and stuff like that So it's gonna be a huge topic coming up in the next few months in the next year so I brought Sustainable preservation, which is Jean Karoon who's an architect for goody Clancy in Boston and yep It's a big name and they've done a bunch of projects again Perry Hall for Champlain College was the one where I met her and it's cited in this book because it's a lead platinum project and it's really all about just reiterating and hammering home the fact that the Greenest building the greenest building is one that's already there and and all those other sort of you know Maybe cliches at this point, but we always forget you know as we let things like Memorial auditorium slip through our fingers or The 20 pine Street the Cathedral Immaculate Conception, you know these are our architectural gems And I think as a community. We're not embracing enough that preservation is sustainable and Possible and and realistic very very possible. Yeah. So anyway, that's a good one to put on your bookshelf and So maybe I'll take the wrong book home today will trade will trade You want to introduce Diana? Sure We are so glad to have you here today Diana Carlisle and you have been part of Unearthing lots and lots of Burlington history and you're here today to tell us about a very special topic, right? So Why don't you launch right in and tell us what that is? Okay? Well the topic I see honoring the old North End's glass makers It was the glass makers But it was also those business people that decided that Burlington could move out of the agrarian farmer mold after the War of 1812 10 years later and Sparked by the Erie Canal completion Which opened up the world to the West and all those cities that developed and Burlington took advantage of that with help from Boston investors and some in Burlington itself and decided to start a glass company window glass So although now we have a lot of glass makers in town.  It's kind of a continuity, but anyway when the Erie Canal opened there was an opportunity and with the investment and the the Perseverance and the entrepreneurship a glass company was formed in 1827 Not an easy task. I mean I I was just doing a little bit of research for the UVM Students and we talked about windows. So this is a I'm really interested in the manufacture of glass But it was it was imported from Europe for the longest time to get the the crafts people and the money and To be big enough to actually do it was took such a long time for our fledgling nation That's right part of that was a colonial Control and tariffs and controlling the flow of product right and So that's exactly right and it took tariffs. It took some economic Helps along the way because of England was giving us glass for less money than it would cost us to make it but anyway yes, so they started and It was a four people from Burlington that were the head head of it But the most important person was a Boston superintendent of glass making who brought these Immigrant glass blowers Germans mostly some English and there had been a glass company in Boston that had just closed and he brought them up and He established it and he had the recipe for the glass which made it beautiful and clear and strong And he had the craftsman the is the blowers the glass blowers Yeah, and it took years and years and years to learn how to be a glass blower So this was key and then they also and so it was window glass by the cylinder method Yeah, and that meant that they blew them into long cylinder kept it going get bigger bigger bigger And then it put it back in the oven and then it opened out and they tempered it And then they put it on a table tempered it and kept it and then finally they could cut it into the Into the sizes right so they make a bottle. Yeah, cut the ends off Yeah, well, yeah, they cut it sit with the scissors and flattened they'd score it right so in the oven It would flop down. Yeah, it's not like the bullseye. It's different. Yeah, and it was the German people So anyway, and it made great glass and the fan lights and the mirrors and other things like that so Let's see and they needed other things that it were here in Burlington and the company was called Champlain glass company it had many different owners through the years But it always went by the business name Champlain glass company And one person that was very important in the beginning was a young Person in his teens late teens called Frederick Smith named Frederick Smith and he was an apprentice His father had died early and he'd been bonded out to a farmer to his mother didn't have enough money For feeding him and keeping him. So this was common in those days But he ran away because he said they didn't feed him well enough He ran away to Burlington and he found this glass company and he was a protégé of the superintendent John Foster Took him under his wing saw the possibilities. He was smart and he'd had some schooling and Brought him along the food was better Let's hope I think it was yes so anyway that so that was Frederick Smith and Jumping ahead he was pretty pretty constant through the life and it was due to his preser Perseverance that though that it went as long as it did. So let's see. What what else do I so? He was like a common thread during that ownership changes and everything else Yes, and actually he was There was some ownership changes. There was a little hanky-panky there in the early 2018 30s where some people took the money from the Champlain glass company and started something across the lake which didn't help with the business but Frederick Smith left and went to Lake Dunmore for a large amount of money even though it was only 20 or so but then he came back and purchased Rented and then purchased and took it through to the end. Oh, wow. So when was the end? How long was the company? It went to about 1849 1850. It's a little uncertain because We can't find any actual date when it finished There were fires. There were deep, you know economic downturns. There was competition for the skilled glass people there was coming and going and It says here that they were located between North Champlain and Water Street, which is now battery. It was in that area So that opened up the old north end because there was nothing there except the contendment They cut the common the the barracks right from the from yeah from the war of 1812 So there's the picture and you can see That's the battery park common. Yeah, uh-huh And then there's the lake up to the left you can see a little bit of the lake Yeah, and then you can see the glass works there and a couple of the outbuildings and then across the street They began to build houses for the workers the workers had to live nearby because they required very high temperatures to melt and Then blow the glass so the young boys that were working. It was child labor Yeah, run off and get the blowers and say it's time. So they a housing area developed there So that's why it was so important to that area and later Frederick Smith was tasked by the city to develop all the area lay out the streets to the left and the right of what you can see there So he was also instrumental in that and he bought up a lot of the property there and I developed that There's not much left We can't find any original of the glass works, but there are two beautiful homes on North Champlain as you go north Brick homes that are very similar. I can't I forgot the number. They're gorgeous and they were by the glass blowers They were built by the glass blowers and one of them was probably a boarding house The young glass right because they're big. They're big. So yeah, but that shows that the glass blowers were a high Economic level in the community. They even sent their sons to dancing school Do you have a sense of how many people the glass works employed? They employed about a hundred when they started to build and to get it going and I think it said in 1840 when it was It's most prosperous. They employed 40 Now that was people to make the pots people to blow people to Drive the wagons people to keep the horses people to cut the wood people to make the boxes And of course they had agents all throughout the Erie canal all the way to Chicago So they were employed a lot of yeah a lot of and in and they paid by cash the Burlington Free Press wrote a very congratulatory Editorial about it a year after it opened that it's giving jobs for the winter It's paying cash rather than barter So it's it really was key to to that whole development and to bring us into the manufacturing factory And those are the some of that Okay, yeah cash-given for us. Yeah. Yeah, what got you interested in the glass works. How did you come to? Dive into this. Well, I was in I was brought up I went to school here in Burlington it but I then I went away and when I came back I was visiting my mother and my dad and I was saying the summer and I wanted something to do of interest I am a history major and So a friend said well, why don't you take a class? Mm-hmm. So I took a summer class with Tom Visser Historic preservation. Oh That opened up a whole new thing so at the end of the class We had to pick a building material and how technology had impacted the building material and therefore the design of homes Mm-hmm, and I was quite fascinated with glass because in my small 20 years in my own home I was as it became more heat It you didn't lose so much heat you could build bigger windows and change So I came home to my mother Lillian Baker-Carlyle and I said mom I'm going to write a paper on glass and she said oh Do you know there was an old glass company in the old north end not much has been written about it But I said that's my topic. That's David Blow and my mother had begin begun as they did the historic guides together a few starter pieces Yeah, I'm gonna give a shout out to the special collections. Yeah do that Oh my gosh, I thought well, let's see. I'm gonna start to look into this and I went down to special collections And I said do you have any information on a glass company that was in the old north end? She said let's go look or I'll go look, you know about a half an hour later. She came out laden with with the the the the Employment books the the financial books the the the list of the company store what they you know They're their transactions the ledgers the ledgers. I Just couldn't get over it that the Smith family had donated All these things in their home and in the office to the special collections for somebody in the future me Yeah, come and write Is what they have up there? Yes It's so great. So if anybody has anything in their family or in their business, you know now It's like the first place to go to leave it so that somebody in the future. Oh, yeah Because that's that's that's something that historians really do grapple with in this digital age Yeah, what is going to be left? Yeah, so if one funny thing in the ledger Apparently one of the Smith children had used it as a penmanship practice paper And he and I he was writing over and over again a fool Let's see a fool can fool you once know a Villain can smile and smile a man me smile and smile and be a villain yet Those aphorisms or whatever they And I said it's still true. Yeah That's amazing. Yeah, I love the special collections It's like we were mentioning earlier before we got on on air about the you know the rabbit hole You know that you can go into things and you have a topic or something speaking of holes and digging I think you brought you found something didn't you? Yeah? Yes, so I'm so I did we did do a little bit of digging in the area nice segue. Yeah and They're you know, you you don't know the but but you have to leave a little bit of the old Cullet or frit to put in when you make the next batch So there's all and then you so it gets buried and discarded and so forth So if you know where glass companies are you can poke around and dig and of course in Boston They have done a big job. They know where the Boston glass You just use two words, I don't know call it and right well frit is just a piece that you can cut off Yeah, whatever and the cullet is the leftover and you have to put along you saw the sand the clay the salt That go into making You have to put a little bit of this leftover stuff. So of course they discarded and it's underground Yeah, that's really neat So this is just part of the old It really does right like something you'd find like amethyst in the ground. Yeah, that's really cool So into glass goes what you said clay sand Sand and clay and salts sometimes arsenic Sometimes There's another to make different colors different things But a bed of sand is particularly important and we have the big quartz in near the Winooski near the high bridge in Winooski There's sand There's a delta in Colchester and and then the clay of the wood ashes everybody had wood ashes Yeah, I would bring them down and it's a source of income for the local people and then clay very important for the pots Yeah, talk about recycling right You don't throw anything away you sell it to the last company wood wood wood Because the temperatures were so high and I'll and that's what? About two thousand sometimes two thousand degrees now I don't know what that's what it was that and I must say that's what one of the things that finally caused the end To the New England glass makers because the wood wood ran out. Yeah lack of land in Pennsylvania The coal and the natural gas Was a much better source of you know heat that they needed and they were near the markets Yeah, so and the railroads came in. Yeah, it's so 1849 all of that stuff happened around that side The railroads came in and so the lake advantage was gone. Mm-hmm, and the wood was gone Yeah, yeah, because what we didn't burn we sent to Boston or Montreal or New York City as lumber Right, I want to say we just saw on the screen Historic marker, which is also part of the story that we asked you to come on and talk to us about right because we're planning an event All right. Yes. Yes, so so tell us about this this marker in this event. Well I'm looking to you to help with the It's going to be installed in Battery Park I should have said that the owners Bought the Battery Park bought the common and the government land when they sold it in 15 years after the war or whatever They bought it and a few years later. I think was 1830 1840 They donated that part of the common, which is the battery to the city of Burlington With a proviso when they deeded it with the proviso to be used as a park and for the common good forever Oh, great, which is why we have that wonderful public space So that's very important and very thank Goodness for those people and I heard from the family that it was Fred Smith's wife That said that wouldn't should be a park forever And she persuaded them to buy it. Yeah, so thank you Especially then when there was so much industry down on the lake I mean that was fledgling industry and it was happening right there But you know the lakefront wasn't what then people perceived as beautiful exactly and they were moving up on the hill and It was a dicey area down there Right, right. So a lot of forethought to save that for future generations again like handing all the paper all the papers to Special collections. Yeah, that's right. So Anyway, one day I just I've been seeing the historic markers and I said what a good good idea to pause and what happened on the space Place who was important who did you know who made an impact who left something for the future? So it was your idea. It was The only one, you know, I was the one that researched and yeah, so You know, but so I I called the state historic woman Laura Tishman. I think. Oh, yeah I know I talked to talk to Tom Visser. Thank you Tom Visser and he said great idea important company important thing for housing and so they came on board immediately and Sent me the application assigned me an intern Cheyenne Stokes a grad student because it became a little overwhelming when I saw I had to go and Establish the longitude and the latitude. So this is a process. It's not just an application apply for a marker It's a they very careful about what you say and what you do and how you describe it and where it's going to be They don't want any mistakes, you know No, that makes so much that my daughter helped so Cheyenne and my daughter and I wrote it up and kept it going and Now it's approved. It's made and it's about to be installed by Park and Rex Oh, that's in a battery. So how long of a process did you how long did it take you three to? Yeah, they're all the information and well it was about I just was noticing a year ago We we submitted the application it's about six months off and on because I didn't think it would be such a big deal So and it was not you know, I had everybody had other things going of course So but when it's I'd love to have a ceremony and I'm talking now back to us That's right. I know Bob our new chair of the Education Committee to celebrate it I will say that I did give a talk at Vermont history because they were donated a beautiful bowl the only extent piece of private a Glass-making that we have from that company. Oh, wow They made it for their own use at the end of the day Mm-hmm, and he so so Vermont history helped me put together a PowerPoint presentation Which I can do and if you want to do a little walking tour. Yeah, that's the plan The plan because it's part of I mean it comes up a little bit in our old North End Ramble tour Which we sometimes it shifts from this end of the old North End back towards Battery Street because if we do the whole thing It's really long, you know, but I know that yeah Bob was asking us to find the exact time and date He wants us to put it in the ground like right now and just cover it with a blanket until it's time to have Mentioned this bowl. Is there other are there other examples of you know, what that's a sad story There were only two and if they'd become and they're missing I don't think it seemed to have that the family had one piece and when the person and when a Dotsmith Hannah died who was so helpful to me as were a couple of the other people in the family She was living in an assisted assist of senior and and when she passed away She told me she was going to leave it to somebody in her family It disappeared So the only thing we have is this gorgeous milkpan bowl that Milton Crouch bought That's another story and before he passed away. He donated it to Vermont Historical Society Great, and who knows the windows in Holmes in Burlington that were blonde. Yeah, I know never know Yeah, well, maybe maybe maybe that's a you know, keep digging. Maybe we'll find it. No I Mean you're done. Yes. No. No, I mean we can guess but you know, there's no there's no way to The only way we know this was definitely from it was because there was a picture in the free press When a descendant of one of the glassblowers gave the ball Okay to Flaming Museum. Oh, right. Oh neat.  Oh, yeah, there is some wavy glass I have to say Fred Smith's house is still standing the red brick house. Yeah across from Battery Park Yeah, gothic, right? Does it have a plaque maybe we should give it a block well the owners they may I think they do have one and they took a window restoration workshop from preservation Burlington, you know in my shop and Women that live there Learned to restore that. Yes, and they said there is some wavy glass up in A little continuity So what's next for you glass works is all done all on the chance, you know, there's never it's never it's never done I was in the I was in the I like to walk in the Lakeview cemetery I like to walk in the cemetery. It's near my house and I look at this Fred Smith tombs, you know monument And I read the year That he had bought the glass company in the 1830s and started it again The same year you see his first born child died two weeks after it was born And then you know, I look a little more and then I see four years later another little child dead and Then the glass company relocated up to Canada for a while thinking they'd get more wood up there And he lost a 12 year old son and the only son that survived is Charles P. Smith who started the Burlington Bank with the time and temperature but I see so to me that whole Personal side yeah of what else was going on and and some of the glass bars in the tragedy, you know I could go that rabbit hole that Digging up the personal and then his his partner Landon I They auctioned off all their land and I thought it was because it had gone out of business Now with the internet. I did a little it said Ralph Landon killed by the cars in Swanton rushing to get on the train It's two years after the train went through. Oh my goodness to go to his father's dying bedside in Rutland And I I said to myself there's a whole nother part of What people were going through I smell a book? Well, and I'm doing the lake the chapel of course. Yeah always so and we'll be doing tours again of the chapel Now, thank you for all the work you do and for it's fun for digging up all these stories It's just really you know, it was like Where we where we lived in the well I like to honor all of these people that made so much to leave the place what it is that we know today And we'll announce the event as soon as we have be up on the website, you know, thank you This was so much fun. Yep, so thanks everybody for tuning in To our live at 525 show and preservation Burlington for more information on history our tours and events The quilt and to get a marker Diana's work and to get a marker for your house You go to preservation Burlington dot org and we'll see you next month. Thanks again Yeah, you can say another time they could go online and find the whole story