Blank WYSIWYG with existing multiple Media content

I don't have time to write a patch right now, but in my case the problem happens because the element doesn't have any children.

File: media_wysiwyg.filter.js ~ line 113.
Add to the conditional: && element.children().length > 0

// Parse out link wrappers. They will be re-applied when the image is
      // rendered on the front-end.
      if (element.is('a') && element.children().length > 0) {
        element = element.children();
      }

I am experiencing a similar issue (dev HEAD) and reported this a couple of weeks back.

WYSIWYG module's onBeforeSetContent and onGetContent call attach and detach on evey WYSIWYG editor. detach calls replacePlaceholderWithToken in media_wysiwyg.filter.js. However, in there Drupal.settings.tagmap is being emptied resulting in tag replacement faults in subsequent attach calls which calls replaceTokenWithPlaceholder.

See https://www.drupal.org/node/2328493

If I have the time I am going to look into this this week.

What fixed this for me was applying the patch in #2328493: Async behavior of wysiwyg plugin attach/detach leads to some media tags not being replaced in time to 7.x-2.x-alpha4, maybe for you too?

I am having this exact issue; however, I only have ONE media element in the body, and I only have ONE wysiwyg-enabled textarea on the page. I am running latest media module code which includes the patch from 2328493.

So there must be some other outlying cause... :(

I am using Commons, CKEditor, Media module. Incidentally, user 1 does not experience the issue, but both people with the 'administrator' role do.

I get the error: Uncaught TypeError: Cannot read property 'tagName' of undefined when there is a summary and body field that contain existing markup.

I found tom friedhof's patch here that fixes this issue for me applying it against 7.x-2.0-alpha4. The patch is identical to the on from 7.x-2.0-alpha3 version, I just re-rolled it against 7.x-2.0-alpha4 for this issue (filename and all) and will give proper authorship to Tom.

oops fixed path in patch to not include www/sites/all/modules/contrib/media. re-rolled.

Patch works for me! thx.

It's worth mentioning that "my" patch from Tom only allows the javascript to continue to execute. It does not actually fix the problem of the unknown 'tagName' property. This is a temporary fix before finding the real fix. Due to circumstances we were kind of forced into updating the media module in production and we needed existing nodes to be editable.

Few questions for everyone:

Can you reproduce the problem using http://simplytest.me/project/media_dev/7.x-2.x? If so, what are the steps?

Is this problem only happening with the CkEditor module or with WYSIWYG module and TinyMCE?

What browser is this happening in?

I suspect the problem in #11 and 12 might be related to #2028253: If you change a file's information with the WYSIWYG disabled, re-enabling the WYSIWYG loses the file -- try the patches there.

I get this with the latest 7.x-2.x with WYSIWYG and TinyMCE.

The odd thing is that Drupal.settings.mediaDataMap has only the first fid as a proper key, all other elements start with index 0 (see attached screenshot).

My first guess is that something interferes with media_wysiwyg_token_to_markup (specifically the settings added in http://cgit.drupalcode.org/media/tree/modules/media_wysiwyg/includes/med...)

Will try to debug this more tonight, but hope it helps steer the issue in the right direction.

Cheers,
Dan

Same problem here, also using WYSIWYG module (7.x-2.0-alpha4) with TinyMCE. There are three WYSIWYG enabled fields on the node.

I note that the media token is outputting a link that's relative the the public:// files directory and does NOT start with the files dir path itself. That makes the media asset throw a 404 when the editor loads. That's probably not helping, huh?

When I add the patch from #12, the WYSIWYG loads, but doesn't show the field content and I get an error thrown on this line instead:
Uncaught TypeError: Cannot read property 'length' of undefined
if ($('<div>').append(html).text().length === html.length) {

Both of the following debug lines print an empty line at this stage.

console.table(Drupal.settings.mediaDataMap);
console.table(Drupal.settings.mediaSourceMap);

... logged in as user #1, so that user is not exempt.

I have rolled back to media 7.x-2.0-alpha3 with the following patches appled and the issue has gone away.

• https://drupal.org/files/media.media-browser.1956620-10.patch
• https://drupal.org/files/media.code_.1701914-2.patch
• https://drupal.org/files/media-857362-selection-bookmarking.patch

Confirming this issue. And here to describe some weird behaviour just in case that helps uncover the problem further for anyone.

Toggling the "Disable rich-text" link at the bottom of where the wysiwyg should have been made it appear. But toggling it back and forth also duplicated the buttons. Again, and again. ;)

Here's a fun screenshot of what I ended up with.

I managed to trace this to commit 72be229
ebf1d572 which fixed #2307993: WYSIWYG filter removes script tags.

Commenting out Drupal.settings.tagmap = {}; in media_wysiwig.filter.js:L74 fixes the issue for me.

Cheers,
Dan

After plenty of testing, here is a patch against 7.x-2.x that incorporates #2317519-12: Blank WYSIWYG with existing multiple Media content and #2491569: Inserting HTML with token that has unknown FID leads to fatal JavaScript error as well as removes Drupal.settings.tagmap = {};.

The code that follows in replacePlaceholderWithToken rebuilds the tag map, so it will be up to date in case the macros have changed. Any stale macros will be ignored.

A potentially better solution would be to only clear the tag map per WYSIWYG editor instance, but that opens another avenue for errors.

The patch in #22worked for me with the latest dev of Media and File Entity -2.x with Wysiwyg module + TinyMCE 3.5.8

The patch in #22 eliminated the JavaScript error I was getting (something about the source variable not being set) that was causing Ckeditor not to load properly in the Summary of the Node Body when an image had been added and saved.

However that has uncovered (or caused?) another problem. I created a new issue here: #2497529: Media module token encoded with HTML entity quotes

I experienced the same as #24: If I install the patch, my editor loads again, but it now shows the token instead of the image.

In my case, however, everything seems to work correctly if I just comment out the line with Drupal.settings.tagmap = {}; and leave everything else as it is.

#24 and 25 -- please try the patch in #10 here: #2028253-10: If you change a file's information with the WYSIWYG disabled, re-enabling the WYSIWYG loses the file -- I strongly suspect that's your problem.

@azinck: In my case that didn't help at all. I had already tried it actually, but I just tried it again and it still didn't help.

@reswild: Do you mean you added back the Drupal.settings.tagmap = {}; line? The patch removed it.

Thanks, azinck. #2028253 looks like the same issue I experienced, except that in my case it happened every time I opened and saved the node in TinyMCE - I didn't need to disable and re-enable WYSIWYG, or edit the file info. Your patch still worked as it should when I tested it.

@jlea9378: No, I mean the other way around. Removing the Drupal.settings.tagmap = {}; is the only part of the patch that I'm using, and that seems to be working for me.

Thank you @azinck, I was having this issue, I resolved it by applying #22 from this thread and #10 from https://www.drupal.org/comment/9569105#comment-9569105.

EDIT: Having done this a couple of times now the #10 from the other thread was not necessary for me

Removing Drupal.settings.tagmap = {}; also worked for me (comment #21).

#4 fixed it for me, adding && element.children().length > 0, thanks heddn.

The patch #22 works, but I think the removal of Drupal.settings.tagmap = {}; is enough to fix the problem.

Based on the number of people that used #22 to fix the issue, I think I can change the status of the issue :)

After a failed attempt at patching, I resolved the problem by following post # 21. I attempted patch # 22, but it failed with the following messaging.

Checking patch modules/media_wysiwyg/js/media_wysiwyg.filter.js...
error: while searching for:
if (!media && media_definition.fid) {
Drupal.media.filter.ensureSourceMap();
var source = Drupal.settings.mediaSourceMap[media_definition.fid];
media = document.createElement(source.tagName);
media.src = source.src;
media.innerHTML = source.innerHTML;

error: patch failed: modules/media_wysiwyg/js/media_wysiwyg.filter.js:44
error: modules/media_wysiwyg/js/media_wysiwyg.filter.js: patch does not apply

I'm running Drupal 7.41, Panopoly 7.x-1.28, Media 7.x-2.0-alpha4, Media WYSIWYG 7.x-2.0-alpha4.

The patch is against 7.x-2.x-dev, not 2.0-alpha4... that's your problem there @eawheeler

Edit: Though it applies cleanly to 7.x-2.0-beta1 too :-)

That makes sense @cafuego. I'm stuck on Media 7.x-2.0-alpha4 due to a Panopoly dependency. But I can't expect a patch targeted at 7.x-2.x-dev to apply cleanly.

Just deployed the #22 patch with 2.0-beta1 on a client site and happy to report it resolves the issue.

I was able to move onto 2.0-beta1 and I can confirm along with cafuego that patch # 22 applies cleanly and resolves the problem.

We were also experiencing this issue, but ONLY on textareas within an IPE-generated modal dialog. The referenced patches did nothing to fix, but we did find a seemingly unrelated patch that does in fact fix the issue as outlined by OP. Here it is for anybody in a similar situation:

https://www.drupal.org/node/2262107

With the most recent patch applied to DEV we are now able to successfully use WYSIWYG in IPE dialogs with embedded media objects...

Just applied the patch from #22 to Media 2.0-beta1 on a client site locally and in our dev environment. It applied cleanly and fixed the issue. Thanks!

#22 did the trick for me. Many thanks.

#22 did the trick for me as well.

Regarding the patch from #22, there are two changes. One is skipping the current iteration of a loop if source is undefined and the other is removing Drupal.settings.tagmap = {};

The problem for me is a token for an image being copied in, like this:

[[{"fid":"1426","view_mode":"default","fields":{"format":"default","field_file_image_alt_text[und][0][value]":"","field_file_image_title_text[und][0][value]":""},"type":"media","link_text":null,"attributes":{"class":"media-element file-default"}}]]

The error resulting from this is that Drupal.settings.mediaSourceMap[media_definition.fid]; is undefined when the image is being copied from the content of another node. I'm not sure if it is a bug or a feature that I cannot copy an image from one node to another.

All the patch really seems to do is "I can't find the fid, so I'm just going to give up and just display the raw token", is there a way to make this work with pasting the token from media of another node?

@smerny: try #2028253-10: If you change a file's information with the WYSIWYG disabled, re-enabling the WYSIWYG loses the file

It's not perfect, but it should keep things from actually breaking. You won't see the copied media element get properly rendered in the WYSIWYG when it's embedded, but you should be able to save the node and things should work properly after that. The problem is that the tagmap is built when the page is loaded and when the media widget is used to insert new elements. There's no support in the WYSIWYG for rendering media elements that are "manually" embedded via the source view.

@azinck: yes that does seem to be working (using it along side #22 to prevent the js error), although not very friendly for the users in my case. thanks though

The fix at #2028253-10: If you change a file's information with the WYSIWYG disabled, re-enabling the WYSIWYG loses the file suggested in #46 above doesn't appear to be necessary for me. When I copy a token from one node to another the token appears in the rich text editor but there seem to be no adverse effects otherwise (with or without the suggested fix).

I have applied the patch in #22 as-is and it works well to solve the JS error. Thanks for that.

media 7.x-2.0-beta1+10-dev
media_ckeditor 7.x-2.0-alpha1+4-dev

#22 worked for me. Applied cleanly and all functionality returned.

I could really use some instructions on how to reproduce this to help confirm that #22 fixes this. #15 also asked for the same but I don't really see it answered.

Hi Dave,

Took some time to dig out the exact details for this. Here's a short screencast illustrating the issue - https://www.youtube.com/watch?v=RWZGddVqg1M

Basically:

- Have more than one text field with wysiwyg enabled (wysiwyg, media_wysiwyg, tinymce)
- Add files to 2 of them. Add text in at least two instances. Save.
- Edit the node. Only the first instance content is showing in the wysiwyg, the other instances appear completely blank.

Hope this helps

Confirming comment #51 covers the steps needed to reproduce.

Displaying and testing with more than two fields will really highlight the behavior issue. I suggest at least 3 fields, because when only trying two fields it's a 50/50 split (one works, one doesn't), but when using three or more WYSIWYG fields with media tokens the issue becomes clear.

I just ran into a similar problem as well; my ckeditor stays blank and an error about source being undefined.

In my case, it is because the media-item which is in my body text has an alt with an & in it.
I traced it down to just above the replaceTokenWithPlaceholder-code where it tries to find the item in the tagmap (which is built in the _media_wysiwyg_generate_tagMap function).

The regex extracts the media-tag properly with the escaped & but the tagmap contains the unescaped &. This means media is undefined :(

This is the media tag:
[[{"fid":"319","view_mode":"full","type":"media","link_text":null,"attributes":{"alt":"Some nice & awesome alt text","class":"media-element file-full"}}]]

Using a file with a different alt (without &) and it works fine.

Attached is a patch with the patch in #22 together with a simple fix (?) for my issue: the mismatch between tagmap and the tags in the content.

I added a htmlspecialchars in _media_wysiwyg_generate_tagMap that encodes the tags.

I found a little bug in my patch; it double-encoded existing &'s into & which broke the tagmap again.

Fixed this by preventing htmlentities from double-encoding with the last boolean argument.

I ran into a version of this issue and (like some others said above) simply removing the Drupal.settings.tagmap = {} was enough to fix it for me, so here's a patch that just does that without any other changes. It might be good to get it committed just with this and then discuss other changes later or in separate issues, as they may be for other bugs that are only somewhat related to this one?

Here's another set of steps to reproduce, which is how I experienced the bug:

1. Make sure that whatever text format uses the WYSIWYG is the default text format for your user account (i.e. appears selected by default when creating new content).
2. Use the https://www.drupal.org/project/autosave module and configure autosave for a particular content type.
3. Go to the content creation page for content of that type, embed an image in the WYSIWYG, and wait for the autosave to happen.
4. Reload the page and click "Restore" in the autosave popup.

Presumably what happens is that after the Autosave module's Ajax request, Drupal.settings gets merged by the core Ajax system (so it has the correct tagmap), but then when the Ajax command replaces the form on the page, first the WYSIWYG editor gets detached (which empties out Drupal.settings.tagmap due to the above-mentioned code), so that when it is reattached with the new content it breaks due to Drupal.settings.tagmap being empty.

I did not see any side effects from simply removing that code yet, and looking through #2307993: WYSIWYG filter removes script tags it is not obvious to me why that issue needed to add it in the first place.

I am wondering if this is related to issue #2262107: Cant insert Document in Media Wysiwyg

I was experiencing the same issue where pasting a token in a wysiwyg would throw a JS error and subsequently fail to actually paste the content.

Path in #55 solves my issue with a sizeable caveat: tokens no longer get parsed the first time around. So while it does fix the JS error, it does not fix the underlying problem of the token failing to parse, it merely makes it fail silently (which is still an improvement in my use-case)

Steps:
- Make a node, inject a media token like you normally would.
- Hit "Disable rich text" and copy the entire content
- Make a new node, disable rich text, paste the content and enable rich text

Result: Token is not parsed in the wysiwyg display, but it is once the node is saved and rendered.

If you now edit that node and disable rich text, paste, enable rich text, the token will be parsed successfully.

So it would seem that as soon as the Media browser or the form handler have had a chance to "attach" the file to the node(-form), it gets parsed successfully.

The patch in #55 is the only one that fixes all my blank WYSIWYG issues.

The only problem I have with it is that I am still getting encoded alt text characters outputting to the user.

This is because the encoded value from the tag map is getting used and then Drupal.media.filter.outerHTML() is encoding the markup, giving you double encoded markup.

So either var media = Drupal.settings.tagmap[match]; needs to handle encoding in the match variable or var element = Drupal.media.filter.create_element(media, media_definition); needs to do some sort of decoding before it creates the element.

Also, I agree that the ampersand issue addressed by #55 should be a separate issue.

I opened another issue for the character encoding problem (re #55) at #2788397: Encoded characters in media token break rendering.

I think for this issue we should commit the patch in #56.

fixed in 7.x-2.x dev branch