Any data- attributes set by other contributed filters are removed by buildEntityEmbed() in src/EntityEmbedBuilder.php. By preserving the entire $context array instead of cherry-picking known filters, we can allow contributed filters to add and retrieve their own data attributes. Patch to be submitted in following comment.
| Comment | File | Size | Author |
|---|---|---|---|
| #27 | 2917132-1.0-beta2-26.patch | 1.39 KB | samuel.mortenson |
| #17 | entity-embed-data-attributes-2917132-16.patch | 9.46 KB | oknate |
| #13 | 2917132-13.patch | 9.57 KB | wim leers |
| #13 | interdiff.txt | 1.49 KB | wim leers |
| #12 | 2917132-12.patch | 8.11 KB | wim leers |
Comments
Comment #2
bryden commentedThis is my propsosed fix for this issue.
Comment #3
bryden commentedComment #5
xenophyle commentedI like this idea but maybe it's better to add the $context array to $build['#attributes'] rather than replace it?
Comment #6
wim leersWow, this is a huge bug!
Comment #7
phenaproximaComment #9
phenaproximaComment #10
phenaproximaTransferred credit from #2628712: Persist the classes specified in <drupal-entity class> onto the rendered entity.
Comment #11
wim leersComment #12
wim leersI was thinking first that to minimize change, we should be passing all attributes through except the ones that Entity Embed cares about.
But the existing
filter_align,filter_captionandeditor_file_referencefilters in core do not stripdata-attributes … so I think it makes sense for Entity Embed's filter to match this behavior. It also happens to be the simplest.The change itself is simple enough, the complexity is in updating the tests.
(This should fail tests.)
Comment #13
wim leersThis should pass.
Comment #15
oknatereroll, as #13 no longer applies
Comment #17
oknateRerolling, it looks like my merge was incorrect in patch 14.
Comment #18
oknateI have manually tested this using my reroll in #17. Looks good to go. Marking as "Needs review" since I rerolled it. But it could be marked reviewed and tested by the community since it was just a reroll.
Comment #19
wim leersThanks, looks good!
Comment #20
phenaproximaLooks good to me!
Comment #22
phenaproximaCommitted and pushed. Thanks!
Comment #24
amme commentedShouldn't `$build['#attributes']['class']` be an array?
Comment #25
oknateI tested the class out and it makes no difference for the output whether it's converted to an array in EntityEmbedBuilder or not. It might be easier for 3rd parties in an alter hook, and it used to be an array, so it might be more backwards compatible to change it back.
This is how I tested:
Updated full_html format to support "class" on entity embed:
Then I edited the embed code in the wysiwyg to add class, then switched back to view output within wysiwyg:
In EntityEmbedBuilder, the context has the attribute as a string, since it pulls it from the code above:
The build attributes that are built from the context also have the class as a string:
This results in the following output of the preview of the entity in the wysiwyg:
Whether you convert it to an array in EntityEmbedBuilder or not, the output is the same.
The only thing I would say, is that it used to be an array before going to the alter hooks:
So it would probably be more backwards compatible to convert this to an array before sending to the alter hook here:
Since this issue is marked as fixed, I'm opening a new issue for this:
#3021505: Fix regression introduced by #2917132: Use array for class attribute in EntityEmbedBuilder
Comment #26
amme commentedthanks @oknate for opening new issue
Comment #27
samuel.mortensonHere's a re-roll on top of 8.x-1.0-beta2 since a release hasn't came out in awhile.
Comment #28
wim leers#3021505: Fix regression introduced by #2917132: Use array for class attribute in EntityEmbedBuilder landed!