If you change a file's information with the WYSIWYG disabled, re-enabling the WYSIWYG loses the file

I think we should continue to use the full token as the key (since changes in the token, such as field overrides) can affect the rendering of the token. But we need to add a menu callback to which we can pass the full token to get a rendered version of it.

No offence, but the current placeholder solution is horrible. (See also #2085997: WYSIWYG Image update not working.)

A multi-element placeholder is essentially impossible to control in WYSIWYG mode.

1. The editor will move elements around (source formatting, filtering or validation corrections), which breaks the tag map.
2. The user will move elements around, which breaks the tag map.
3. The user may attempt to modify the macro, which breaks the tag map.
4. The user WILL change the link text - because it's not obvious this is ignored by Media -, which breaks the tag map, as well as causes a UX WTF.
5. The current wrapper comments quickly get out of sync with the tag map because the numerical identifier must remain the same between attach/detach.
6. Multi-lingual content must have the same link texts etc because there is no way for the plugin to override or localize that on a per-macro basis.

I'm currently experimenting with this since it's driving users on two of my sites nuts. If it isn't fixed soon, I'll have to ditch Media completely while I still have the option of re-building all the content using it.

So far:

• I've removed the comment wrappers and I'm instead relying on finding a data-media_placeholder attribute in the placeholder img tag to find and extract the placeholder text using plain RegExps and string manipulation.
  The source order of placeholders/macros no longer matters because of this.
• To make resize and style changes stick between attach/detach I'm generating separate, simplified, macros for the tag map. Any macro that goes into the tag map has an empty attributes list, and any macro extracted from a placeholder has no attributes as well. On a detach, the macro is deserialized, the current attributes get extracted from the placeholder and then inserted into the macro, and the macro is reserialized again. The reverse happens when attaching. On insert, any new macro going into the tag map has attributes stripped first as well.
• On loading the edit form the tag map is always populated with multiple macro/placeholder pairs for each media item inserted, one for each allowed view mode. Creates a slight overhead, but at least compensates for users modifying that part of the macro when not in WYSIWYG mode.

This still has massive problems with:

• Multi-element placeholders (img with included caption) are untested. Even non-self closing tags aren't reliable as placeholders. Don't expect them to work.
• Download links can still not have their link text modified and have it stick. Partially because finding the closing a tag is a bit tricky unless implementing a parser. The current outerHTML() method is completely unreliable as it uses the browser to generate the markup, which sucks. I know, we do this in the Wysiwyg Teaser Break plugin as well, and I hate it because it completely messes up the source formatting and markup validity depending on the browser used.
• If any part of the macro, with the exception of the attributes or view mode parts, gets changed when not in WYSIWYG mode, there is no match in the tag map.

Next, I plan to basically implement what azinck suggested and pass the macro to the server when there's no match in the tag map and get a new placeholder from there. What worries me is the potential delay when doing this.
That still won't help a bit with the major issue of users not being able to change the link text "live". Not that I've yet to actually figure out how to find the closing a tag, or limit selection/manipulation to the topmost placeholder element while in WYSIWYG mode.

+1 that this is a big issue. Even minor actions like using alignment buttons in CKEditor are problematic because Media does not respect changes in its element's attributes.

We're addressing this issue in this thread: https://drupal.org/node/2067063 as it is related to the issues around attribute persistence.

EDIT: @TwoD, I completely agree with you about the wrappers. See thought (3) in https://drupal.org/node/2067063#comment-7936175.

I'm confused..

I have the same problem. I followed the issue mentioned in #5. It claims it is fixed. I have the latest dev - it's not fixed. I followed the issue that was created out of the issue from #5. That patch does not pertain to this bug..

So.. maybe we need to reopen this?

the work on this splitted off to #2126755: Improve Media's WYSIWYG Macro handling

I know #7 said this was to get taken care of in #2126755: Improve Media's WYSIWYG Macro handling but it never did. This is still a problem.

I don't expect this patch will get accepted. But it will at least make the tagmap generation more tolerant when it hits an html-encoded macro. Without this your WYSIWYG editor won't load due to a javascript error: TypeError: source is undefined

Oops, slight change. The fid might not be the first attribute listed in the macro.

Closing this issue as outdated. However, if you think this issue is still important, please let us know and we will gladly re-open it for review.
sincerely,
- the Drupal Media Team