Existing classes are not used as default values

This patch shows changes required by the ck5 v29 1.0 Matcher pattern update

@slattery Thank you for the patch. It applied successfully, but unfortunately it doesn't solve the problem I still don't see any enabled switches (read: default values) when I select more than one option the first time.

Sorry! I retraced my steps, and I can share a separate issue, which may not apply to your case. I should note that this patch doesn't solve a problem I have with compound class config lines - I will address these in another ticket if I get to it. In addition to the patch, I needed to separate my class toggles.

If I have one toggle for 'a.btn|Button' and a separate config line for 'a.btn--small|Button Added Styling Small' these work with the patch, using d9.5.11/ckeditor_link_styles v1.0.1. Even as a single toggle, I could not get a configuration with 'a.btn.btn--small' on a single line to be recognized after saving a node.

Looks like there are a couple things going on here. @slattery was on the right track with #2 to correct for the MatcherPattern change, we just need to also provide the $classes as an array now, rather than a string as there could be more than one. (This change will also fix 📌 Use `classes` matcher pattern option Active ).

Even with that corrected, if your styles have "shared" classnames, like:

.btn.btn--primary
.btn.btn--secondary
.btn.btn--small

Where the `.btn` class is present in each style—only the first enabled style will "match" and thereby show the associated toggle as enabled. These should work, but just don't anymore. My best guess is that this is an upstream regression in ckeditor 5 (?).

As @slattery suggests, the only solution I could find at the moment is to refactor your styles to remove the shared classname.

This means that only one of the three example configs on the project page currently works as expected. The second example "Example configuration for Bootstrap links" works fine. The first and third examples have shared classnames (".btn" and ".button" respectively) so users will be able to set multiple styles, but they won't appear to be active on subsequent edit, which is obviously very confusing for users.

In all cases, the actual classes do get set and remain in the content, unless the link is subsequently edited.

Attaching a static patch based on the MR.

The change in the MR (or patch #8) will allow the selection of multiple link styles to persist on subsequent edits as long as your styles do not contain any shared classnames.

I was able to replicate "shared classnames" problem on a barebones, local install of ckeditor's 'Classic Editor' build, so it doesn't seem specific to Drupal or this module.

I opened a new ticket in the ckeditor queue -- https://github.com/ckeditor/ckeditor5/issues/15908. Go give it a 👍 if you're interested in seeing it fixed!

Until that upstream issue is resolved, seems like the only current solution is to refactor CSS to remove shared classnames in your link styles.

Updating the title and issue summary.

Just confirming that I've observed this behavior as well and that the workaround for non-shared class names in #8 appears valid.

#8 seems to be working here too.

Patch #8 works for me using Drupal 10.2.6 with Bootstrap 5 classes (button colors and sizes).

I have been waiting for ages for the D11 release and today I raced to try it out :-)

This is such a brilliantly useful module in theory but when go to use it an anger to sprinkle Bootstrap 5 buttons around the place I am still falling foul of the above issue.

I have applied the patch in #8 (which applied without issue to 1.01) but it does not fix even a simple scenario where I successfully apply the Bootstrap styles:

1. btn
2. btn-light
3. btn-sm

I can see that in the front end...

But when I go back in to edit the content, the UI does not reflect the truth...

Even though, the markup-up is clearly correct...

<a class="btn btn-light btn-sm...

From a content-editor's point of view this simply renders the module unusable which is a terrible shame :-( because it's such a killer tool for them.

My test is with Drupal 10.3.6 rather than 10.3.9 but I don't really think that should matter should it?

Thanks all.