[upstream] [GHS] CKEditor 5 does not retain custom HTML tags that are not defined by CKEditor 5 plugins whenever /.*/ is not allowed (e.g. when filter_html is enabled)

🤯

Reproduced.

Despite #3268306: [GHS] Custom/unofficial HTML tags not retained: <drupal-media>, <drupal-entity>, <foobar> having fixed this. Requires deeper investigation. I'm baffled.

It seems that #3268306: [GHS] Custom/unofficial HTML tags not retained: <drupal-media>, <drupal-entity>, <foobar> only fixed it when filter_html is disabled?! 😱

Confirmed. This is a bug in GHS.

It boils down to a small difference in the GHS configuration that should not make a difference:

drupalSettings.editor.formats.custom_tag.editorSettings.config without filter_html

{
    "htmlSupport": {
        "allow": [
            {
                "name": {
                    "regexp": {
                        "pattern": "/.*/"
                    }
                },
                "attributes": true,
                "classes": true,
                "styles": true
            },
            {
                "name": "foo"
            }
        ]
    }
}

drupalSettings.editor.formats.custom_tag.editorSettings.config WITH filter_html

{
    "htmlSupport": {
        "allow": [
            {
                "name": {
                    "regexp": {
                        "pattern": "/^(br|p|foo)$/"
                    }
                },
                "attributes": [
                    {
                        "key": "dir",
                        "value": {
                            "regexp": {
                                "pattern": "/^(ltr|rtl)$/"
                            }
                        }
                    }
                ]
            },
            {
                "name": {
                    "regexp": {
                        "pattern": "/^(br|p|foo)$/"
                    }
                },
                "attributes": "lang"
            },
            {
                "name": "foo"
            }
        ]
    }
}

That should still work. But the additions that \Drupal\ckeditor5\Plugin\CKEditor5Plugin\GlobalAttribute makes to the htmlSupport (aka GHS) configuration somehow break it.

(Note that var pluginConfig = processConfig(config); in core/modules/ckeditor5/js/ckeditor5.js converts the regexp.pattern pieces in that JSON to actual RegExp objects — PHP's json_encode() just cannot generate that.)

I modified it to the more minimal:

pluginConfig.htmlSupport.allow = [
    {name: 'foo'},
    {name: /^(br|p|foo)$/, attributes: [{key: 'dir', value: /^(ltr|rtl)$/}]}
];

and it still happens. Per https://ckeditor.com/docs/ckeditor5/latest/features/general-html-support..., this definitely should work. But not even this works:

pluginConfig.htmlSupport.allow = [
    {name: 'foo'},
];

It looks like that it has to contain /.*/ for any custom HTML tag to work:

htmlSupport.allow =  [
    {name: 'foo'},
    {name: /.*/}
];

#3268306: [GHS] Custom/unofficial HTML tags not retained: <drupal-media>, <drupal-entity>, <foobar>'s test coverage was not strict enough. It only tested if custom HTML tags are supported when there are no HTML restrictions. Note that custom HTML tags that are defined by a plugin, such as <drupal-media>, do work, otherwise we'd have known about it months ago.

Reported upstream: https://github.com/ckeditor/ckeditor5/issues/13343

I offer one solution:

We were able to solve this by creating a custom CKE5 plugin in a Drupal custom module. The plugin registers the new model element, creates the conversions for the custom html tag for the view, creates the command to apply it, and assigns it to a button in the editor toolbar. It took a learning curve through CKE5 documentation (https://ckeditor.com/docs/ckeditor5/latest/api/index.html), but the positive of that is our new clarity on CKE5 conception and architecture.

Creating this plugin registered the custom element and the custom html tag. It is now in the "Allowed HTML tags list" and is no longer filtered out.

Thank you Wim Leers, Lauriii, and all for the cool work on the integration!

👍👍 Yep, that's indeed the recommended work-around!

Just to clarify, we used the tools and plugin template in this Drupal module to get started:
https://www.drupal.org/project/ckeditor5_dev

@fl-49 Are you able to share more details of your solution? I have ckeditor5_dev set up as a starting point to generate a new module and plugin but it would be great to see how you approached it.

Please vote with a 👍 there if you want to see it solved sooner.