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.
I have a file field with the media file selector on a node. There is also a caption long text field that has been added to the media entity. I've added a media item to a node and attempted to edit it using the new "Edit media" button. But the caption that I've added does not actually save. There is also no error or notice to help figure out where things broke.
I should also note that if I turn off javascript or go directly to the edit url "media/[nid]/edit/nojs" the caption saves correctly. So perhaps this is an issue with the popup save event.
Comment | File | Size | Author |
---|---|---|---|
#8 | wysiwyg_fields_dont_save-1508528-8.patch | 971 bytes | justindodge |
Comments
Comment #1
Dave ReidDo you use the WYSIWYG module? What admin theme do you use?
Comment #2
becw CreditAttribution: becw commentedThis is an issue specifically with WYSIWYG fields in the "edit media" CTools modal. Other fields (for example, a taxonomy term reference autocomplete field) work as expected. This probably means that content in the WYSIWYG field isn't getting pushed back into the real textarea, so it's possible that detach/unload events aren't getting called.
This issue does not happen with the media module's modal, for example with the patch from #1 in #1426730: Automatically open the file edit modal after uploading a file, so it may be specific to the CTools modal.
Comment #3
becw CreditAttribution: becw commentedTo duplicate:
admin/content/file
You can work around this bug by avoiding the use of WYSIWYG for fields on files.
Comment #4
becw CreditAttribution: becw commentedComment #5
gleroux02 CreditAttribution: gleroux02 commentedThanks becw, you beat me to it. It is definitely the WSYSIWYG that is causing the issue.
Comment #6
dddave CreditAttribution: dddave commentedSix months have passed and there are no follow ups. Is this still an issue?
Comment #7
becw CreditAttribution: becw commentedYes, this is still an open issue.
Comment #8
justindodge CreditAttribution: justindodge commentedHey ya'll. I was running up against this issue and found a culprit.
In modules/media_wysiwyg/js/media_wysiwyg.filter.js within
replacePlaceholderWithToken()
, the WYSIWYG markup for media elements gets converted back to "macros" as they're referred to in code. This process relies on a search and replace in javascript - however the HTML that is passed to the function gets altered in the process of being parsed by jQuery (attributes change order) and the.replace()
fails for that reason.For example:
In
replacePlaceholderWithToken()
, this discombobulation happens when .media-elements are iterated through:$('.media-element', content).each(function(i, element) { ...
Shortly after, the search and replace is attempted:
but it fails because
markup
has HTML who's attributes have been jumbled around, and hence can't be found withincontent
.My solution is to "normalize" the HTML before the iterator and search/replace happens, like so:
Attached is a patch to that effect against the latest 7.x-2.x-dev checkout.
Comment #9
justindodge CreditAttribution: justindodge commentedOn a side note, I just happened to stumble across #2126755: Improve Media's WYSIWYG Macro handling, and it looks like the rewrites there will ultimately include this same type of fix within the same code and function, although that issue is fairly deep and long running.
Edit: Tried to make this a 'related issue' but couldn't seem to get it to stick. Maybe that's broken right now?
Comment #10
justindodge CreditAttribution: justindodge commentedI'm pretty sure this issue has been superseded by the one I referenced in #9, and I'm pretty sure all has been resolved, or at the very least moving on in new issues with subsequent matters will be more appropriate.
I think it's best to shut 'er down.
So, closing. Good night!