 Okay, I wonder how close should I meet to this microphone? All right, so we're gonna start in, I don't know, 30 seconds because there are still people entering the room. There are some seats in the front, like two, three, four, six seats in the front at least. And there are two there still available. Okay, so I'm gonna start now. Hi everyone, happy to be here with you. Today I'll talk about CK5 in Drupal 9 and 10 and about some things that you probably never heard about CK Editor. I hope to inspire you to squeeze the most out of CK5 in Drupal projects with this presentation. About myself, I'm working for CK Source since 2007. CK Source is the company that makes CK Editor. We are located in Poland, have currently like over 80 people on board. I started as a developer in the past, I was also the maintainer of the CK Editor module for Drupal 6 and 7. Currently I am the president and CPO of CK Source. So today I will cover several topics, how CK5 ended up in Drupal. I will give you some overview of CK5 including presenting some of the features that are not included by default in Drupal, but that you can try to add. And at the end I will go through a sample plugin that was built to showcase you how to extend CK5 with your own features. But before we start, let me show you a couple of screenshots of CK5 to stimulate your imagination. So that's the stock CK5 in Drupal. It recently had a refreshed interface, so the background is white. This is also the stock CK5 in Drupal, this time with a little bit more features. This is CK5 with a customized team, thanks to CSS variables. This is CK with restricted editing functionality, allowing you to create only... Oopsie... That's funny. Super restricted editing. I have to be very gentle, this adapter is really sensitive. Okay, so I will try to change the slide with my eyes maybe. This is CK5 with restricted editing functionality, so you can create only certain parts editable in CK5. Here you can see some fancy features called pagination. That lets you see in the editor how the content will be split into pages in created PDF files, that you can create with CK5 too. CK5 can be enhanced with spell checker, grammar checker and intelligent text predictions. This is also CK5, here you can see track changes. So basically instead of making changes in the document, you can add suggestions to remove add content, etc. There's more sophisticated revision history where you can compare even several revisions at once. This is CK5 with free time collaboration, where multiple people can edit the documents simultaneously. This is the cake edition of CK5. Yes, so I'm showing those examples to you to underline that CK editor is really flexible. The default Drupal integration is great already, but it doesn't have to limit you in any way, because thanks to Secular API and Drupal API you can extend it further with features. So, a couple of slides about how it happened that actually CK5 ended up in Drupal 9 and Drupal 10. As most of you know, Secular 4 is the default with weak editor in Drupal 8 and Drupal 9. It has been added to the Drupal core years ago, like 12 years ago or something like that, or 23. Unfortunately, as every software is slowly reaching its end of life next year. So, because of the upcoming end of support for Secular 4, Drupal had to choose another with weak editor to replace Secular 4 in Drupal 10. There was a little bit of brainstorming about which editor to choose, but Secular 5 has been selected as the successor and will become the default editor in Drupal 10. There are multiple reasons why this has happened. Secular 4.5 is a really good editor, but most importantly, we had a good track of previous collaboration with the Drupal team. The next slide will show this a bit. On the next slide, it will show the number of tickets that both Drupal core team, Drupal community and CK editor team had to close to ship Secular 5 in Drupal. I'm not sure if that's a good recommendation for Secular 5 in general, how many tickets it took, but just have a look at this. So, it starts here, and we go through tickets, even some more tickets, and tickets, tickets, tickets, lots of them, plenty of tickets, too cheap, just so easy to get it over, and tickets. And the list stops here, so that was the 10 seconds time lapse of two years of people's life. Yeah, so it took us over two years to complete all the work required to seamlessly integrate Secular 5 with Drupal and guarantee desired developer and user experience. And taking this opportunity, I would like to thank everyone who was engaged in this process, especially to Benjamin Millins, Laurie Escola, women leaders, and Peter Weber, and really big kudos to them. And I would like also to thank all the other people involved. Thank you, everyone. This list actually does not contain all the nicknames of people that help with that. Okay, so on the Secular site, we introduced some features in Secular 5 internally to satisfy Drupal requirements, and we had to focus among other things on several things, such as general HTML support, because believe me or not, but the initial version of Secular 5 was actually very strict in terms of HTML elements and tags that it supported out of the box. Basically the first version of Secular 5, I mean the first and a couple of other reasons, were just supporting elements and attributes that were only supported by Secular 5 plugins. So if there was an HTML markup that didn't follow this rule, it was simply removed by Secular 5. We had to introduce, yes, I have to speak closer to the microphone, we had to introduce so-called general HTML support, where through just the definition, you can actually define what additional elements, attributes, and styles Secular 5 should support. And this took a while, but thanks to that, you might be sure that if you port your content from Secular 4 to Secular 5 from Drupal 9 to Drupal 10, the content will be preserved. Another thing that we had to introduce, and this is just like an internal thing, but basically, unlike typical JavaScript applications, Drupal has a requirement to be able to ship an extension for Secure Editor through country modules. So we had to invent, let's say, a mechanism to be able to attach plugins to Secure Editor. And because Secure 5 is, let's say, a modern JavaScript application, typically you just bundle all the JavaScript and finish with a bundle that cannot be actually extended, etc. But here Webpack Delos were handy, and we added some additional functionalities that were not available in Secure 5, but for, let's say, future priority, etc. We introduced them, so styles drop-down and document lists. Document lists were particularly funny because this is the thing that you actually probably don't notice at all when you work on it. Basically, this is a functionality to be able to have a block image inside at least item or a heading inside at least item. And it took us like months of development to ship that particular thing. So one understanding that I wanted to mention before we move forward, don't be fooled by the numbers. Next to the name of the editor, Secure 5 is not a continuation of Secure 4. It has been rewritten from scratch. So as a Drupal community, you maybe remember the situation with Drupal 7, Drupal 8, and the migration. So that's the case here. So it is a completely new editor with a different architecture and APIs. We were writing the editor was a hard decision, but we doubted we will not be able to introduce all the changes we wanted. Basically, there was no easy way to make some transitions from Secure 4 to Secure 5 to enable the functionalities that we wanted to introduce like truck changes, return collaboration, and so on. So as a consequence of this switch, any country plugins for Secure 4 have to be recreated to work with Secure 5. Side note, yeah, writing so complex software from scratch is an incredible challenge. And we will think twice before we try it again. So basically, we started the Secure 5 development like eight years ago. And we still are adding features to it. So really, it looks simple at first glance, but it's complex and really time-consuming to produce something like that. So let's have now a closer look at Secure 5 in Drupal. Secure 5 was started into the core in Drupal 9.3 as an experimental module. And starting from 9.5, Secure 5 is no longer experimental and Secure 4 is deprecated. It shows the confidence of the Drupal core team into the effort that has been already made. We actually support it. So basically to try out Secure 5, you don't have to wait until Drupal 10 is officially available. You can even try it out in Drupal 9.2. So the process of enabling Secure 5 was a little bit different in the previous version of Drupal. It was marked as an experimental module. And starting from Drupal 9.5, it's no longer experimental, it's stable. But instead, the previous Secure version was marked as deprecated. Just to notify unaware people that it's going to be succeeded next year. So once you enable Secure 5 module, if you're on Drupal 9, you have to switch the editor, text editor, and text editor. It takes for much configuration to Secure 5. And once you do this, you will have a new toolbar configurator with new buttons and some warnings. So that's the new Secure 5 in Drupal. Okay, so in Drupal 10, Secure 5 will be the default, the only wisdom editor available in the core of Drupal. That's because of Secure 4 not being supported anymore. Drupal 10, according to my knowledge, is going to be released in December this year. So we always still have some time. However, we encourage you to give Secure 5 a try, especially if you're looking to improve the editing experience of your users. A little bit about the data retention. I already mentioned this. The Drupal core team did everything that was possible to keep your data safe, and so we do. And once Drupal 10 is officially released, there should be no data loss. When your content from Secure 4 will be loaded into Secure 5 after the upgrade. Even if it turns out that some features are missing in Secure 5, the goal is at least to keep your data in place. So remember what I said about general HTML support, that it provides support for everything, basically. A bit different story is when it comes to all the modules that were extending or interacting with Secure 4. Since Secure 5 is completely different software, all these modules need to add dedicated support for Secure 5. If you're using some less popular modules for Secure 8 or you have developed your own, you have to make sure it's ready for the new editor. There's actually a helpful documentation page that may help you understand what's the status of some Secure editor-related modules and how to test the upgrade path, etc. Now let me go quickly through some new enhancements added to Secure 5 in Drupal. First of all, the new editor comes with a new better UI and improved user interface. For example, media widgets have now a dedicated balloon toolbar attached, allowing users to quickly adjust embedded media. You can find options directly in the editor. Links have now a balloon panel attached to it, allowing users to quickly see the link URL to manage it. The styles dropdown has been reworked to let you present nicely how each specific style will look like. I was having some hard time to configure it in Drupal, so make sure to try it out and report any errors you find. We introduced some productivity enhancements, such as how to format things, where you can use the markup similar to Markdown, within the editor to make lists or quickly format the text. For instance, if you start with two stars, type some text, it will become bold, so simple but a useful feature. In fact, it supports lots of markup, like lists, to-do lists, headings, code logs, etc. The one small issue is that it's not yet available in Drupal, but it's in progress, and I know that there is an intention to have it shipped in Drupal, too. Right now, we can test it in the Secure Editor documentation, for example, but it should land soon in Drupal, too. Another similar functionality are transformations. In this simple example, we will surround C with parentheses to convert it to a copyright sign automatically, something like that. You can actually configure those transformations to add similar transformations in Secure Editor. This is actually not shipped in Drupal, but if it looks interesting to you, you can always fill an issue and count on that. It will land sooner or later. One more thing that I wanted to showcase to you. Basically, it's something that doesn't make a wow effect, it's just a source mode. But if you are more familiar with how the development of Secure 5 was going over the last years, we were actually quite unhappy with adding support for social elements. For quite some time, we thought that that's not the way how you should propose rich text editing, that basically you should propose a decent UI for that. You shouldn't expect from your users to know HTML, etc. And guess what? We had so many people looking for it that we had to give up and we introduced it. It's typical that on some websites there are power users that actually want to use HTML, that want to enter manually some sophisticated HTML, which isn't supported through the UI, so we basically introduced it. So yeah, we have source mode again. Right now I would like to show you a couple of ideas for simple country modules that you may create for Drupal, utilizing already existing features of Secure 5. They are not shipped with the core library, but you are free to make country modules. By the way, just my two cents. Country modules are a good way, in my opinion, to sell your skills. We are looking actively for a good developer to help us with Drupal module development. And one of the things that I look personally at is the public profile on Drupal.org. So if you're a Drupal developer, make sure to do something for the community. It will help yourself, too. Okay, so first plugin, not available in Drupal, but probably easy to ship it. It's the word that characters count. Basically, we expose the API and you are free to propose it in any way you like in the UI. Second thing are mentions. They may even have more sense, paired with some custom notification system, for example, to notify people when they are mentioned in a document or something. And perhaps also with two-list items. Things that probably some of you know from CQl4. There was quite a popular module for CQl4. This is also available, like setting font family, size, color, background color. It's available for CQl5 too. Same as find a new place. So basically, if something is not available in Drupal out of the box and you like it, you can always add it by writing a module or checking if someone already did that. Another category of plugins that are not included in Drupal... Okay, that should work. Another category of plugins that are not included in Drupal are the premium features. As you know, CQl5 is an open-source editor. Anyone can use it for free under the GPO license. At the same time, in order to have a team working full-time on an editor, we need to have funds to run the whole thing. So that's our solution for this problem. We just have some additional paid features that anyone can additionally purchase to CQl5. And just like two minutes, why actually funding is required, that's the story of Aloha Editor. Basically, they had a really high chance to be included in Drupal 8. And somehow it happened that we were selected to Drupal 8. But the story is that Drupal 8 was released publicly in 2015. And the same year, Aloha stopped being maintained actively. They just were minimally maintained with a two years break in 2019. And for a project like Drupal, it's really important to have stable dependencies. And we as a product company also understand how it's important to have stable dependencies because you don't want to ship your product with a dependency that you will have to maintain a year later by yourself. Another example of dying projects is QuillJS. So it actually is kind of that since 2019. And as you know, projects without proper support are a major threat for everyone. There are some security issues hanging on GitHub issue tracker. I haven't verified them, but nobody's taking care of them. Another fun stat is that from eight supported editors by Drupal 7 with WIC module only to survive until today. Okay, so enough about that, editors. Here are some of the premium features I would like to quickly showcase before we move on to another part. So export to PDF. With proper configuration, you can actually achieve some document layout. I mean the same document layout I've seen CKEditor. So that was CKEditor. That's the PDF file. Yay. Export towards similar functionality as export to PDF, but this time creating DocX files with commands and suggestions supported. Talking about commands, there's support for commands in CKEditor 5. There is support for track changes. So adding suggestions in the document, revision history. What I particularly like in this functionality are the up-down arrows on top that will let you quickly browse through the changes in the document, especially useful if you have like super long documents for some reason. And retouch collaboration. So basically, if you like, you can change your CKEditor 5 into a Google Docs-like editor. I actually found out that some people are using Drupal and Google Docs together to collaborate in Google Docs and later paste the content into Drupal. So if you would like to use a single application, you can do so. And you have full control over where the data is located and so on. So we are working on a dedicated module for that integrates those functionalities. I was actually hoping that we're going to have our release today, but yes, we have. Okay, so yay, it has been released. So you have a chance of being super early adopters, probably misleading documentation and some issues. If you are eager to try it out, go ahead. It's marked as 1.00 beta and some of the modules are marked as experimental, but I encourage you to give it a try if you like and report issues because we probably are not aware of some issues. Yeah. So here's a sneak peek of the module. So CKEditor with retouch collaboration comments, track changes directly in Drupal. It works in Drupal 9.4 plus and 10 alpha beta, whatever, alpha 7 and beta 1. Yeah, this is the same article, but we don't have a lot of space for the editor by default. I have no idea how to fix it, so we have this collapsible sidebar to gain at least a little bit more space. And we have some proof of concept of maximized planning. That expands the editor to the whole report, let's say. The revision history is also integrated with Drupal. It's a little bit different than the default Drupal revision history because it is accessible actually from the editor itself and it's more granular than the Drupal revision history. Yeah, so just play with it and you will understand the differences. Export to Word is also integrated with Drupal. Here you see the same content but exported to Word with suggestions and comments included. Okay, so let me check the time. Yeah, we'll have like half an hour for questions. So let me change the topic now and talk a bit about widgets. Similarly to CKEditor 4, you can use widgets in your plugins to place various objects inside CKEditor. For instance, more complex structures, product cards, external libraries like charts, math formulas or whatever you imagine. So to put this in really, really simple terms, a widget is just an element inside the editor that has this little highlight border. The arrows in top left and bottom right are to actually make it simpler to add paragraphs at the top or under the bottom of the widget. And it can have some additional toolbars attached to it. So a good example of a widget is this image element or a table or this widget to insert diagrams using the Mermaid syntax. There are other brilliant widgets that you can create by yourself. It's just to inspire you. By the way, in case of you are wondering what you see here, you are correct, that's actually a screenshot from GitHub where we replace the default markdown editor with CKEditor. And we made this Mermaid widget when we noticed that it's supported by GitHub. Yeah, so that's our editor in action. So we can actually download it if you like. We just wanted to... There is this saying like, eat your own dog food or something like that, so we just wanted to try out CKEditor in action all the time and deal with all the issues we have. Yeah, so it's available for Google Chrome and Firefox. Yes, changes this thing into the other thing. There's one thing that I actually appreciate the most in this extension is that basically it has support for tables. I cannot sometimes even remember how to make links and so on in markdown, so for sure I don't remember how to make tables in GitHub, so it's useful for me at least. Okay, so I will use the GitHub writer to explain one more thing about CKEditor 5. So now we, let's say, change the part of this presentation to the more technical one. So how is it actually possible that we injected CKEditor 5 into GitHub? Since GitHub is actually operating on markdown, so that's because of the architecture of CKEditor 5. So basically if you input HTML to CKEditor 5, it goes through HTML data processor to convert it into a model, which is an abstract presentation of the data, and the same if you ask CKEditor 5 to return the data, it goes through the, let's say, data processor, let's say, to output HTML. So we replaced the HTML data processor to markdown data processor, and that's it. But this should give you an understanding of what's possible, because in theory we could replace the markdown processor with JSON data processor. So perhaps someday we'll introduce some more block-based oriented variation of CKEditor 5 next to classic HTML that outputs something like JSON instead. We'll be interested in something like that. Just feel free to reach out to us because we would like to actually understand how to propose such an editor. Yeah. So in the last part of this presentation, I will quickly introduce you to the CKEditor 5 plugins development. So let me check something. Okay, so anyway. Yeah, let's switch to the plugins development. I was sure that I have a warning here in the presentation, but I can't find it. Basically, my expectation is not that I will teach you how to write plugins in like 10 minutes. It's more like to inspire you. And there is a sample plugin available on GitHub. You can go back to this presentation to get a taste of it, but it's impossible to learn this so fast. At least I'm not able to. Okay, so before we switch on to that plugin development, I just wanted to say one more thing about Webpack DLLs. I will actually probably repeat myself. So basically CKEditor 5 uses some modern ES6 JavaScript, so it's being bundled with all the features you need in the ahead-of-time build process. So this wasn't suitable for Drupal, where plugins should be added actually dynamically through country modules. So we had to, you know, ship this Webpack DLL support. And I'm actually not able to explain what they do inside. So basically it's about placing one magic file with the DLL handling code for Webpack configuration and it magically will make it happen that your imports between dynamically added files that they will work. So you don't have to understand it. Just like me, we have like a special DevOps team that handles that and we just consume what they do. Yeah, so in the sample plugin, you will find like the part of code that you have to use to give support for Webpack DLLs. And you can do it this way or you can actually use our CKEditor 5 package generator. That is actually producing a nice plugin out of the box with things like ready, I mean, there's like some simple code that shows how to write a plugin. Basically, there's a code of a plugin that defines a button and does something. There are tests already included. There is a code to actually create a DLL out of this sample plugin. So basically, I encourage you to give it a try. It saves a lot of time. There's life reload also available and so on. Okay, so let's see this whole module plugin development in action. We'll create a sample module that will add two columns layout in CKEditor. So this is an example of a widget. Again, you see this like additional features around this widget. And remember that widgets can do really magic things. So for example, we can restrict what HTML is supported inside widgets. So if you'd like to have a widget with something like title that just supports text or just basic formatting that's possible too. Here we just define two columns layout. The source code is available on GitHub and this is like a nice example of open source cooperation. It was based on previous attempts by Peter Weber and Laurie Escola. I just copied it and fined it and added some comments. I did the code later if you'd like to. So a little bit about how it's structured. Know that there is no PHP required to a Shippa module that provides a CKEditor 5 plugin. There's just a webpack configuration file and some YAM files and some JavaScript files. So in the webpack configuration that I never understand, there is some like definition of an output file, library name, etc. So basically things that I never remember but they have to be there. There is a landscape that actually builds the DLL. This is if you copy the sample plugin that's available on GitHub. But if you use our plugin generator it will actually provide you a little bit more features like building the DLL, life reload, linter, tests, etc. So that's why I'm actually recommending it. Yeah. So about the YAM files required for the plugin, the info YAM file is just a standard module. I mean standard description with some dependencies. The CKEditor 5 YAMLA is more interesting. It describes the plugin that we create. For example, at the bottom you see the elements that it introduces a little bit above the toolbar item that it introduces and so on. And the libraries one, it just like defines which assets to load with extension for both admin and the frontend. So that was the JUPAL part. Now the CKEditor 5 part. Let's start from the simpler things. So basically the plugin will consist of let's say four parts. CKEditor 5 is in general much more decoupled than CKEditor 4. An anecdote to enforce ourselves to have a really decoupled architecture at some point we ended up with like 100 repositories for every single plugin. It was super useful when we actually had to, I don't know, update the copyrights with a new year or have pull requests that were touching like several plugins. So to solve that problem we have to write our own tool to deal with that. So after dealing with that for a long while we ended up with a monorepo back because we spent so much time on it. And yeah. So going back to the reality we have to define the UI. We have to create a comment that will insert those two columns into the editor. We'll connect this comment with the UI so that this comment was executed when the UI is when the button is pressed in the UI. We have to define the schema which actually tells the editor where these two columns can be inserted and where not. And we'll define converters that I will explain soon. So basically four concepts that you have to understand. Don't worry we have it explained in our documentation. Yes. And if you will not be able to understand it after the first reading don't worry. It's just complex. Yeah. So these are all the files that we need to create. The comment one. The main plugin file that loads the rest of files. Editing file where we define schema and converters and the UI file. You know in general you could place it into a single file that just to showcase more or less how those things are split in CK editor. So the main file has just a bit of code. It simply loads the editing part and the UI part. The UI is pretty simple. So we create the button there and we ask the button to actually the editor to listen to the execute event of this button and if that happens the insert to columns command is executed and that's basically all. So changing the topic for a while the main difference between CK editor 4 and CK editor 5 is that CK editor 5 operates on its own document model. We love abstraction. It actually was supposed to help us a lot with dealing with changes in the document and it actually helped a lot implementing things like track changes or return collaboration was much easier. Thanks to that. So in our case we will create two model elements two columns and columns that will have their own representation in the view let's say. So the representation is pretty typical we have section and some divs but in the model this is much simpler. So a little bit more about the model just to give you a better feeling of this part. So on top you have at the bottom you have the representation in the model so we see that the headings are let's say typical paragraphs too but at the same time you see that inline elements are actually just attributes on the text and another interesting thing are the list items. So we no longer used nested list items in the model we have pretty flat lists with attributes that handle the list indentation. They help us deal with nested structures. Okay, so the editing file takes care of almost whole logic. I will go through each method on the next slides. So in the init methods we define the schema and co-vertors and register the comment. Of course the code will go later. The comment itself will insert those two already mentioned model elements to columns and column on the current selection if it's allowed by schema. So here we have also the refresh method of the comment to make sure that for example the state of the button will reflect whether it's possible to inject particular element in the editor or not. So a little bit about this magic word schema. Schema defines rules for the cq editor engine on how to process the model. For example where elements can be placed what attributes are allowed in elements it will be used during editing when pasting content and so on. It's a little bit complex to understand but it's where the power of cq editor is. Again if you were not using general HTML support in your project let's say somewhere without using Drupal just be aware that only known elements and attributes will be retained by cq or 5. So speaking about schema we will tell the editor to allow two columns elements everywhere where block elements are allowed and we tell that the column is only allowed inside two columns container. Now we define converters so another complex word. So going through this super quickly in cq editor 5 there are two different conversions, model to view which we call downcast and for example if you call getData to get HTML from cq editor the data conversion happens so when cq editor renders the model in the wizard area it frequently does the conversion into the editing view whenever it is needed and the upcast conversion so the opposite to the previous one upcast conversion on the other hand happens for example when you paste content into cq editor cq editor gets HTML and transforms it internally into the model also the downcast conversion simply happens when you start cq editor with HTML. So we define some upcast and downcast converters for the main two columns converters using our conversion API I won't spend too much time explaining this but you can check out the extensive documentation if you want to more more. Again the goal is to guide cq editor 5 how to convert HTML to the model and vice versa and we do the same for the column element as well so once we have this module completed we can go to the module screen and find this module and simply enable it remember also to adjust the format configuration text format configuration to add the new toolbar button and if reverting went well you should see a new button in the toolbar and you can should be able to insert this two columns layout so for the better developer experience we created a dedicated developer tool called cq editor 5 inspector this is the thing that you see at the bottom it basically lets you inspect the model the view selection markers and basically everything that will help you to build your plugins you can check our documentation for more info I believe there is also cq editor 5 def module that ships that functionality too you can also attach this cq editor 5 inspector simply using bookmarker it's explained in the documentation if you're using a bookmark in the browser you can inject cq editor 5 def inspector anyway that's almost it but I wanted to mention at the end that there are two additional sessions about cq editor 5 tomorrow Lori will make an event deeper dive into cq editor 5 so check it out and on Thursday anyone willing to work on things related to cq editor 5 may come to our dedicated session where help will be available we will have also some cq editor 5 core team members available online to help so there will be me, Katzper, Lori and lots of folks online willing to help you I wanted to say at the end that we also have a booth during this conference so please feel free to drop by we would love to hear your feedback about cq editor believe me or not what we will develop next depends on you, cq editor users we basically have really feedback driven development so feel free to come to us and say what you would like to see next and give some context what's your application what you're trying to achieve because sometimes it's that we can figure out a different way to solve your problem so that's also important also please feel free to drop by if you are interested in some of those premium features that you showcased so that's all I have for today I hope you liked it and you will give it a cq editor 5 or try if you would like to chat about cq editor or anything else I'm here until Thursday as well thank you the hardest part questions if you have any if you have time, I don't know yeah, go ahead hi, could you maybe elaborate a little bit like on the revisioning system like how the persistence work so basically it depends whether it's together with real-time collaboration or non-real-time collaboration let me explain how it works with non-real-time collaboration basically the module that we ship the cq editor 5 premium features comes with adapters we save those revisions in Drupal database it's not using internally the Drupal revisioning system because we didn't want to break Drupal by adding our own enhancements so we save it as a different entity in Drupal database thank you for your talk you showed us the image handling system inside the cq editor 5 does it play well with core media module and with other kind of medias I think so, because I was trying it out and it worked well basically the core Drupal team was working heavily on that and I think that it has much nicer experience than it had before with cq editor 4 so according to my knowledge it works well last one hi, thank you for good presentation how would you use that in a decoupled scenario? could you maybe render the model in a decoupled way like a graph kill or something like that you mean decoupled headless version of the editor so basically yes the code is super decoupled we have customers that use cq editor for example I don't know if you are familiar with Zendesk support it's quite a popular ticketing system they are using cq editor 5 you wouldn't notice that because they are using their own UI they used cq editor 5 engine cq editor 5 is super flexible so you can replace the UI write your own UI in React or whatever and use just the editing engine and the same with how cq editor 5 operates on the data so just like I said you can force cq editor 5 to return anything else than HTML it's up to you we actually had a prototype even of returning JSON Piotrek who is here was actually doing that for Nios CMS we didn't pursue that idea yet but this is something that we have in our minds to have this kind of proposal next to cq editor 5 so we are not going to replace our default proposal of cq editor 5 we just would like to propose something also different I watched a part of the presentation that was here before about layout builder and I would love to provide some more sophisticated features in cq editor 5 make it possible also in cq editor 5 in some way but I would also like you if you are interested in that kind of functionality to come to our booth and tell us how you envision this kind of editing experience that's it thank you everyone