Allow CKEditor5 custom headings

Thanks for the pointer. I will certainly check out what comes eventually out of this and if it is useful.

For the time being I've created a simple module which allows to customize the headings exactly like it was possible in CKE4. Perhaps it is also useful for other users as a bridge technology:

https://github.com/rgpublic/ckeditor_custom_heading

Can you please update to Drupal 10.1 and try this again? Updates in CKEditor 5 maybe have fixed the problems you were seeing.

I don't *think* the issue is resolved in 10.1, unless I'm missing it? Is there now a way in the UI to configure headings with classes like there was in CK4, so that users can apply the block-level element *and* the style in one click?

@mrogers: That's right. This is not solved in 10.1. You can use my module (see above) to do just that.

After having re-read the issue summary in detail, I now see how my responses in #2 and #6 completely missed your point 🙈 Sorry about that!

I am strongly inclined to mark this , because

1. The Heading plugin supports only a class to <h1> … <h6>. But the Style dropdown allows adding a class to virtually any element.
2. Once https://github.com/ckeditor/ckeditor5/issues/14372 is solved, that will be able to do what you want: you'd be able to use the Style plugin to create for example <h2 class="fancy">. 👈 Actually, retitling/rescoping for tracking this. I should've created an issue for this back in #3326261-51: [Style] Add tests for inability to apply styles to
   ,

   ,
   ,

Actually, let's first get feedback from @lauriii on my proposal 😇

@Wim-Leers:

Well, in CKE4 you could switch between P and H1.blue with just the paragraph style dropdown. Two clicks. You can't do that right now. Another difference is that say you have h1, h1.red and h1.blue. The new CKE5 style dropdown works more like a checkbox and not like a radio button. You could create h1.red.blue which is usually not what's desired.

The CKE5 style dropdown (IMHO, of course) still has a lot of very unpleasant usability flaws. Of course, they might be resolved in the future and it might very well be a sensible strategy to wait for these to be resolved - I don't want to argue against that. Nevertheless, I thought it would perhaps be a nice addition to allow to use the way more simple headline dropdown to be used for all those cases where you don't have a lot of different classes and styles and just want to have an experience similar to what we had previously in CKE4 - especially since the feature seems to be built-in already. It'd just need to be exposed in Drupal and would probably solve a lot of headaches for people trying to switch from CKE4.

Nevertheless, I thought it would perhaps be a nice addition to allow to use the way more simple headline dropdown to be used for all those cases where you don't have a lot of different classes and styles and just want to have an experience similar to what we had previously in CKE4

Yes, I see your point. But we need to think about long-term implications of that. What you propose only works for a handful of tags. It's not a general solution.

https://github.com/ckeditor/ckeditor5/issues/14372 is a general solution.

If Drupal were to adopt what you propose, then it would be disruptive (for both the UX and configuration) to at some point switch to the generally applicable solution that https://github.com/ckeditor/ckeditor5/issues/14372 will eventually provide.

As a subsystem maintainer, I have to take the long-term view! 🕵️

Related to that long-term view: 📌 [Style] Warn the user about styles for unsupported elements Needs work .

It'd just need to be exposed in Drupal and would probably solve a lot of headaches for people trying to switch from CKE4.

So far, this reduction in capabilities in CKEditor 5 when compared to 4 has triggered few complaints: this issue has only half a dozen followers currently and it occasionally comes up as a question in Slack most recently on October 3.

So: please vote on https://github.com/ckeditor/ckeditor5/issues/14372 to help gauge interest! 😊

@Wim-Leers: I understand & makes sense! Thank you anyway for considering & detailed explanation. My module might be a stop-gap solution for some people in the mean time until a full-fledged solution comes along.

My module might be a stop-gap solution for some people in the mean time until a full-fledged solution comes along.

💯

Thank you for your understanding and creating that module! 😊

Updated the issue summary to recommend that as the interim work-around for some cases 👍

All we need is to support custom heading elements in Drupal\ckeditor5\Plugin\CKEditor5Plugin\Heading. With this patch the following code works:

/**
 * Implements hook_ckeditor5_plugin_info_alter().
 */
function MYMODULE_ckeditor5_plugin_info_alter(array &$plugin_definitions) {
  assert($plugin_definitions['ckeditor5_heading'] instanceof CKEditor5PluginDefinition);
  // Modify 'Format' options.
  $plugin_definition = $plugin_definitions['ckeditor5_heading']->toArray();
  $options =& $plugin_definition['ckeditor5']['config']['heading']['options'];
  $options[] = [
    'model' => 'paragraphSmall',
    'view' => [
      'name' => 'p',
      'classes' => 'text-small',
    ],
    'title' => t('Paragraph small'),
    'class' => 'ck-heading_paragraph_small',
  ];
  $options[] = [
    'model' => 'headingFancy',
    'view' => [
      'name' => 'h2',
      'classes' => 'fancy',
    ],
    'title' => t('Heading 2 (fancy)'),
    'class' => 'ck-heading_heading2_fancy',
  ];
  $plugin_definitions['ckeditor5_heading'] = new CKEditor5PluginDefinition($plugin_definition);
}

The new options now appear and can be enabled in the text format's Enabled Headings section.

If we are going to commit something to core for this, think we will need to include test coverage also.

Per comment: https://www.drupal.org/project/drupal/issues/3326261#comment-15316349 🐛 [Style] Add tests for inability to apply styles to , , , etc. in CKEditor 5 — and allows applying it to all elements Fixed
this issues here is supposed to be the catch-all issue for all remaining non-critical ck5 issues:

But this only concentrates on headlines.

I still don't see a way for this to work as it is now for

As far as div, I found that I put this extra line in ckeditor5.ckeditor5.yml:

options:
          - { model: 'paragraph', title: 'Paragraph', class: 'ck-heading_paragraph' }
          - { model: 'div',      view: 'div', title: 'Div', class: 'ck-heading-div' }
          - { model: 'heading1', view: 'h1', title: 'Heading 1', class: 'ck-heading_heading1' }

then div at least appears as an option in the text-format form, and if I select it there it also shows in the ckedtior pulldowns for headlines.
At least that way, a person could make a section a <div> instead of a <p>.
And then this would work if the theme only has css that deals with divs (not p, span, etc).

But... it still does not work well:

The bigger problem is (and I do not see a way at all in CK5 that can do this): a div can wrap around many paragraphs, or other elements.

If I go into text-source mode and put a div around several

or whatnot, whenever I go out of source-mode then ck5 removed that div.
Likewise, if I use the above workaround and select multiple paragraphs, then in the headings pulldown select "div:, then ckeditor places one div around each paragraph.

At the moment I do not see a use divs correctly in ck5.

Please consider opening another issue for ck5 and div, as that problem is slightly different than for "headline" because divs can wrap multiple elements. Alternatively change the title so that this issue does not only refer to headlines.

@hoporr: Yes, it won't work that way. CKE5 would need a dedicated plugin to define such a container DIV in the model and allow it to wrap other P tags. Unless such a plugin is written, you probably won't be able to make it work. Perhaps see also:

https://github.com/ckeditor/ckeditor5/issues/6462

Okay, I've filed:

https://www.drupal.org/project/drupal/issues/3418322 ✨ [upstream] [GHS] Allow CKEditor 5 support for containers: div, article, section, aside, etc. Postponed

I think it's better to not modify the focus of this bug too much. Feel free everyone to subscribe / continue discussion over there.

Indicating this is blocked on upstream.

The solution outlined in #3362451-16: [upstream] [Style] Allow CKEditor 5 to *create* a

directly (instead of first

, then adding a class) → works, thanks @aludescher

To summarize, it uses a core patch to allow any tag in the ckeditor5 heading plugin, not just PS. in my use case I added an option for support for formatted text. I tried to add that then in the custom list for source editing tags so the editor wouldn't just remove them. But the text format configuration was clever and produced an error on save, since the tag is already supported by the CodeBlock ckeditor5 plugin. As a workaround I found out adding the tag with an arbitrary class bypasses that check and makes any tag work that is added in the alter hook.

I applied the patch in #16 and added that function to my module and I got this error:

AssertionError: assert($plugin_definitions['ckeditor5_heading'] instanceof CKEditor5PluginDefinition) in assert()

@taote you might be missing a use statement for CKEditor5PluginDefinition at the top of your module file:

use Drupal\ckeditor5\Plugin\CKEditor5PluginDefinition;

The approach in #16 worked well for us — thanks @aludescher!

One note: be sure to add 'converterPriority' => 'high' to your new options, e.g.:

  $options[] = [
    'model' => 'headingFancy',
    'view' => [
      'name' => 'h2',
      'classes' => 'fancy',
    ],
    'title' => t('Heading 2 (fancy)'),
    'class' => 'ck-heading_heading2_fancy',
    'converterPriority' => 'high',
  ];

Without that, added options likely won't still be selected on subsequent edits of the content. Standard options that operate on the same element (in this case 'Heading 2') will take precedence.

I don't understand the technical decision being made at CKEditor. It is a shame we cannot convert elements to div or simply inject a div manually for styling.

Sharing this issue to all my Drupal relatives.

I have a dream we'll have a proper editing experience by the end of the decade 😅...