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.

Files: 
CommentFileSizeAuthor
#8 wysiwyg_fields_dont_save-1508528-8.patch971 bytesjustindodge
PASSED: [[SimpleTest]]: [MySQL] 914 pass(es).
[ View ]

Comments

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

Title:WYSIWYG fields don't save from edit media button pop upEdit 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.

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.

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

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.

Status:Active» Postponed (maintainer needs more info)

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

Status:Postponed (maintainer needs more info)» Active

Yes, this is still an open issue.

Issue summary:View changes
Status:Active» Needs review
StatusFileSize
new971 bytes
PASSED: [[SimpleTest]]: [MySQL] 914 pass(es).
[ View ]

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.

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?