CKEditor 5 support for Content Templates

What's the "Needs review" status mean in the case of this issue? My impression of the state of things is that the ckeditor plugin will not have a CKE 5 version, so this module simply won't be compatible CKE 5? -- in theory, this could become a documentation/plan issue, for providing information on the project page...?

I guess by writing a custom plugin this module could also work with CKEditor5 - but I don't see anything to review here too.

@mhespanhol, Do you already have a draft or something one could help working on?

Just to say this would be really useful. I'm building a new D9 site at the moment, and I really thought it would be easy to allow editors to insert an element (which our css renders as a sidebar) without asking them to edit the source html. I really need a module like this to achieve that.

I did trial the suggested solution of using ckeditor5_embedded_content and while it kinda worked, in a clunky way, writing a custom module for such a simple insertion felt like overkill, not to mention that for a floated sidebar, the way the embedded content area is shown in the editor doesn't line up at all, which will be confusing for people using it.

I have some hope that perhaps the CKEditor5 Style Feature can be modified to force a

tag to be converted to an tag... but have had no success yet. So ckeditor_templates for CKE5 would be deeply appreciated!

@mhespanhol that's awesome!

I'll chime in to provide some more information on potential use cases for this module / ckeditor4 content templates plugin!

My use of this module has always required the ability to add formatted content within templates, so ckeditor5_embedded_content isn't a replacement. I'd argue that Embedded Content provides a different feature, though I can understand how some uses of content templates could overlap.

One, fairly typical, use case for us is to format columns via templates. This means adding a few divs with specific classes (usually using bootstrap row + column markup) and the client replaces the placeholder text with their own content. Media can be embedded within the template using the Media Library and other templates can even be nested. We'll often create a template for a 'boxed' section (aka a div with classes that add a border, background colour, or padding, etc.) which could be used within a column, or a row of columns could be inserted within the 'boxed' section.

It's a fairly straightforward way to make the layout of a page more interesting and give the client a bit more control over their content, though it is of course a feature only requested by clients who are working with their site regularly and are motivated to experiment a little bit. Sometimes, it's just a way for us to get someone using tables as layouts to kick that habit. These templates can't be added as styles, they're just a little too complex for that, but are still simple markup that can easily be integrated in a new theme when the client wants to do a redesign.

Another way that we might use content templates is to reproduce layout components. If we're using a framework like bootstrap, we can add templates for alerts, cards, list groups, etc. to allow the user to take advantage of those components. In some cases this could be done with embedded media, but only with limitations, since we want the user to be able to format the text within these components.

Perhaps worth noting, right now the embedded content module requires a patch to core in order to function properly, which is not always possible (ie. in managed hosting environments): https://www.drupal.org/project/ckeditor5_embedded_content/issues/3306230 ✨ It is not possible to have the embedded content modal open another modal. Needs review

Which unfortunately makes it a poor replacement for a use case where the ability to embed media within templates is required.

We opened an MR with some modifications to the CKEditor Templates module to work independently from an external plugin. A few notes:

• - These changes are CKEditor 5 ready, working with Drupal 9.3+ or Drupal 10, but it is not compatible with CKEditor 4.
• - It creates all necessary files for this module to work, so people migrating from the previous version might want to delete the "templates" in the "libraries" folder afterward.
• - The templates can be managed in the config page /admin/config/content/ckeditor-templates (see the updated README.txt file for more info), so you might delete the templates/ckeditor_templates.js file after setting them inside the new structure.

Excellent news @mhespanhol ! I am looking forward to trying it!

The MR looks almost exactly as I imagined it :D

If the maintainers agree on the general approach can we create a new 2.x branch for a CKEditor5 compatible version of this module?

Thank you @mhespanhol for all the work.

I understand alternatives are not ideal for everyone and some contrib prefer flexibility over maintenance (which is always relative on depends on each website context).
So let's upgrade this module !

I updated the project page to explain the current Drupal 10 situation, created a 2.x branch and set it as target for the merge request.
Now, we need to test and review this new version.

I only had a quick look but I have two comments for now :
- is the licence file required ? All modules hosted on Drupal.org have to follow Drupal licence + the licence file is automatically generated and added when downloading the module or installing via composer.
- is using webpack and yarn required to develop the CKEditor plugin ? It adds quite a lot of complexity for such a simple need.
I even asked myselft if the CKEditor plugin should be deliver with this module or hosted on CKeditor platform ? For sure, it is easier to install when bundle together but could it be of any use for people using CKeditor outside of Drupal, who were using the Template plugin ?

@lucaslg, the license file is not required. It can be removed from the repository.

As for Webpack, we used that for developing the CKEditor 5 plugin, following their recommendation. So it is only necessary if people are going to tweak the CKEditor 5 plugin, but the Drupal module doesn't need it to work.

I agree that having the Templates plugin available for CKEditor 5 would be nice, but that was never our goal for this project. The plugin we created has only the minimum requirement to connect Drupal to CKEditor, and most of the Templates functionality is now coded inside Drupal. Therefore, the CKEditor 5 plugin for this module is only useful with the Drupal plugin.

I tested the latest MR 4 on a Drupal 9.5.2 site with CKEditor 5 enabled, and it looked good! I was able to add the Templates button to my CKE5 toolbar, created several test templates at /admin/config/content/ckeditor-templates, was able to insert them into content.

The only issue I saw, which may be specific to my setup, was that after clicking "Insert" on the Template pop-up, I was jumped to the bottom of the node edit screen, and had to scroll back up to my Body field with CKE5.

I have been doing some changes so that my client can finish their upgrade to CKEditor 5.

It is now pretty much working really well and I am about to pass this onto testers.

1 issue I have is that the templates are being loaded via AJAX. We should add this as a part of DrupalSettings which will mean it will be loaded much faster and make the 5 plugin experience the same the 4 plugin.

@gordon, love your approach here. We too want to follow your workflow of using both CKEditor 4 and 5 for a time. We'd like to be transitioned over before we upgrade to Drupal 10.

Hey @gordon, the patch is fantastic. Thanks for your hard work.
There is an issue with the insert button.
If I create a `blockquote` element, the cursor can't move to the following line, in fact, my mouse cursor will be stuck inside the `blockquote` element.

This quick and simple patch is just for my user cases.

Is this a CKEditor issue? I mean the same thing happens when one upcasts this html right?

I was unable to apply the patch from the MR to the composer installed module on my site due to a conflict between the .info.yml changes in the MR and the .info.yml changes automatically added to Drupal packages. I generated a patch that makes the same changes as the MR (I didn't include yovince's change from above) but works against the auto-generated .info.yml file for use with composer.

The changes in this patch should not be added to the MR, but may be useful to others trying to patch the module before this is merged in and tagged.

I also noticed that this patch applies a D10 compatibility change (changing the core_version_requirement) but does not apply other D10 compatibility changes (replacing drupal_get_path which no longer exists in D10). It is currently in a broken state because of this - my D10 site now has fatal errors on many/all pages after clearing caches.

There is an issue for automated D10 fixes at https://www.drupal.org/project/ckeditor_templates/issues/3296778 📌 Automated Drupal 10 compatibility fixes RTBC which fixes this issue, but it conflicts with this patch because of the above.

As I see it this could be resolved in two ways - by either removing the D10 compatibility change from this patch or bringing in the other D10 compatibility fixes. Since this patch is for CKEditor5 compatibility and that technically does not require D10 compatibility I've done the former.

I've also attached an updated composer patch.

That still leaves a small conflict so here's another updated composer patch.

I have found a pretty major problem. I am not sure how to fix it.

Basically if you load up ckeditor inside layout builder the css template doesn't get applied.

I checked and it is being loaded, but not in a way, that the ajax will not reload, but it is not being treated as css.

@yovince Can you explain your patch a little, does it just add a line break after the template?

I have figured out the problem that I am having with the CSS not being applied.

Basically for me, in a standard node edit page the radios element uses (for me) the clario form-radios.html.twig template which adds the class form-radios. When using CKEditor in layout builder it is using the stable form-radios.html.twig.

I am not sure if this will be an issue for 10.x but it is an issue for 9.x

I have fixed the issue with the styling not being applied as I described in #45.

Basically the class form-radios cannot be depended on as some of the base themes do not add this class (stable and stable9) and some do.

The second problem is that the radios theme doesn't support #wrapper_attributes so I have had to add a hack to add support for this so we can add a new class form-radios--templates which we can target instead of form-radios.

I have attached the patch, but I have excluded the last couple of patches as I was not being able to apply these patches.

I have raised an issue against core for the lack of support #wrapper_attributes see #3352581 which explains this.

I found an issue with different themes having different classes on the form element wrapper so the selector was not always targeting it correctly.

After some investigation I found that the best classes to target are the js- prefix classes which seem to be on all the core themes that I checked. So I have cleaned up selectors on the dialog to use the js prefixed versions and reduced the selectors to only one.

I have found another issue. Not sure if this is a big one but it will cause problems.

CKEditor 5 is much more integrated than what 4 was. Eg. when you add buttons it will upload the allowed HTML tags will get updated. This is great however when you add in a template we need to add in the tags the template uses into the allowed tags. Basically what happens is the tag just disappears.

eg.

<blockquote>
  &ldquo;The quote.&rdquo;
  <cite>The citation (optional).</cite>
</blockquote>

So we have the blockquote added to the allowed tags, however we did not have the cite tag so it was just stripped.

I am not sure if we need to do anything for this. or we need to update the filters which we have connected the template to. I did run into another issue when I tried to add in the (in my case) cite tag and I was unable to edit the allowed tags. I have not done the additional investigation but I suspect ckeditor5 is stopping this.

@gordon You can't edit the allowed tags directly, but you can add them to the "Source editing" field in the settings below the toolbar buttons.

Folks creating template markup need to make sure all their tags are represented in that field.

Not sure if I do anything wrong but I can only apply patch #40 and #41 onto version 1.2.0. None of other patches including the MR can be applied with composer.

OK I added @gordon's changes fro #46-#48 to the PR this seemed to work just fine.

I also added a ckeditor-template annotation plugin because even though having templates stored in config-entities is a reasonable decision I can think of scenarios where this is suboptimal (Some might want to use content entities or files etc...). Also this gives a handy place for some logic that was previously in the dialog form. To keep the config entities working I added a deriver that adds a ckeditor-template for each config. So for the user shouldn't change anything. This is a well known approach in drupal used in many places (content-blocks block fields etc.).

I also had a deeper look at the other code and found some things I'd like to discuss:

1. The config entity has the ID "ckeditor_templates" - I think we typically use the singular here
2. The thumb of the config entity has the type: sequence in the schema - Is there a reason for that?
3. I think we should introduce getter in the config entity to avoid the nasty ->get('xy') ?? '' everywhere

@sonnykt, This is still under heavy development. If you still want to try it you can clone the MR (https://git.drupalcode.org/issue/ckeditor_templates-3273358.git) and checkout the issue's branch.

@lucaslg, What would you like to see before we can merge this into 2.x? I'm asking because it would make things much easier if we could work in separate issues.

@Halor I noticed that ckeditor_templates config entities capture the File ID of the image for thumb. I don't think that storing the incremental ID in config is a good practice. It's not an easy task to keep the FID in sync between different environments.

Previously, the CKEditor Template UI module stores the path of the image. Other module such as paragraph stores the UUID of the icon and/or the base64-encoded version of the image.

Just adding for reference, CKEditor5 is supporting their own template implementation, but it is a premium add on, not an open source feature (see https://ckeditor.com/docs/ckeditor5/latest/features/template.html).

@subashgandu, Oh very good point! Opinions which of the two options is preferable?

@kmonty, Ah I think that's a new feature! Even though #2 is no longer true a open-source implementation in drupal still has its benefits.

@Harlor hopefully you get this notification as I think other comments misspelled your handle...would be nice if drupal.org helped us complete usernames, but oh well. This thread has a few missed comments where people were one/two letters off the actual screen name. I will also ping @sonnykt as I think you meant to ask them a question.

But my main question is if your MR is good to be reviewed since you moved the status from "Needs Review" to "Needs Work"?

I'm trying to familiarize myself with the module now, but I can help review it if you are paused. I just don't want to look too hard if you are planning to add updates soon.

@afinnarn, There is a username completion ;)

Did I miss something? I changes the status to needs work because there are at least the issues mentioned in #52 and #53.

Also I think we need to install the new entity type:

/**
 * Update 9001 - Install the ckeditor_templates entity.
 */
function ckeditor_templates_update_9001() {
  \Drupal::entityTypeManager()->clearCachedDefinitions();
  \Drupal::entityDefinitionUpdateManager()->installEntityType(\Drupal::entityTypeManager()->getDefinition('ckeditor_templates'));
}

randy Tang → made their first commit to this issue’s fork.

The permission "use text format advanced" is available when a text format config entity "advanced" is available.
I think create a custom permission with "use text format advanced" syntax is not a good idea.

You can create a custom permission like "use ckeditor templates" if you want to manage a special access to the ckeditor button.

I made a patch for the code as of 2023.06.20 to apply to version 1.2. It should be noted that I submitted two commits, one was added
“# Information added by Drupal.org packaging script on 2020-09-27
version: '8.x-1.2'
project: 'ckeditor_templates'
datestamp: 1601232519”
The second time is to support the code of D10, and the patch is also submitted based on the second commit.

You also need to add "drupal/ckeditor_templates": "-p1" in patchLevel

I committed a change on the access to the route. Don't hesitate to tell me if you don't like it.

The webpack.config.js was missing from the previous patch

#64 patch working well on Drupal 10 (PHP 8.1)

This is mostly working well for me testing locally on Drupal 9.5.8 and php 8.1.

But I'm getting an error from not having a 'Illustrative Image/Icon', aka ''thumb', for any given template. That or the alternative field seems to be required, however the error I was getting from the console after clicking on the button is coming from ckeditor_templates/src/Plugin/CkeditorTemplate/ConfigTemplate.php on line 95 which is

$thumb = $this->ckeditorTemplateConfig->get('thumb')[0];

So we need a check for that value, and/or requiring the thumb field when creating a template.

Once I added an image to all my templates everything seems to be working fine.

I've created a patch off of #64. In my comment above, the relevant line:

$thumb = $this->ckeditorTemplateConfig->get('thumb')[0];

Was throwing a console error locally if there was no thumbnail icon selected for a template, since there was no [0] index in the array to reference. In my patch, I simply amended the line to be

$thumb = $this->ckeditorTemplateConfig->get('thumb')[0] ?? '';

The rest of the code correctly handles $thumb being '' if no thumbnail is selected for the template.

I was having trouble generating my patch above, which doesn't seem to be working for me (for ckeditor_templates version 8.x-1.2).
So I literally just modified the patch file in #64 with my relevant change. You can feel free to delete my above comment. (#68).
Here is the comment again to make deleting my above comment easier.

I've created a patch off of #64. In my comment above, the relevant line:

$thumb = $this->ckeditorTemplateConfig->get('thumb')[0];

Was throwing a console error locally if there was no thumbnail icon selected for a template, since there was no [0] index in the array to reference. In my patch, I simply amended the line to be

$thumb = $this->ckeditorTemplateConfig->get('thumb')[0] ?? '';

The rest of the code correctly handles $thumb being '' if no thumbnail is selected for the template.

Added widget functionality to all templates

Added widget functionality to all templates.

There is another lightweight module in dev which covers the need of supporting CK5 and D10.

For me this is working perfectly!

https://www.drupal.org/project/ckeditor5_template →

Add translation of code.

I added #68 on the basis of #70

Warning: Undefined array key 0 in Drupal\ckeditor_templates\Plugin\CkeditorTemplate\ConfigTemplate->getThumb()

Fixed warning: Undefined array key 0,Warning: Undefined array key 0 in Drupal\ckeditor_templates\Plugin\CkeditorTemplate\ConfigTemplate->getThumb()

I have not looked at this issue in a while and it was a huge mess. There was no way to see the changes made as there were no interdiffs created making it very hard to track.

I have spent some time going though all the patches and merging them all into !MR4 so we can see the changes. Also I have removed all the Drupal 10 compatibility changes from 📌 Automated Drupal 10 compatibility fixes RTBC as this is not related to this issue. But we do need to make sure that any new code here should be D10 compatible Also the one line patches that were being uploaded we not being loaded into the larger patches and had actually already been fixed in !MR4 which made things difficult.

Thank you both @devanbicher and @mark-shi for your work. If you can check the changes I committed to !MR4 from your patches and make sure I didn't break it too much would be really great.

Also if we can do any additional development is the issue fork would make it so much easier moving forward. I know it is not easy with composer but this is important work and the goal is to get ckeditor_templates working for CK5 and released. If we have to create local patches for our sites that is a small price.

@gordon nice job patching this all together in an MR, thanks. As you can see above I added another commit that will introduce an update hook to migrate existing templates of the ckeditor_templates_ui module which will be obsolete once this MR lands.

The update hook will migrate all templates and enable them in all enabled text formats. If this needs to be more granular, an update hook may not be the right solution and a form which one could select the templates and formats the templates should be enabled in could be the way to go. However this isn't great if you need an automated migration during a deployment and thus I abandoned the form idea. The code for it could still be found here if that's interesting for anybody: https://git.drupalcode.org/issue/ckeditor_templates-3273358/-/blob/35d96370ad9f32d7c822d99a730fd9d83e7bdf04/src/Form/MigrateCkeditorTemplatesUiForm.php (it's in a separate branch, not part of MR4)

Fixed the problem of scrolling to the bottom of the page after adding template based on #70 and add code form #79 patch

@mark-shi I am not sure what you did in #83, I went to merge this into the issue branch but there ended up being no changes. In fact this was not a complete patch as there were other changes which were not included.

Your contribution is appreciated but please use the issue fork as described here →

This is a complex change and colborating via the issue fork will make things a lot easier.

Updating issue status with what I see as the remaining steps.

Morning everyone. Do you have any suggestions on preventing adding a template from taking you away from the field you're editing?
https://www.drupal.org/files/issues/2023-09-01/CleanShot%202023-09-01%20... →

@yovince

Temporary you can use this module.
It just adds the template to the curser location:

https://www.drupal.org/project/ckeditor5_template →

BR
Daniel

Thanks! @dbielke1986

I removed the migration as suggested in the MR comment ✨ CKEditor 5 support for Content Templates Needs review as there was more to add to it. It's now available in a separate module over at https://www.drupal.org/project/ckeditor_templates_upgrade →

Just want to thank everyone for this work which is mostly way above my head. Crossing my fingers and toes we get there soon.

Updated patch file for failing on info.yml file and having rich text editor field for HTM Code field on entity add/edit form.

Applied patch #91. It works correctly +1 RTBC

I have rerolled this patch as it conflicts with the Drupal 10 upgrade patch. Bascially I have reverted the info.yml and removed the composer.json so both patches can be applied.

For me, using D10, php 8.1 the above 2 patches don't work, I tried 91 in combination with the D10 upgrade patch but also couldn't get it to apply after several attempts with some of the D10 patches.

But anyway the relevant issue with patch #93 is when trying to edit an existing template I get the following error:

TypeError: Cannot access offset of type string on string in Drupal\ckeditor_templates\Form\CKEditorTemplatesEntityForm->form() (line 136 of modules/contrib/ckeditor_templates/src/Form/CKEditorTemplatesEntityForm.php).

Same as @gordon in #93

But fixing

Hunk #1 FAILED at 172.
1 out of 1 hunk FAILED -- saving rejects to file src/Plugin/CKEditorPlugin/CkeditorTemplates.php.rej

That is in #3296778-28: Automated Drupal 10 compatibility fixes →
https://www.drupal.org/files/issues/2023-10-23/ckeditor_templates_d10_32... →

changes added D10 compatibility changes into info.yml file

Just going to note that the latest patch there seems to be bugs in it, there are missing properties in the entity (from a quick look) and I cannot insert templates.

I first applied the D10 patch - https://www.drupal.org/comment/15285058#comment-15285058 →
Then the patch from - https://www.drupal.org/files/issues/2023-10-27/3273358-95.patch →

Updated entity to match structure, added in property types and removed `getHtml` method (unused, outdated method).

The patch "3273358-99.patch" works pretty well for me :-)
on ck5/D9 before switching to D10 very soon...
Thanks

Tried patch #99 on D10 and can create, save add templates.
Thank you @RichardGaunt

Can confirm that patch #99 isn't working for me, but insead #91 works fine.

I have implemented two ways of templates:
1. programmatically implemented template
2. template by configuration within UI.

If I delete the template made by UI, I don't have access to the programmatically created one.
Using the template made by UI it works as intended.

If you have any questions or if I'm wrong with something, pls tell me :)

Patch #99 worked for me as well, but it seems that there is no upgrade path for templates made in CK4, as our previous content is not editable (nor viewable in the editor, but it does show on the page).

Could one o the maintainers please specify what is missing to use the current state of this issue as a base for a CKE5 compatible version of this module?

@Mysdiir, for me, #99 didn't work on its own, it needed to be applied together with the Drupal 10 patch: https://www.drupal.org/comment/15285058#comment-15285058 → maybe that was the issue for you?

Can I just say this is working great for me... thank you all for your work... I hope it gets merged good and proper!

The changes in #91 converting the code field are not working for me.

The following error is produced:

`Cannot assign string to property Drupal\\ckeditor_templates\\Entity\\CKEditorTemplates::$code of type array in Drupal\\Core\\Entity\\EntityBase->__construct() (line 63 of core/lib/Drupal/Core/Entity/EntityBase.php).`

In this patch that change is undone and it now aligns with the MR. N.B. there are some other diffs between these patches and the MR such as README.md/txt

@klidifia that issue is probably due to pre existing configuration that was generated before the change from plain text to formatted text? Could try resave or update the config manually to be formatted text?

This issue jumps between MR and patch workflow with no interdiffs on many patches - its very hard to keep track. Around comment #80 there was effort put in to consolidate the patches into an MR however its gone back to patches now.

Completely agree with ericgsmith, it's super hard to keep track of the changes posted in various patches without interdiffs, whereas it would have been a lot easier if people could have just used the MR. It's not only easier to keep track, it obviously eliminates the need for interdiffs and makes code reviews and feedback much more convenient. It is what it is though, so I'm posting my latest changes in a patch too.

Also @klidifia, ericgsmith is right about this being a problem with your config that was exported prior to the change added in #91, I have the same problem. It can be fixed by editing the config manually and then re-importing it, but you'll need the changes I'm posting in a separate patch here in support_for_old_codefield_config_scheme.patch. This patch is NOT to be committed but just helps in the described scenario.

The actual change in the new patch I'm adding is that it's based on the latest commit in the D10 compatibility issue 📌 Automated Drupal 10 compatibility fixes RTBC and it changes the dependency inside the info file to ckeditor5.

I am facing issue to display the newly created template on ckeditor. So updated cache clear for ckeditor template plugin

@deepaverma please read https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... →

Its too hard to know what you are changing without an interdiff. It also appears you did not start your patch from #109 as the most recent changes (#99 and #109) are missing from your patch?

Hello everyone, I'm the maintainer of ckeditor_templates_ui → module, I'm just waiting for this issue to be fixed to complete the Ckeditor 5 integration with my module, no need to add this feature to this module.

Related issue 📌 Support ckeditor 5? Postponed

ericgsmith & s_leu yes. thank you! (108/109) - the pre-existing config was the issue and the schema patch in 109 helped resolve it.

I encountered a separate issue due to the wrapping around the inserted template with the section and div wrapper (my issue was that the section markup produces another insertbefore arrow in ckeditor) - I am thinking that this wrapper is not needed and hence if so some of the code can be removed, I include a patch with the intent.

@klidifia I think that change looks good - I agree that there doesn't seem to be a need to have multiple wrappers around the template and the editors get a better experience without seeing that double return block.

I missed a few things from previous review, having another look at this

1. +++ b/ckeditor_templates.permissions.yml
   @@ -0,0 +1,6 @@
   +use text format advanced:
   

   This permission looks wrong? Should the be something clear like "insert ckeditor templates"?

2. +++ b/js/ckeditor5_plugins/ckeditor_templates/src/ckeditorTemplatesCommand.js
   @@ -0,0 +1,30 @@
   +        editor.data.set(htmlCode);
   

   The use of set appears to result in the undo button not working. I don't think we need to do anything about this now - but its worth noting. Hopefully if this can be committed to a dev branch soon we can start opening this kind of thing up as a follow on issue.

3. +++ b/js/ckeditor5_plugins/ckeditor_templates/src/ckeditorTemplatesEditing.js
   @@ -0,0 +1,27 @@
   +      "ckeditorTemplates",
   

   Nitpick - diff between using ' and " in previous file

4. +++ b/src/Form/CKEditorTemplatesDialogForm.php
   @@ -0,0 +1,181 @@
   +    $this->ckeditorTemplateManager = $ckeditor_template_plugin_manager;
   

   I might be missing something here - but this feels overly complicated to have a plugin system involved?

   Is there a reason for introducing plugin + plugin deriver to map the config entities to plugins? Would it be simpler to just use the entity type manager and load the config entities?

   This is just a question now - probably for the original author to clarify?

@Anas_maw - it looks like a decision was made early on to use Drupal config entities for the templates and for Drupal to render the form - which means the patch so far includes a UI for the config entities it creates.

There was a suggestion early on in #31 to "externalize" the plugin which would require a native CKEditor form reading from the ckeditor plguin config - but as it currently stands Drupal provides / renders the form to select the template rather than the plugin - so the source of the data is already in Drupal. So I think if that approach is what is going to continue, it would be awesome for you to review the above and UI aspects of this MR? I am not a maintainer, that is just my assumption / understanding of the work so far.

I'm setting to needs work based on point 1. I think given how much code exists at the moment, point 4 is more a question than anything.

Just a note to say this is working really well and I like the UI.

In regards to points 1 and 3 from 115 -- used appropriate permission: "insert ckeditor permission" and the parameters.

Replaced the various inconsistent double quotes with singles.

@klidifia
Which version of the module was used to apply the patch 3273358-117-ckeditor-5-support-for-content-templates.patch
I am trying to apply this to version ckeditor_templates:^1.3 but getting an error that the patch can't be applied.

@khaldoon_masud you should use the 8.x-1.x-dev version, which at this time is identical to the 8.x-1.3 release version (save for the automatic package additions to the module info.yml file).

I tested the latest patch in comment #117 and it works great!

Thanks @klidifia!

Permission change looks sensible and resolves the comment originally raised in #61

Looks like there is plenty of people using this patch and reporting favorably - I'm in favour of RTBC'ing this.

In further testing with the patch, it doesn't seem to gracefully fail when a user has access to the CKEditor5-enabled text format, but doesn't have a role with the "Insert CKEditor Templates Allow user to insert ckeditor templates" permission. The button silently doesn't work/do anything and throws an AJAX error in the browser console.

Drupal.AjaxError {message: '\nAn AJAX HTTP error occurred.\nHTTP Result Code: 40…keditor templates\\u0027 permission is required."}', name: 'AjaxError', stack: 'Error\n at https://example.com/site…srpiiF1hjvyiFFDjy_jB1pTW_XUY7ls_gMdePQq:260:19298'}

I didn't notice before, I seem to have missed these Drupal messages at the top of the edit form. I guess the patch does gracefully fail.

I notice there was also a commit to the MR at some point in comment #63 which use the editor access instead of a new permission https://git.drupalcode.org/project/ckeditor_templates/-/merge_requests/4...

It appears this got lost for now reason at #69 - one of the issues with not posting interdiffs.

Haven't tested that but that also looks like a good approach and reduces the need for additional permissions 👍

I kind of fear more stuff may have been lost in some of these patches without explanations or interdiffs but at this point I'm happily using #117.

Has anyone used the patch with Drupal 10.2? I'm curious whether the change introduced in 3396628 🐛 Fix → native CKEditor 5 functionality and fix bug in SourceEditingRedundantTagsConstraintValidator that allowed it to slip by Fixed impacts the ability to create and use a template with <div> and classes.

FYI There is also a separate module for ckeditor 5 https://www.drupal.org/project/ckeditor5_template →

I'm also facing a problem in 10.2 with 8.x-1.dev (as metioned in #119: Add book navigation links to non 'book page' nodes → ( https://www.drupal.org/project/ckeditor_templates/issues/3273358#comment... ✨ CKEditor 5 support for Content Templates Needs review )
When adding a template to `/admin/config/content/ckeditor-templates/foo', CKEditor will cut off the `div` container in the rendered output.

I double checked my settings and even tried to manipulate the `config.yml` itself but it doesn't show the results I expected.

I wonder why are you using a CKE editor to get to the values of the HTML code you want to use as template? Are there any important differences to a text block field type?

Thanks for the heads up. I've been postponing upgrading to 10.2 until I can adequately test stuff and this module/patch was the top of my list of concerns!

Tushar1 → closed merge request !7

I am not able to apply patch from the MR since its 1 commit behind, I think we need rebase the MR.

Several people reporting issues. Moving back to Needs Work.

So, I was using an early patch before and it was working fine, but now I've tried to update to the dev version of the module and use patch #117.
This is the error I get on the console:

Object { message: "An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /admin/config/content/ckeditor-templates/template-selector/full_html StatusText: 500 Service unavailable (with message)
ResponseText: The website encountered an unexpected error. Try again later.
TypeError: Cannot assign string to property Drupal\ckeditor_templates\Entity\CKEditorTemplates::$code of type array in Drupal\Core\Entity\\EntityBase->__construct() (line 63 of core/lib/Drupal/Core/Entity/EntityBase.php).

Seems that $code should be an array with format and value but it's being passed as a string. I cannot even open the dialog to see the templates available.

@bbombachini I believe that error is when you need to update your templates to the new version that was implemented later along in this thread. It's a manual process to update.

Thanks @RichardGaunt, updating manually was a bit of a pain. I had to use the temporary patch on #109 ✨ CKEditor 5 support for Content Templates Needs review and I've deleted them before recreating.

I had an error that when re-saving content without a thumb_alternative value, it was saving as thumb_alternative: null and that was invalid, import would fail, then I couldn't delete the config.

Another issue I'm currently having is that if I add a div with 3 columns for ex, there's no way for me to add a paragraph after the template. I can hit enter and add as many paragraphs as I want, but I'd still be inside the template. I think we're missing the implementation of these handlers that we see on media embed:

I am able to apply the patch using MR (https://git.drupalcode.org/project/ckeditor_templates/-/merge_requests/4...) and has to run the following command.

composer require drupal/ckeditor_templates:1.2.0 --prefer-source

It seems to be working fine, I have manually re-created all the ckeditor4 templates to ckeditor5.

@bbombachini I am facing the same issue with not able to add a paragraph after the template. When I researched about it this comes from the plugin called "magicline" for CKEditor4, there is no plugin ported for CKEditor5. Please do let me know if you find anything that works for CK 5
https://github.com/ckeditor/ckeditor4/tree/master/plugins/magicline

This "trapped cursor" thing is an issue with CKEditor 5 in general, as reported here in core: [GHS] Allow the cursor to leave 🐛 [GHS] Allow the cursor to leave s and other HTML elements at document start or end Postponed: needs info

Couple of small additions:

• Changed the schema type of the description field to text in order to make it translatable
• Added an update hook to install the entity type definition as noted in #57 ✨ CKEditor 5 support for Content Templates Needs review

Hi @imran1217 , I have also faced the same issue, I'm using the solution proposed by you. But, there is a problem if we use the --prefer-source option it is starting to track the files based on git, which is not-recommended for the client-project. To resolve that, we need to add the following lines inside the config and repository key of the composer.json file respectively.

"preferred-install": {
            "drupal/ckeditor_templates": "source"
        },

"ckeditor_templates": {
            "type": "vcs",
            "url": "https://github.com/drupal/ckeditor_templates.git"
        },

Alternatively, I have found that there is a little problem in the patch or MR we are using here which reproduces the issue mentioned in #136. I'm attaching here the updated patch also. Please verify whether the issue of applying patch is resolved or not.

Thanks !

At some point clearing the plugin cache was removed from the save method on the form - not an issue for deployed config but it means when developing locally you need to clear the cache before seeing new templates, and if you delete templates you get a 500 error as it tries to load a plugin for an entity that no longer exists.

Yes, see also ✨ Always detect changes in template file Closed: cannot reproduce .

Found an additional issue - when using a lot of templates the dialog appear to open at the end of the list, not the start as expected.

+++ b/js/ckeditor5_plugins/ckeditor_templates/sass/dialog.scss
@@ -0,0 +1,47 @@
+        display: none;

This is what is breaking the auto focusing on the dialog - when the dialog is opened it can't focus on the first radio button, so focusses on the checkbox creating a confusing scroll to the end of the list for the user

Noticed that when loading the template dialog form in CKEditor the template definitions get cached in the first language they're loaded under and do not update when switching languages. This switches to using a language-specific cache key in the CkeditorTemplatePluginManager

There have been several new patches since this was set to "Needs work", it would be helpful to get some new feedback.

Latest module release required the patch to be rerolled. Attached w/interdiff.

Hi all, great work here. Especially the addition of "Added widget functionality to all templates" to end the cursor horror.

We were still facing one issue tho and that was the scroll to the bottom of the page after clicking 'Insert'.

I fixed it by adding the following to the insert button: (see commit above)
'disable-refocus' => TRUE

I can't seem to use the latest MR (cannot apply diff as patch), however the patch at #3273358-146: CKEditor 5 support for Content Templates → applies correctly to latest DEV release and appears to function correctly. Thanks for everyone's work on this - it's a great module.

Worth pointing out this alternative module: https://www.drupal.org/project/ckeditor5_template → - similar functionality (and D10+ ready), but doesn't have a UI to create templates: the templates are built in a JSON file with embedded HTML.

@Falco010, there is a core patch for 'disable-refocus' => TRUE. I believe I've triggered that cursor refocus in more cases than just CKEditor5 as a part of using the media library on a entity reference field.

See #3415961 🐛 [drupalMedia] Using the Insert Media button causes the window to scroll to the bottom of the page Needs work .

Here is my attempt at the requested review from @mandclu. This issue is definitely a bit confusing to follow with both the patches and the merge request.

The latest patch in #146 applies cleanly to the latest release, 8.x-1.4. In my tests, it works well.

The merge request is against the 8.x-2.x dev branch. Which doesn't have a release and is not the default dev branch. I have not been able to get it to successfully install with composer.

The merge request seems to make some different choices than the latest patch other than the base branch.

• The format of the README.md is a little different (minor).
• The patch declares core_version_requirement: ^9.3 || ^10 || ^11 while the merge request shows core_version_requirement: ^8 || ^9 || ^10.
• The patch includes an update hook.
• The patch adds a permission called insert ckeditor templates. The merge request adds a permission called use text format advanced.
• The patch adds some language management that the merge request does not.
• The merge request adds an upcast and downcast in /js/ckeditor5_plugins/ckeditor_templates/src/ckeditorTemplatesCommand.js that adds the widget type around handles to add a new line before or after the inserted template.
• The merge request includes code formatting changes in /src/Plugin/CKEditorPlugin/CkeditorTemplates.php.
• The patch properly types attributes in /src/Entity/CKEditorTemplates.php but the merge request has a save() function in that same file that clears cache definitions when a template is saved.
• There are a few spots in the patch that set the form fields as text_format where the merge request opts for textarea and string.

@mandclu (or another maintainer), should that merge-request be against the 8.x-1.x branch? And if so, how would we resolve which of the slightly different approaches should make it into the accepted merge request.

The sweet spot for me would likely be a new merge request against 8.x-1.x that is mostly the patch from #146 with the addtion of the type around widgets getting added to the templates if those work well. I've not been able to test them as I personally haven't found a way to get the merge request to apply.

Thoughts?

Thank you @joshuami for the detailed summary, that is very much appreciated for somebody who is trying to keep track of this monster 😅

This issue has faced many challenges due to dancing between patches and MRs - for big changes like this MRs are fantastic for keeping track of issues and feedback that gets lost along the way with patches. Unfortunately multiple attempts to move the patch to MR end up with patches reappearing without interdiffs, and then MR becoming stale. The MR has the latest commit, but misses 7 months of development between #91 to now. I am hesitant to keep trying to work in the MR if it just leads to more maintenance when people start uploading patches again but its really hard to keep track of every reported issue in these 150 comments.

I just want something committed to a dev branch so we can open up remaining niggles as follow up issues - make them easier to review and ensure we are not reintroducing issues already fixed.

What do people thing about:

1. Create a new 2.x branch or update the 8.x-2.x branch with the changes committed to 1.x
2. Create the MR as @joshuami suggests
3. Commit to the dev branch and be realistic about some features being added as new follow up issues

I think that will make it easier to drive this forward.

Things like the widget functionality - there are arguments both for and against in is thread, and a good suggestion to make it configurable. Why not merge what we have a keep that conversation going in a dedicated issue.

ericgsmith → changed the visibility of the branch 3273358-ck5 to hidden.

ericgsmith → changed the visibility of the branch ckeditor_templates-3273358-3273358-ckeditor-5-support to hidden.

ericgsmith → changed the visibility of the branch ckeditor_templates_ui_migration-3273358 to hidden.

That'd be awesome @ericgsmith. I think that would resolve a great deal.

Having a 2.x branch makes most sense to me - as different issues can be raised with reference to that branch, so they can be tackled individually; balancing lots of different interests in single thread has been a lot!

@joshuami's suggestion looks good too!

Having an issue branch for the widget functionality (and any other contested feature) would also mean that while in development that those who do want that functionality can access it as a standalone patch.

I've tried to go with @joshuami suggestion of a new MR based on the patch, as I found an additional bug that I needed to fix for a client - but I wanted to keep some of the stuff that was only in the MR and not just the patch.

I don't want to confuse the issue further - but this is what I did:

• Applied the patch from MR4 to a new branch from 8.x-1.x (A)
• Applied the patch from #146 to a new branch from 8.x-1.x (B)
• Cherry picked from B into A to get the changes from the patch into A
• Added additional commits to B and pushed as mr4-with-patch-146

The merge request adds an upcast and downcast in /js/ckeditor5_plugins/ckeditor_templates/src/ckeditorTemplatesCommand.js that adds the widget type around handles to add a new line before or after the inserted template.

This is still missing from mr4-with-patch-146 - I'm still in favor of adding this back if its configurable.

As previously mentioned - this is a big beast, the last thing I wanted to do was add more confusion the the issue with another MR, but hopefully this is the consolidation between MR and patch that can push the issue forward. Setting to needs review - would appreciate if the approach to use this new branch is acceptable we can hide the patches and old branch.

Previously, this module recommended using ckeditor_templates_ui (there is a link still present on the project page). The work on this issue includes all of the UI features from that module, plus more, at slightly different URLs in the Admin > Configuration section.

Currently, the module does nothing to tell the user there are two UIs, and we hit this issue and ended up super confused.

Therefore, I'm setting this to NW to add an hook_update_n to uninstall ckeditor_templates_ui if it was previously installed on an older version of the module, and still present after an upgrade to the latest 8.x-2.x branch.

I've created a separate issue 📌 Remove ckeditor_templates_ui from Project page Needs work to cover the docs task.

I don't think this module should necessarily uninstall the ui module, people may want the module enabled after upgrading to this modules in order to access / migrate their data.

That sounds more like something that should be in the release notes.

Pointers in the UI for how to configure your site and advice to uninstall a separate no-longer compatible module, or forced removal of another module (which I admit I don't love) feels like a fine issue to raise. But surely a separate issue; where there may be varying opinions and difficulty reaching consensus.

However the latest MR, so it seems, provides "CKEditor 5 support for Content Templates"! I really think we should consider this mission accomplished.

Improvements and changes beyond this point will always be possible and maybe even easier if we merge as is and have an established structure.

This issue is over two years old, yet we stil lack even a dev branch which supports the default CKEditor version used in the current version of Drupal. Despite a merge request sitting here which achieves just that.

Are these the same templates that will be offered in the CKEditor 5 Plugin Pack from CKSource → ? It's a premium feature in standalone CKEditor 5 but will be free via the Drupal module.

The templates feature CKEditor 5 Plugin Pack → definitely seems like it might offer an alternative solution, but I've been unable to get it to work so far. See 🐛 Fatal error on enabling ckeditor5_plugin_pack_templates Active .

Agree with @jacobupal, better to get a first release for CKE5, like a beta version, so people can start pulling into their projects and testing. I have multiple projects looking for this upgrade to CKE5.

I have tested 1.x-dev with MR#10 and it works great! There was a bit of confusion around ckeditor_templates_ui, but after I uninstalled and removed that module it was pretty straightforward. I would say get an alpha version going, close this ticket, open new tickets for any changes that are needed (uninstall ckeditor_templates_ui, update docs, etc...).

I've tested MR #10 and the dev branch with success as well. There are no tests in this module and the functionality is all there with multiple manual tests, so I guess this is RTBC. I tend to agree that getting a stable release would be ideal.

I do worry that the next release may break backwards compatibility with the contrib ckeditor module or possibly the paid CKEditor 4 version provided by CKSource.

I noticed that I cannot remove the composer dependency on drupal/ckeditor with the patch from this merge request. I don't see why not in the module's composer.json—which is a bit odd.

I also was curious about the ckeditor5_plugin_pack approach to CKEditor 5 templates. I guess the good news is that its implementation is very close to MR #10. The configuration of templates is nearly the same with a small difference in how the SVG is added via a field rather than as a file path.

The plugin widget has a neat little search feature, but I'm not a fan of the concatenated template descriptions. It does not show the full description in any way that I can find.

Until those clean up items get added to the ckeditor5_plugin_pack, I think there is still a place for this module, but afterwards, I would imagine most folks are going to settle on the module maintained by CKSource. 🤔

I found CKEditor5 Template module →

RTBC +1 for MR#10.

One way to test with ckeditor module is to add to composer.json

...
  "repositories": [
    {
      "type": "vcs",
      "url": "https://git.drupalcode.org/issue/ckeditor_templates-3273358.git"
    },
...

then run

composer require drupal/ckeditor_templates:dev-mr4-with-patch-146

Admin iterface testing:

Liam Morland → made their first commit to this issue’s fork.

Patch file with current state of merge request 10.

Thanks for everyone's work on this. Merged in!

Very cool - but why did this go into 8.x-1.x ?

The 8.x-2.x branch is way behind. It should have 8.x-2.0-beta1 merged into it.

It looks like this was merged into the 1.x branch in error, so that branch won't be able to be updated without this being pulled out.

2.x RELEASE branch was just 1.x with this PR merged in. The 2.x DEV branch is years out of date.

Might be a good opportunity to move to semvar while cleaning this up?

Automatically closed - issue fixed for 2 weeks with no activity.

Just to clarify - It might just have been me who was still confused about this, but for anyone else reading: It seems 8.x-2.0-beta1 is the first release with CKEditor5 support, hurrah 🎉.

Cleaning this up just requires switching to branch 8.x-2.x, running git merge 8.x-2.0-beta1, and pushing.

If there will be no more 8.x-1.x releases, then it doesn't matter that it has the 8.x-2.0-beta1 commits on it.