Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem / Motivation
A lot (maybe all) of the information in the attributes structure can be generated based on other information in the macro or from the file entity or file settings. This is how the $tag_info['attributes']
structure might look like after media insertion into the text area, in json format:
{
"attributes":{
"alt":"Overridden Alt text",
"title":"Overridden Title text",
"height":220,
"width":148,
"class":"media-element file-teaser media-wysiwyg-align-left",
"data-delta":"1"
}
Proposed resolution
Generate the attributes based on information from the macro or file entity itself during input filtering, and omit inserting these in javascript:
- The
alt
andtitle
attributes should be generated based on the values in$tag_info['fields']
and theDrupal.settings.media.img_alt_field
andDrupal.settings.media.img_title_field
settings. - The
height
andwidth
attributes should not be set if they differ from the selected style/image. It also causes problems when selecting a different format in the wysiwyg media browser. If necessary, add this information in the input filter. - All inserted classes can be generated based on other values in the media token:
"type":"media"
→media-element
,"view_mode":"teaser"
→file-teaser
,"fields"."alignment":"right"
→media-wysiwyg-align-right
Comments
Comment #2
kaareMost of this has been addressed and fixed in the parent issue, but not height and width.
The solution is to rebuild the token upon stringification, based on a new token schema which only adds settings and attributes that aren't generated or otherwise duplicate info.
I'm still gonna keep this issue open trying to see if the width/height attributes can be handled.
Comment #3
kaareIt seems like ckeditor forcefully sets the width/height attributes upon detachment even if I delete the values in the ckeditor image plugin. Couldn't find any code in wysiwyg that is responsible for adding these. I suspect this is out of scope of the clean-up-token task. Probably requires a follow-up.
So … closing this as fixed.