Change to edit source error handling in 10.2 leads required changes to configuration that cause data loss on edit

Link where this was discussed on slack - https://drupal.slack.com/archives/C01GWN3QYJD/p1703130469784569

I believe this is a behaviour change which is not necessary for Drupal to try and validate against. This is something that CKEditor supports but Drupal is imposing a restriction that is problematic in certain limited circumstances.

The rationale is to force you to use the native functionality rather than typing HTML by hand.
… because that always is a better authoring experience.

I believe this is fine and reasonable for Drupal to recommend this and give this to you as an out of the box experience - but not to enforceit, because like all things always there are edge cases or practicalities that get in the way.

Our use case is we have a large amount of content dating back years and a theme inheriting from a distribution which uses a CSS framework. The site as a lot of classes and patterns that have been used over the years. Not all of these classes / styles are appropriate to be "promoted" as a visible option via the styles drop down - they are no longer encouraged to be used by editors today, but we certainly can't remove their support if the editors need to edit historic content.

Other classes only work in combination with other parent classes - and we use CKEditor templates for this purpose to allow these pre defined bits of markup to be inserted with the classes pre applied. As we can see what these classes are, this is easier to retrofit into the style plugin - but not desirable if they don't function as expected without a structure around them (e.g. bootstrap cards which have a class on the div, title and card body).

Some editors are also very comfortable using HTML - again this is the edge case, but if the editor knows their website and framework, I don't want to get in the way of their judgement if they want to use utility classes from the framework. Good luck putting tailwind into the style drop down for instance 😂

So I think the tldr from me is: I know that using the style plugin for all classes is best practice and if I was starting a new build I would 100% rely on that, but I have constraints that stop me from immediately doing that - and I think given GHS / Source editing in CKEditor allows me to do this - Drupal should too.

Additional use case - classes on images.

If you try to define image classes via the style plugin, it is invalid with:

The tag is not yet supported by the Style plugin.

If you try to apply them via GHS you are told:

The following attribute(s) can optionally be supported by enabled plugins and should not be added to the Source Editing "Manually editable HTML tags" field: Style ().

joshuami ask me to share the example of the code in my edit source and style plugins on my ckeditor5 basic text filter:

Source Editing:

Original (D10.1.5)
    <cite> <span> <dl class> <dt class> <dd class> <iframe allow allowfullscreen src width height frameborder> <blockquote cite> <ul type> <ol type> <h2 id class> <h3 id class> <h4 id class> <h5 id class> <h6 id class> <a hreflang accesskey id rel target title class> <img data-entity-substitution class> <p class>
    
Current (D10.2.0)
    <cite> <span> <dl class> <dt class> <dd class> <iframe allow allowfullscreen src width height frameborder>
    
Style Plugins:

Original (D10.1.5)
    a.button|Button
    p.note|Note
    p.large|Larger text
    h1.node__title|Page title
    img.border|Add a border
    img.display-left|Float left
    img.display-right|Float right
    p.h2|H2
    p.h3|H3
    p.h4|H4

Current (D10.2.0)
    a.button|Button
    p.note|Note
    p.large|Larger text
    h1.node__title|Page title
    img.border|Add a border
    img.display-left|Float left
    img.display-right|Float right
    p.h2|H2
    p.h3|H3
    p.h4|H4

There are known issues with iframes, filters, and 10.2. See https://www.drupal.org/project/drupal/issues/3410303 🐛 FilterHtml data loss when iframe and/or textarea is allowed Active .

Alright... another use case with data loss. The language selector no longer works with any core configuration.

If you try and add language to the toolbar, it gives you an error that you need another plugin to add <span>, but if you try to enable span via source editing, it throws an error that it is already enabled via language.

I am not able to reproduce the language selector error in #8

I get the warning message - but I can still add span to source editing - no issue for me.

Hmm. I was adding <span lang dir> to source editing. Just adding <span> does work. Thanks for having me double check @ericgsmith.

I still think it might strip the declaration upon saving after an upgrade because of the new rules around plugin requirements, but at least you can sort of use the language selector again.

Added some clarification to the issue summary. The text filter won't cause data loss until saving the format after resolving all errors to allow saving.

Duplicate of 🐛 [10.2 regression] CKEditor 5 breaks when "Source"/Source editing button is added and "Manually editable HTML tags" are specified Needs review (which is the oldest). Will investigate and transfer relevant info from this issue, plus credit everyone who contributed here 👍