 All right, so thank you everyone for coming here. I will talk today about CK Editor in Drupal 8. My name is Victor Valds. And just a few words about myself. I've been maintaining the CK Editor module for a couple of years already, for Drupal 6 and Drupal 7. And I work as a CTO for a CK source company that created CK Editor. I will talk today about the status of Wizzweek editing in Drupal 7. I will tell you about the new features that Drupal 8 offers. I will tell you a bit about some cool features inside CK Editor itself. One of them is ACF, Advanced Content Filter. And the other one is Widgets. Widgets were created actually thanks to Drupal 8 requirements. We had to introduce images with captions for Drupal 8 and we ended up with a very powerful feature called Widgets. I will tell you how to extend the functionality of CK Editor in Drupal 8 by adding your own plugins or third-party plugins that you found somewhere. I will tell you a little bit about other things like security or migration. All right, so let's start with Drupal 7. This is the default Wizzweek editor in Drupal 7. And yeah, it's very simple and fast. It has no bugs. Yeah, so when I saw it for the first time many, many years back, my reaction was like this. Yeah, but thankfully after you play with Drupal for a while you see that there are contract modules which you can install to you at some functionality on top of the core Drupal. And you have actually two very good options in Drupal 7, one of them is the Wizzweek module and the other one is CK Editor module. Both of them have their strong sites and some weak sites. And together they are quite popular. There are almost 600,000 sites running Drupal 7 together with one of them. This is awesome, but there is a problem with this. You have to spend time on things like research. You have to choose which module to use. You have two modules which has the same popularity. You have to choose which editor to use, actually. And then if you decide, for example, to use CK Editor, you have to pick up which distribution of the editor you want to use. So we spend some time on it. Then you have to install the thing that you decided to install, test it, configure it and things like that. And then you have to maintain this thing which, again, takes time. And even if you install a CK Editor module, for example, you will still face some problems. For example, you configured CK Editor, you configured it to use the image button, but after you save some content with images, you see that images are lost because you configure a CK Editor in one place and you configured text formats in another place. So there is a configuration mismatch many times. And up to recently, you had also this confusion when you installed the CK Editor module because you installed CK Editor module, but CK Editor wasn't there. So, what the, yeah. So Drupal 8, CK Editor is in core, so we don't have to search, test, install. And let's say that, I don't know, it took two hours to do some research, installation and things like that. It means that as a community, we saved almost one million hours in Drupal 8. Yeah. And we can spend it on, I don't know, writing new modules for Drupal or things like that or we can simply party. All right, so what do we have in Drupal 8? We can select any text editor, actually, and text formats and editor's administration page. You don't have to use CK Editor, we can use any other editors that will be available for Drupal 8. You have some really cool drag and drop toolbar configurator. It's really awesome, the accessibility is perfect of this tool and things like that. What's really cool is that the HTML filter settings are automatically updated when you change CK Editor configuration. And there is also really nice API that lets you register additional CK Editor plugins. So if you want to extend the features of CK Editor in core, you can do it very easily. Yeah, so I have prepared a couple of videos that show how CK Editor works in Drupal 8. This video shows how we can configure text formats in Drupal 8. Here we add the table button to the toolbar and see that the list of allowed HTML tags has been extended automatically with all the tags that are required by the table button. So you see that there are a couple of tags that you would have to place manually in the list of allowed HTML tags and it's sometimes hard. Here we add the underline button to the toolbar. See that the U element has been added automatically as well. And it works also in the opposite side. So if you remove the underline button, the element will be removed here as well. You'll see that this is not happening always. I will show you another video where this administration form will work in a little bit different way. Here we have some interesting thing. We add the styles combo, which actually comes with configuration options that you can set. So the configuration options are shown only when a feature is enabled in CK Editor. And what is really cool, you can create your own modules that provide your own plugins that extend this configuration form as well. And we added just the styles button to the toolbar, which lets you style content with classes or elements with classes. And what is really cool here that is that we just told CK Editor to use headers to style the content with some classes. And those headers from the configuration settings were added to the list of allowed HTML tags as well. And why is this happening? Or how it is happening? This is possible thanks to a hidden CK Editor instance running there behind. And Drupal contacts CK Editor asking it for the list of HTML elements that it needs. So there is a perfect connection between the administration area and CK Editor. Oh, sorry. Yeah, actually this is the end of this video. So let's move on to another slide. All right, so let's see the next video. Here we'll configure the basic toolbar and we'll add the strike element, actually S element to create strike content. Now we create some sample article with some strike text. Sorry, I don't type fast. Even for the video. All right, so it worked. Yeah, now let's try to do something nasty and let's change the text format configuration and let's remove the strike button and see what will happen. Oh, the S element is still there. Why did it happen? This is because, this is by design. This is because you already saved this text format so there is a possibility that you created already some content with the S element and if now the configuration, the scripts here that automate this stuff will remove the stack automatically, you could possibly end up with some broken content. So if you already saved the text format and you remove some buttons, if you want to disable some text you have to do it manually. And now let's see how this will affect the article that we will edit again. So see that the strike button is in there but you see still the strike text in the editor. And of course the element is still there although the button is not available. Yeah, so the content is still left there. All right, so let's move on to another slide. I will tell you now about the advanced content filter. Advanced content filter is a feature that lets you remove unwanted content in the editor. Yeah, so you can disallow certain tags and those tags will be not allowed already in the editor so if you disallow tables in the text format configuration, Siki editor will actually already remove them to provide some better wizarding experience. Of course the filters in Drupal will still remove any tags that Siki editor will leave or if you remove Siki editor and use plain text error or if you alter the post request, still the filters are there in Drupal but Siki editor by doing the same filtering straight in the editing area provides some better wizarding experience because there is no mismatch between the things that you have in the editor and the thing that you see after saving the note in Drupal. And the ACF is quite smart. If you, for example, disallow the B element but allow strong elements, Siki editor will transform this B into strong because they have more or less the same meaning. So yeah, the ACF is quite smart. And because ACF actually can strip some tags whenever you switch text format you may see such a pop-up message. Of course you will not lose any content unless you save an article but just be reminded that ACF may remove some things. Yeah, so one more video this time about ACF. So we'll add Siki editor to restricted format just to have more configurations to be shown. And now let's create some content and try to see ACF in action. Let's use the restricted HTML text format and paste some nice HTML content. Oh, sorry, I was too late. Yeah, so we are pasting in the source mode of Siki editor a script tag and some footer element. Both of them are disallowed in restricted HTML text format but it means that also Siki editor will make an attempt to remove them. So let's see and ACF will run whenever you switch from source mode to wizard mode or ACF will run whenever you paste content. So it runs in different situations. So yeah, we have script and footer. We just switch to wizard element. Let's go to wizard mode and we see that the script element has been removed completely because it doesn't make sense to keep the content of the script element when we remove the script element but the content of footer element has still some meaning and it's just a pure text. So we left the content of the footer element and replaced it with some other element that makes sense and is allowed in Siki editor. All right, so let's move on. Now let's copy some more complex data structure. This is actually some WCAG checklist and we have here headers at the top and the table with some lists inside. Now let's see what will happen if we paste it to this editor which doesn't support tables, doesn't support headers. We see that actually Siki removed almost all, actually removed these elements, I mean tables and headers but the text has been left and same with list. So we ended up with some clean structure here which still has the same meaning. Now let's switch to the basic format. Here the situation is a bit different. We allow tables and by configuring the styles combo to accept a header two and header three, we allow also headers. So let's paste content here and see that headers are left at the top and so is left the table. And ACF is enabled when HTML filter is enabled in text format. So when we switch to a text format where HTML filter is not enabled, ACF is not enabled by default and we'll see what problems it brings. And this is Chrome, we just paste content from external website where the external website was using classes to style the content to make red header and things like that. But Chrome thinks that it will be cool to actually copy all those styles to your website. So it transforms them to inline styles and creates a huge mess in your content. You see, it was actually a header with some class but when you copy it in Chrome, you end up with something like this. And it's happening in Chrome, it doesn't happen in Firefox, for example. And ACF can remove this thing. All right, so here we have Firefox. We'll do the same thing with Firefox. Yeah, we'll use the full HTML text format to use editor without ACF. We'll copy the same table and ta-da. Actually, security did the same job here and you see that the results in Chrome and Firefox are really different. So if you'd like to have the same result in Google Chrome as well, you should have ACF enabled. I'll show you later how you can do this in fact. Yeah, so the content in Firefox is much cleaner and this is just pure information that we actually wanted to copy from the external website. All right, so let's switch to another topic. Let's see what editing possibilities we have in Drupal 8. Actually, Drupal 8 comes with classic editor which you might already know because this is the default solution that is running in Drupal 6 or Drupal 7 if you install CQ Editor module and Drupal 8 comes with a very cool inline editor. And yeah, so the classic editor is used in the administration backend. So it's quite similar to the thing that you should be already familiar with. It's using iframes which means that the backend team has no effect on the styling of the editing area. And the cool thing is that in Drupal 8, frontend teams may register some style sheets to make the editable inside CQ Editor a little bit more similar to what your end users will see when you create an article. All right, so this is a classic editor in action. You see that the fonts are not exactly the same like they will be on the article when we save it. And we have quick editing option where no iframes are used. So it means that CSS styles from the surrounding website will actually be inherited by the editing area. So everything that you will edit inside the editor will look exactly the same when you save it. So this is really wizard, finally. Yeah, just to show you an example, this is an article in Drupal 8. You have a quick edit option in top right corner and when you click on it, you have the editor available and the styling of the article is the same when you enable the editor because this is the editing area. All right, so a few words about how we can style content in the editor in Drupal 8. The recommended way is to use CSS style definitions in your teams. You can define some classes to allow your users to use style content in a consistent way. When you define these classes, you can define which classes are actually enabled for the end user by using the settings form that they shown earlier. And using classes is cool because you have a semantic markup and you separate the markup from the visual presentation, actually. And this is handy because you have consistent styling on your website to work less because you don't have to search for a previous article where you use some styling and you want to use it again. It's a much better approach. Yeah, but what if your customers insist on using the color buttons, for example? There is a solution for that. But first, let me mention that the security in Drupal car is not actually a full preset, which you perhaps downloaded in the past. This is actually more a standard-like distribution where some plugins like color buttons are not available. But by using a very simple API, you can add any plugins you want to Drupal 8 and make it call for your customers. Yeah, so when you create some module that provides plugins, you can enable it as usual. And the buttons will show up, just like the buttons provided by the core distribution of CKEditor in Drupal. And ta-da, your customers can create beautiful websites again. All right. So let's switch to another topic, widgets. As I said before, widgets were introduced thanks to Drupal 8 and the requirement of having to produce images with captions. We created a prototype in two days and then ended up working on this feature for one year. Widgets are which content units that act as a single entity? I will show you later what it means, in fact. And it is really simple to provide your own widgets thanks to the generic widget plugin which provides this feature. All right, so to show you what widgets are, I will show you first how we used to do, how we used to deal with HTML structures in the past when we used templates in CKEditor. So basically templates, it was a plugin in CKEditor which allowed you to insert some HTML snippets into the editor. But the problem was that when you inserted such HTML structure, you had no control over it. It was easy to break it, delete parts of it. Of course, we had no possibility to drag and drop the structure later. And of course, this feature is not available in Drupal 8, by default. I simply mentioned it to show you the power of widgets. Yeah, so let's see templates in action. This is a dialog window provided by the templates plugin. We select here an image and title template and when you insert something like this into CKEditor, we can end up with an image on the left side, title at the top and some text about the image on the below. The problem with this is that actually there's no control over what users can enter in the title element. They can insert a table or the whole article. There is no control over the different pieces of the structure. So users could delete the image but leaving the contextual text information on the right side. So this is not cool when working with some structures which should be immutable. So, what's the solution? Of course, widgets, yeah. So with widgets you can work with those structures as a whole. We can select the whole widget, copy it, delete it. You can drag and drop a widget. You can define which parts of widgets should be editable. So we can make the whole widgets uneditable, for example. You can upcast and downcast widgets to simpler data formats. So we can represent complex structure in CKEditor but save it as something simple to possibly modify how it will look like in the future. We can provide common dialogues, context menu for widgets and provide some consistent look and feel for similar structures. Yeah, so, yeah. Widgets are cool in general. Yeah, so let's see a sample widget first to understand how they look like. This is a very simple widget that I took from our tutorial about creating widgets. When you read our tutorial, you will be able to actually create your own widget. Whenever you create a widget, you get one feature for free. It's the drag and drop handle in the top left corner. And you have a couple of other cool things in a widget. You can, as I said before, you can define which parts are actually editable in the HTML structures. Here we defined two editable parts. And you can define different ACF settings for each editable inside the structure. So here, for example, in the title, we disallowed tables, images. We just allowed some basic styling. But in the second element, we allowed using things like lists, for example. So whenever you allow your customers to insert some structures which are repeated in the contents, widgets are perfect for that. And let's see, add some more examples of widgets. Yeah, the new image plugin in Drupalite is actually a widget. We have some video here. The image plugin in Drupalite is actually using Drupal dialogues. You are free to use either Drupal dialogues or built-in CKE editor dialogue windows to write your own plugins. Yeah, we select some image here. We can redefine some alternative text. And we can set that our image comes with a caption. You can see that we have a caption here at the bottom of the image. And see that the caption actually has some ACF rules defined as well. You are not able to insert lists into a caption and things like that. And you can resize images. And you can drag and drop them. And basically, you can do the same thing with your own widgets. And yeah, this is something that I told you before. You can actually represent more complex structures in a simple form when you want to save them in a database. Here, we represented a figure element with the caption and image just as an image element with some data attributes. So if you distribute your content into multiple channels or if you want to have the possibility of changing how images with captions are rendered in the future, this is a cool way to do this. All right, so, end of the video. Yeah, let me go a little bit into, I will be more into details here. Yeah, this is the downcasted form which is saved in the database. This form is returned by Ciki Editor when you save an article or switch to the source mode. It's just an image element with some data attributes which actually holds the caption information. And the upcasted element which is shown in the editor has figure image caption elements and some div elements which wrap the whole widget which are added automatically by the widget plugin. So for example, we have the drag handler element. You don't do this by yourself, it's added automatically by the widget plugin when you create a widget. And how does it happen that the simple image element is actually replaced with, actually shown with the caption in Drupal? Drupal 8 comes with a filter caption filter which scans for all elements with data caption attribute and wraps them with such a template. So you are free to edit this template and render images with caption in your own way. And yeah, the same thing shown in a little bit different way. We have some operation that happened on the Ciki Editor side. The image is replaced with some figure and the caption elements and Ciki Editor when it returns the data back, it does the downcasting of this complex form to a simple image element. And on the Drupal side, it takes those images and again makes a complex structure from it. Sorry. One more example of widgets is the Medjax plugin. The Medjax plugin shows you a little bit different thing. It's a plugin in Ciki Editor that lets you create mathematical formulas. It's not enabled in Drupal 8 by default, but you can provide a module which enables it. And this plugin returns a span element with some latex markup inside. And what's cool here is that the Medjax library is making a mess in DOM when it works. So you can write widgets which use an iframe to actually encapsulate libraries that are troublesome for you. So you can represent a simple span element by using an iframe with a magic inside. All right, so let's see. I have just two more examples of widgets. I will not bore you that much with widgets. There is a code snippet plugin for Ciki Editor which returns a beautiful pre-element with code element inside. This plugin is using the highlight.js library. And what it does is this highlight.js library actually replaces the text information that you have in the code element with hundreds of span elements to highlight the code. So again, widgets allows you to work with a complex data structure in Ciki Editor, but it returns back a very simple data structure. And the last example regarding widgets, this is actually a sample plugin, a chart plugin that I wrote by myself while creating this presentation. I wanted to see how actually it's hard to create widgets by following our tutorials. This plugin is using the chart.js library and it returns maybe, you know, a little bit stupid element. It returns a diff element with some data attributes that lets you create a chart from it on your website again using JavaScript by using the data information from this element. And what it does internally, that this plugin in Ciki Editor is that it takes this diff element with some data attributes and it adds some canvas element to this diff element and runs chart to chart.js to actually render the chart in this canvas element. But what we actually return is just a diff element with some data attributes. So you are free to, I don't know, use a different library later to render the same chart or things like that. All right, so let me just summarize the features, the feature of widgets. We can, thanks to widgets, we can work with complex data structures that will not break. You know, as I said before, you can define editables, but you can define zero editables to make the whole widget not editable unless you make it editable with some dialog window. This is also a convenient solution for using some external JavaScript presentation libraries that even may break the DOM, then you can encapsulate them with an IFRame. You can save simpler forms if you like and render which forms in this week. When you check the simple box tutorial, you'll see that you actually save the same form that you see in Wizzweek. You are not obliged to, you know, render a different form in Wizzweek and you can return the same thing that you have in Wizzweek, actually. And of course, when you save simple forms, you can transform them using filters in Drupal, which you can change at any moment without having to, you know, do some SQL magic to replace the content if you would save the final markup otherwise. All right, so let's switch topics again. I will tell you about writing plugins. Of course, I will not explain you how to write plugins for Siketer because it's impossible in a few minutes. I will tell you how you can actually enable plugins in Drupal and how you can provide your own configuration options, which allows you to do some magic as well. All right, so, ending your plugins. First of all, you don't have to write your own plugins. You can use the one that are already available in Siketer Add-ons repository. There are over 200 plugins already available. But if you like, you can write your own plugins. You can use the Siketer plugin SDK for and see tutorials that we have there. And you can see the Siketer widget SDK where we have tutorials as well. As developers, we understood that there's this way to teach others how to create stuff is to create tutorials. If you see that some documentation is still confusing or things like that, just feel free to get in touch with us and, you know, just point us to the weakest points in our documentation. All right, so now let me show you how you can create plugins in Drupal to register Siketer plugins and how you can make them available in the text format administration interface. So the only interface that you have to implement when you provide your own module is the Siketer plugin interface. And I'm surprised how simple it is. Actually, you have to just define a couple of functions. I listed the three most important ones here. You have to define the dependencies. If your plugin depends on some other plugin, you have to just show the path to the plugin.js file, which is simple, of course. And if you want to provide some configuration settings for your plugin, you just do this by the get config function. And that's it, it's very simple. If your plugin provides a button, you have to inform the administration interface about this, and you have one function for that. It's called get buttons, and it's really simple again. If you want to provide your own configuration settings in the administration area, again, you have to just implement one function and return a simple array to provide a text area or checkboxes or whatever form elements you want to return here. And last thing, if your plugin should be enabled under certain conditions, for example, if you want to provide a list style plugin, which allows you to style HTML lists, you can use the sEnabled function to enable your plugin when, for example, the number at list button is enabled in security editor. And I'm not going to teach you how to do this. I will not dive into the API details. I created sample modules for each of the interfaces, apart from the styles combo. The styles combo plugin is actually available in core. So if you want to create your own plugins, just follow the links and you will have a really simple plugins to follow. Yeah, so you're probably surprised by the small number of configuration options for security editor that are available in Drupal 8. I think this is really cool because in security editor module for Drupal 6 and Drupal 7, I ended up with a zillion of configuration options, which are confusing at the end, I believe. Anyway, if you want to extend the list of possible configuration options in Drupal 8, you have a very simple hook provided by the editor module and you are free to do magic with this. So for example, you can set any configuration options, including security or skin. So you don't have to stick with the default skin that is in Drupal 8. You can use, for example, monocolor skin, which provides some colorful icons. Again, this is a module that I created and you can use it as an example on how to work with security in Drupal 8 and how to create your own modules. And it's one more cool thing related to this is the possibility of changing configuration options. You can actually enable ACF for, even when HTML filter is disabled. So with the simple hook, you can enable ACF even for the full HTML text format. All right, so we are reaching the end of this presentation almost. Just a few words about the security. Drupal in general stores content as is. It doesn't remove any cross-site scripting attempts when the data is saved. And this is a potential threat for WYSIWYC editors. And ACF is not a security filter. In fact, it removes elements and things like that, but it was not designed to remove cross-site scripting attempts. But thankfully, Drupal 8 is doing a similar thing to what CQEDAR module was doing for Drupal 6 and Drupal 7. It actually runs some security filters before the content is passed to CQEDAR. So you are safe and you don't have to worry about any hacking attempts using CQEDARs. All right, so last slide. Migration, I have to admit that there is no easy way to port CQEDAR profiles from Drupal 7 automatically, mainly because actually you are free to use any CQEDAR distribution you wanted to and there was a lot of options in the CQEDAR modules. So you have to somehow port your configuration from Drupal 7 manually. If you have never used CQEDAR before and you rely on things like auto-paragraph and things like that, there's a WYSIWYC line breaks module which should help you do with this. If you have never used CQEDAR before and you are worried about some markup, you can use the Migrate API. Actually, you have no other option, but you, yeah. Yeah, and if you use some custom markup, you can write plugins or widgets to allow editing it in CQEDAR. Yeah, so that's it. You can see this presentation on GitHub if you would like to check out the slides. They show to you all the sample modules and plugins that I mentioned during this presentation are available on GitHub. Feel free to follow our CQEDAR on Twitter. If you have any questions, you can contact me at Twitter or using the contact form at drupal.org. And I encourage you to leave me some feedback. I don't present often and my English is let's say weak, so yeah, I encourage you to leave some feedback. Thank you. All right, so any questions? Maybe? No, no, this is already available. Just know if you launch Drupal 8 Beta, this week you'll see everything that I showed here. I have, yeah, Wim? Do you want? Wim is actually one of the authors of the CQEDAR module in Drupal 8, so I'll let him answer maybe this question. The question was essentially, I think Victor showed the plugin contextual interface, CQEDAR plugin contextual interface, which allows you to have a CQEDAR plugin be enabled based on the context that it is in. But Kevin asked about that, whether you have a very rich context or a limited context, essentially, can you react to any sort of magical context in, for example, a URL, the current user, that sort of thing? In theory, you could probably react to the current user and current URL, but it's definitely not designed to do that. The context that you get are the settings for the text format and for the text editor. So based on however the user has configured, everything related to text editing, you can react to that. So the idea is really to enable it whether if a certain filter is enabled, for example, so if filter foos and bar are both enabled, then you show a button that allows you to control both in a meaningful manner. So it's meant to react to filters and perhaps a complex combination of certain buttons being enabled, but in general, it should be something that's necessary fairly rarely because most things are using buttons, so it's for the advanced use cases, essentially. Actually, congrats for him for providing this awesome integration with Drupal 8. I have to say something as well because as Victor has said, they developed a seek editor widgets, especially for Drupal 8, because we insisted that that would be present because we believed that it would be instrumental for you guys to have a solid framework to innovate and to make cool things that were nigh impossible to do without such a foundation. And as he said, it was prototyped roughly in two days, but it took many months to get it to a stable point, so thanks to seek editor for the big investment there. Yeah, so any other questions here? I'm sorry if I, I'm not sure the status of something, so maybe my questions are actually kind of dumb, but what's the status of like providing widgets for certain modules in Drupal 7? The seek editor, the seek editor, JavaScript, you know, the rich text editor has widgets in a version that's Drupal 7 compatible as well, I assume? As I said before, actually users had freedom with using any seek editor distribution that they wanted to. If your own module would like to rely on widgets, you can do this. I've seen some attempts of using widgets to allow users to work with complex structures like, I don't know, references to some notes inside the editor and widgets is a perfect tool for that. And yeah, you are actually free to use widgets in Drupal 7. This is why I mentioned them here, because I thought that would be useful also not only for Drupal 8 users, you will not switch immediately to Drupal 8, but you can also use widgets in Drupal 7. It's not just my ignorance of seek editor, but also maybe the status in Drupal 8, but my use case is like, you know, media elements, obviously, packages of figures with like, you know, some sort of rich tech, some sort of rich media element and then captions and various other things, and what would be the status maybe for the Drupal 7 media module and then for the Drupal 8 media solutions? Yeah, for, actually. And how does that all work together and where are we in those both those platforms? Yeah, the situation could be improved in Drupal 7, I believe. We have some issue that is pending for many months already, but I hope to give a review of a patch there. It's related to the media module. It's about making a secure module more aware of plugins, and we can also target this requirement. It might be able to hard, we should encourage users to use the CDN version which has access to all the plugins or to download CK Editor with the widget plugin because the other option that you will have actually, assuming that user has installed CK Editor without the widgets plugin, is to provide the widgets plugin with your module, but then the situation is a little bit wrong because the widgets plugin that you will provide in your module may come from different version of CK Editor that the user is using, together with the CDN module or the WISUQ module. So the most correct solution for that will be to encourage users to not use the full preset of CK Editor, but to use either the CDN version with full all or standard all, or to download a customized build with the WISUQ, sorry, with a widget plugin. I can answer one bit of that. You were asking about embedding media, for example. So the question is, can I use something like widgets and for media embedding, probably also entity embedding in general, image galleries potentially, can I use that via CK Editor widgets to have a nice editing experience, that's kind of the question. And the answer is in seven, I don't know, to be honest, if there is any work being done actively to make that work there. Precisely because as Victor is indicating, it is kind of tricky to resolve potential conflicts between different versions, because there was nothing that ships with Drupal, nor with CK Editor.module, because of licensing constraints back then. Theoretically, I guess it's possible today, but it's not really accepted to include JavaScript libraries in modules in general, on Drupal.org. So in Drupal 7, it's a bit tricky, but in Drupal 8, people who are actively working on the media module and things related to the media module there are actually implementing a CK Editor widget to easily select, so you can basically say, I wanna select a node, then you can select which node, then you can choose in which view mode to display it in, and you can even choose to display just certain fields. And the really cool thing is that then within the widget, you will not see some arcane structure that you would see today in the editor, like square brackets with a bunch of JSON in between, something like that. No, what you will see in Drupal 8 or in Drupal 7 if they port it back to Drupal 7 is the actual rendered preview of what it will look like on the front end. So you will see that, be able to click on it and then get a dialog to change it. So that's kind of, that's the target. All right, so. Hi. Thank you for an awesome job. Thanks. I want to comment on a D7 status. A little known fact is that with the D7 CK Editor module, you can actually add in plugins from like CK plugins from the URL you showed there. Add them into, and you just reference them in the config file for a CK Editor. And most of them just works out of the box, no Drupal coding needed. Also, we've been using the CK Image 2 plugin for a while, the Drupal 7. That's like the basis for the Drupal 8 implementation. Yeah. And it's actually possible to hack it in place in just a couple of hours, sort of. What we've done on a few sites is that we use the standard media module to add the inline images into the body field, just the normal way. But then we have installed the Image 2 CK plugin, so that when you double click the image inline, you get the options from Image 2 so that you can align left and right, add captions and so forth. It's just a two hour work, and it just works. Yeah. It's sweet. Thanks. Yep. We now have the new version inline editing and the iframe thing. Yeah. And about the letter, that iframe thing. Will that always be there, or is it possible to always use inline? I believe the iframe version of CK editor is there because many times the backend team is different from the frontend team. So it doesn't make sense to actually use inline editor in the administration interface because also the HTML structure that is on the frontend part of Drupal is different from the thing that you have in the backend. That's why the iframe version is used because it's much safer and it makes sense in that context. Does it answer your question, Moras? So it doesn't break any functionality to use it. If we use inline editor instead of classic editor in the administration backend. Now or in frontend, is it, does it, do you have extra functionality with the iframe? The main difference when the iframe is used is with CSS styles because when you use iframe to render the editable, the CSS styles for your content will not affect the thing that you will see in the editor. So for example, if for any weird reason you make some elements invisible like the strong element on your website, the element will be visible in the classic version of the editor, which is using an iframe because those styles will not be used there. Yeah, as I said before, there is no difference between the inline version of CK editor in general, apart from styling. Well, the slight difference might be in the list of bugs that it has. But don't tell about it to anyone. Okay, thank you. All right, next question. If not, let's just end this session and thank you once again for coming here.