[upstream] [GHS] CKEditor 5 stripping <h2> tags (and more) if inside <div>

Looks like that's a ckeditor bug, it happens on the demo page for the source input https://ckeditor.com/ckeditor-5/demo/html-support/
If you select h2 via the heading dropdown, it stays.

Looks like this might be the same: https://www.drupal.org/project/drupal/issues/3349893 🐛 [upstream] [GHS] CKEditor 5 removes s that wrap HTML elements not natively supported by CKEditor 5 Fixed
(added this issue to the CKEditor report).

This sounds like a duplicate of 🐛 [upstream] [GHS] CKEditor 5 removes s that wrap HTML elements not natively supported by CKEditor 5 Fixed , however it seems a bit different. That's because in 3349893 it's about an inline element (i.e. an <a> tag) wrapping a block element (i.e. a <div> tag). Whereas here the wrapping h2 is a block element. Not sure if that affects this issue here, but thought it was worth noting.

Can you please upload the output of drush config:export of the relevant text editor + format? Thanks!

OK - here ya go. Note that this is a pretty much plain vanilla install - I'm only at the import/organize stage. If you use the HTML I've provided in a vanilla site, I'm pretty sure you'd get the same result.

Thanks for the quick response!

You provided everything 😅

I just needed these two files! Looks like you have only a single text format/editor: . Is that right?

Your text format is configured to not allow <div> tags 😅

So of course it's getting stripped. CKEditor 5 is configured to match the HTML restrictions, which means no <div> tags.

Can you please share your text editor + format YAML config exports (like the ones I posted in #8) from before you upgraded from CKEditor 4 to 5? 🙏 We have VERY detailed test coverage that proves this should not be possible: if <div> was allowed before, it should still be allowed.

Thanks, Will - this isn't an upgrade, though. It's a straight D10 install.

The old site I'm exporting from (D7) used Field Collection, which I now see is available (if patched) for D10. I do recall, however, that in the past, I've had to use TinyMCE to preserve certain tags. Thanks for the <div> info, though - that explains a lot!

In #7, you only provided an export of Basic HTML, no other text formats!

Try using Full HTML. Then your markup should work. Or did you already try that?

That being said, there are still edge cases of this kind of arbitrary HTML that do not work correctly in CKEditor 5. In the next 10.1 release (after the current first beta), CKEditor 5 will be on version 38, which has additional fixes for this, which may address this. See 📌 Update CKEditor 5 to 38.0.0 Fixed .

Oh and like @TinaRey said: if this is reproducible on the official CKEditor 5 demo site with GHS (General HTML Support) enabled, then this definitely would be an upstream bug! This is definitely a different bug though: <a> are very special (because they may need to wrap inline or block elements, and both elements supported natively by CKEditor 5 and custom ones that are supported thanks to GHS).

What we need here is to distill this down to the minimal test case that triggers the problem. Once we have that, we should report it as an upstream bug.

Tentatively bumping priority and tagging , because based on @TinaRey's comment, that is now very likely.)

I suspect the triggering condition is that this is markup inside of a <div>. It'd be great if that could be confirmed 😊🙏

Try using Full HTML. Then your markup should work. Or did you already try that?

Oh, I most definitely did; in fact, there's no other way I would have tried it. I have no idea why my export didn't show HTML, though. In any event, if you try the HTML I posted on a D 10 install, I'd be surprised if you didn't get the same result.

In the meantime, I've decided to use a different method to do what I was trying to do, so I'm off the dime here. Thanks for getting back and keep up the good work!

I could replicate the issue in a pretty fresh Drupal 10 install with full_html, other formats with several ways of adding tags, ids, classes etc in the allowed list etc and at some point noticed that the h2 doesn't get stripped if it's applied via UI; only via source. That's when I went to their demo page for the "source" button which says it allows all sorts of dangerous html. The test case is as minimal as

<h2>
    <div>Test</div>
</h2>

I left a comment in the upstream issue https://github.com/ckeditor/ckeditor5/issues/13803#issuecomment-1558319636

Asked @witeksocha to confirm — thanks @TinaRey!

Was confirmed at https://github.com/ckeditor/ckeditor5/issues/14249. (I forgot to follow up here.)

Looking at the upstream issue, there was a valid point made that <h2><div>content</div></h2> isn't legal html.

That may help explain why this hasn't been addressed yet. Given how long this has been open, might it be an option for folks suffering from this to consider migrating to markup like <h2><span>content</span></h2> instead? I'm not convinced that cksource will make divs in headings work as a product feature.