WYSIWYG fields don't save from edit media button pop up

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

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.

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

Yes, this is still an open issue.

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?

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!