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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

Do you use the WYSIWYG module? What admin theme do you use?

becw’s picture

Title: WYSIWYG fields don't save from edit media button pop up » Edit media button pop up does not save.

This 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.

becw’s picture

To duplicate:

  1. Configure WYSIWYG API to provide an editor on filtered text fields.
  2. Add a long text field to the image file type, and set the default "Text processing" to filtered text.
  3. Add a taxonomy term reference field to the image file type.
  4. Add a file field to some content type with the media browser widget.
  5. Create a new piece of content and add a piece of media.
  6. After adding the media, click the "edit media" button. Change the file name and add content to the wysiwyg text field and the taxonomy term reference field, then save (which closes the modal).
  7. Click the "edit media" button again. The file name and taxonomy term reference fields will have the correct content, and the wysiwyg text field will be empty.
  8. These fields work as expected if you edit the file from admin/content/file

You can work around this bug by avoiding the use of WYSIWYG for fields on files.

becw’s picture

Title: Edit media button pop up does not save. » WYSIWYG fields don't save from edit media button pop up
gleroux02’s picture

Title: Edit media button pop up does not save. » WYSIWYG fields don't save from edit media button pop up

Thanks becw, you beat me to it. It is definitely the WSYSIWYG that is causing the issue.

dddave’s picture

Status: Active » Postponed (maintainer needs more info)

Six months have passed and there are no follow ups. Is this still an issue?

becw’s picture

Status: Postponed (maintainer needs more info) » Active

Yes, this is still an open issue.

justindodge’s picture

Issue summary: View changes
Status: Active » Needs review
FileSize
971 bytes

Hey 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:

var content = "<img height="20" src="test.jpg" width="30">";
content = $(content).html();

// content is now: "<img src="test.jpg" width="30" height="20">"

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:

// Replace the media element with its macro.
content = content.replace(markup, macro);

but it fails because markup has HTML who's attributes have been jumbled around, and hence can't be found within content.

My solution is to "normalize" the HTML before the iterator and search/replace happens, like so:

// "Normalize" the content html - when html is processed by jQuery, attributes can end up in a different order.
// This causes issues with our search and replace, so we normalize here before iterating through our media
// elements and risk getting them mixed up.
content = $('<div>').append(content).html();

Attached is a patch to that effect against the latest 7.x-2.x-dev checkout.

justindodge’s picture

On 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?

justindodge’s picture

Status: Needs review » Closed (duplicate)

I'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!