Problem/Motivation
We have customized the Entity Embed dialog that appears when embedding a media item to include a custom set of radio buttons that allow the user to select an aspect ratio for the embedded media item.
Now that we're trying to upgrade from Entity Embed 1.4 and CKEditor 4 to Entity Embed 1.5 and CKeditor 5, one of the issues we're running into is with this custom form field that we've added to the dialog no longer working like it used to.
The selected aspect ratio value is supposed to be stored in the <drupal-entity data-aspect-ratio=""> attribute. However, after upgrading to EE1.5/CKE5 our custom data-aspect-ratio attribute is no longer getting set on the <drupal-entity> element.
Steps to reproduce
Here's our code that adds the custom aspect ratio form element to the dialog, linked to the data-aspect-ratio attribute:

I've verified that this is an allowed attribute in the CKEditor 5 source editing:

When I inspect what form data gets passed to the server when the dialog is closed, the data-aspect-ratio is missing in the query parameters:

Proposed resolution
If I change our custom form element to use a different attribute name like data-caption or alt then the data does get passed. So it seems like there's a new whitelist of allowed attributes within Entity Embed.
Can you provide some way to customize what attributes can be passed from the Entity Embed dialog to the <drupal-entity> element? Or can it use whatever is allowed in the CKEditor Source Editing configuration?
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 3410132-MR-31_support-custom-data-attribs.diff-14.patch | 38.36 KB | altcom_neil |
| #11 | Fixes-custom-data-attributes-issue-11.patch | 38.37 KB | nadim hossain |
Issue fork entity_embed-3410132
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
richarddavies commentedComment #3
wim leersFYI: this logic must be modified to pass all attributes to the server side: also the GHS ones, and not just the ones explicitly used/supported/consumed by the
entity_embedCKE5 plugin:— https://drupal.slack.com/archives/C01GWN3QYJD/p1703092541221209?thread_t...
P.S. there already is explicit test coverage for additional attributes not getting stripped. So this is NOT a data loss issue! This issue is requesting the ability for the server side rendered dialog to be
hook_form_alter()ed to support editing additional attributes.Comment #6
bnjmnmComment #7
bnjmnmTest failures on MR are unrelated to the changes made in there and (the test I added specific to this issue is passing, btw). I assume this is due to the welcome addition of testing multiple core branches by the testbot, which has surfaced several pre-existing issues.
Comment #8
odensc@bnjmnm Thanks for the MR! I've confirmed it fixes the issue described, but I did find some bugs:
1. If a wildcard is defined in the Source editing plugin's allowed tags, e.g.
<drupal entity data-*>, then aTypeError: attr.key.replace is not a functionis thrown.2. If one of the default data attributes is defined in the allowed tags, e.g.
<drupal-entity data-entity-type data-entity-uuid>, then the media doesn't render after embedding. I believe this is because the default key in the attrs object, e.g. "drupalEntityEntityType", gets superseded by the now-automatically-added "dataEntityType", causing some other part of the code to break.I've attached a patch to your MR that works around these two issues.
For #2, the fix is easy enough: add a check that the attribute is not already defined in the attrs array.
For #1, it's a bit trickier. It appears CKEditor's
SchemaItemDefinition.registermethod does not accept RegExp objects in theallowAttributesproperty. That means there's no way to simply pass the wildcard along, AFAICT.Therefore, I simply added a typecheck to simply skip if
attr.keyis not a string, but this is quite opaque - I'm not sure if it'd be better to actually throw an error instead, so the user isn't confused if their wildcard is not respected. That is, of course, unless you have a better idea of how to handle wildcards.Comment #9
yovinceThank you @bnjmnm and @odensc for your contributions. After applying the two patches you suggested, everything is working perfectly. For my convenience, I've combined both patches into one.
Comment #10
szato commentedUsing patch #9 with D10.2.2 solved our issue (broken custom attributes)
Thank you!
Comment #11
nadim hossain commentedRe-rolled the patch for the new release of Entity Embed version 1.6
I couldn't push the merge request resolved conflict though,
Comment #13
mortona2k commentedRebased branch on 1.7 and regenerated JS.
Comment #14
odenscThanks for the rebase @mortona2k. I also added the fixes from #9 into the MR.
Comment #15
altcom_neil commentedHi
Tested latest diff in Drupal 10.5.1 and entity_embed 1.7.0 and our custom data attributes are working.
Attaching the patch here to be included as a composer patch.
+1 RTBC
Comment #16
odenscMoving to RTBC, we've been using this in production for a year+, and there are a few other people here that have confirmed the fix.
Comment #17
geoffreyr commentedI'd like to try and find a way to feed custom attributes into the plugin in a way that doesn't require filter_html, since we don't always use it. I might look into this in a separate ticket.