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 😂

I think the docs from CKEditors GHS page say it best:

Therefore, GHS’s main use cases would be:

Ensuring backwards content compatibility with legacy systems.
Introducing basic support for missing HTML features at a low cost.

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 <img> 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 (<img class>).

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.

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.

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