Fix for replacePlaceholderWithToken in media_wysiwyg.filter.js

We had a bug as described in Wysiwyg embeds breaks in Firefox and IE.
Bug occured as you pointed out in IE and FF.

Test results

Before patch applied

Opera(W8) 12.16 OK
Firefox (W8) 26.0 FAIL
Chrome (W8) 31.0.1650.63 OK
IE9 (W7 VM) FAIL
IE10 (W7 VM) FAIL
IE11 (W8) FAIL
Safari (W8) 5.1.7 OK

After patch applied

Opera (W8) 12.16 OK
Firefox (W8) 26.0 OK
Chrome (W8) 31.0.1650.63 OK
IE9 (W7 VM) OK
IE10 (W7 VM) OK
IE11 (W8) OK
Safari(W8) 5.1.7 OK

Test conclusion

Testing confirms that patch does solve the issue!

Thank you for posting this issue with the patch!

@das-peter - this is a much cleaner solution than one I was working on. I've added it to a slightly broader topic because it covers a piece of the issue at hand. Closing this one out as a duplicate of #2126755: Improve Media's WYSIWYG Macro handling as we should (and have) consolidate our work on a single thread.

In our case the provided patch results in a "TypeError: this.cloneNode is not a function" JS error in some cases. I guess that that is because there can be content that does not have any media-element items in it and therefore "this" will be the "window" object instead of a media-element.

I changed the code into the following to solve this (probably there is a cleaner way to do this?):

  content =  $('<div>' + content + '</div>');
      $('.media-element', content).each(function(i, element) {
        $(this).replaceWith(function() {
          var markup = Drupal.media.filter.outerHTML($(element));
            macro = Drupal.media.filter.create_macro($(element));
          // Store the macro => html for more efficient rendering in
          // replaceTokenWithPlaceholder().
          Drupal.settings.tagmap[macro] = markup;
          return macro;
        });
      });
      return content.html();

I am going to reopen this as addresses an immediate bug and I see no reference of this code in the others issue patch which doesn't correct the problem.

@sylus - the reference to this patch being included in the work from #2126755: Improve Media's WYSIWYG Macro handling can be found here: https://drupal.org/comment/8361293#comment-8361293. All subsequent patches on that thread include the approach used here.

So … closing.

I think this patch is still useful at least for now.

In the version of the module I am running this is an issue that needs addressing.

Once #2126755: Improve Media's WYSIWYG Macro handling is fully finished then this issue likely not be relevant (at least once they have addressed the problem mentioned in #97 & #99 of that issue).

Thanks for this patch, it fixes the problem described in my current module versions:
* media 7.x-2.0-alpha3+77-dev
* file_entity 7.x-2.0-alpha3+17-dev
* ckeditor 7.x-1.13+22-dev

However it is not compatible with the the latest versions:
* media 7.x-2.0-alpha3+90-dev
* file_entity 7.x-2.0-alpha3+17-dev
* ckeditor 7.x-1.14+2-dev

In newer versions of the media module I don't ever see the [[{fid...}]] tokens. Only ever the image markup.

Based on #97 & #99 of #2126755: Improve Media's WYSIWYG Macro handling I'm assuming that this newer problem will be fixed there.
If it does not I will reopen #2279749: Media in WYSIWYG no longer shows rendered entity as this issue is really for a different problem.

Unfortunately I don't see this patch being committed due to the recent media changes (so not marking RTBC), however this patch will still remain useful to users running older versions.

#8 works for me thanks!

#8 seems to resolve an issue we have with Firefox where upon save, the image(s) are shown in the wrong view mode. We've tested this with media 7.x-2.0-alpha3+29-dev, and we'd love to see this problem fixed. Does the patch need to be re-rolled, or did something fundamentally change since then? Thank you!

The module has changed since then, so this patch is no longer relevant for the latest dev version.

It is however very useful for those of us running slightly older versions.

Hopefully when #2126755: Improve Media's WYSIWYG Macro handling is finished this issue will be redundant.

The patch at https://www.drupal.org/node/2832384#comment-11814293 should correct this issue as well. It uses the $.replaceWith approach suggested in the original issue, and is rolled against the latest 2.x-dev branch.

I marked it as duplicate, but could very well have been marked as 'closed outdated'.