Colorbox does not work in WYSIWYG after updating to Media 2.0-unstable7 and Media Colorbox 1.0-rc3

Victoria: I have this problem as well, and it might be a Media problem rather than a Media Colorbox problem per se. You can work around it by using devincarlson's Media Wysiwyg View Mode sandbox project, located here: http://drupal.org/sandbox/DevinCarlson/1823634

This module allows you to "tell" the WYSIWYG editor to only display a certain formatter (in my case, Preview) WITHIN the edit box, and actually transition to the selected view mode once the node is saved.

In my case, we do the following:

1. Set up "Teaser" as the "colorboxed" view mode
2. Set up "Preview" as an image thumbnail. This is the first half of the view modes selected in the Colorbox settings for Teaser.
3. Set up "Colorbox" or "Original" as the actual image. This is the second half of the view modes selected in the Colorbox settings for Teaser, which shows up in the colorbox as planned.

The sandbox will make sure that only the "Preview" thumbnail shows up within the edit iframe, which prevents the error you're seeing.

Yeah, what I posted is definitely a workaround and I ran into the same sub-issue with image view modes and so on.

Attached is a patch I came up with that seems to solve the problem. It's not yet heavily tested, all I did was check the WYSIWYG stuff. Using media colorbox for images in fields etc. is still untested.

Essentially the patch directly uses the available file as given from the media browser (with $file->override['wysiwyg'] == TRUE) to the theme function. The theme function checks for this override and, if present, simply renders the preview view of the image, rather than outputting a link etc.

The WYSIWYG content that's shown if you disable rich text, is of the [[{'fid': .... }]] form, as expected.

I've tested the patch, and it works great! Well, minus one small detail, and maybe I'm just going about this the wrong way. Before, I could insert the image using media, and then double-click the image which would bring up the image properties dialog box. Within here, I could choose 'align left' or 'align right'. Since I applied the patch, It aligns properly in the editor, but when I actually view the page it does not. Is there maybe an error in the patch? Or, is there a different/better way to align images in content with media?

Great work! I can confirm that the patch works as expected! :)

Nevertheless I want to mention that using Wysiwyg + CKEditor lib + Media Colorbox cost me lot of time to get it to work as expected. Out of the box, the actual output on the page was full of junk like contextual-links (even visible for anonymous guests!), an invisible h2 plus a div-wrapped output, which caused another problem: the invalid markup with the divs inside a link, that itself is sitting inside a paragraph. While I thought, that would be ok - but still ugly - in HTML5, Firefox and Opera (didn't test others) were rendering the <a> element twice - although it was only appearing once in source. Which lead me to the problem that I had duplicate images in the colorbox. To get a better idea, of what I mean, please have a look at the original issue summary above, where you can also see all this extra markup.

The output is coming from the file_entity.tpl.php template because the image is rendered as entity. By removing all the extra markup there, I solved my little problem - additionally one may also override theme_media_colorbox() and use the media_colorbox_strip_only() function to clear both links and divs.

The question now is: is this a bug or a feature? And who's responsiblity is it to get this working out of the box? Should the Media Colorbox module do more and better cleanup or does file_entity provide a bad base template? Hard to say from my perspective, as I avoid using view modes for files for image fields, preferring the image field formatters. The only thing I can see is, that when using "normal" file view modes (=without Media Colorbox) within Wysiwyg + CKE, I never had these problems. So it seems that the Media module is rendering images differently

I can confirm that patch from #5 fixed the issue for me.

My way to work this out was overwrite the formatter by showing just an image for edit and format-form form this added my data without any problems. Why I did something like that? Seems like this problem is bigger than just media colorbox module. If you have colorbox module installed then you can start using colorbox formatter and it will fail becouse this will add data with a link. I really did my own module and learned all this by doing it.
This code under my text is just an example and could maybe help to solve this..

  if (arg(2) != ('edit')&& arg(2) != 'format-form') {
    return l($image, $variables['link']['path'], $options);
  }
  else {
    return $image;
  }

But the real reason http://drupal.org/node/1451316

Thanks for your input. That looks very promising. I'll give it a try, when I face this problem the next time! :)

I fixed the problem with the attached patch.
Instead of rendering the whole file entity I just render the file portion of the entity.

I just wanted to say that #12 worked better in terms of the wysiwyg. I tried out #5, and for some reason it was rendering the 'img' outside of the 'a' '/a' in a separate 'div' and so the preview file display showed up properly in the wysiwyg editor, but in the actual content view, there was nothing to click on as the 'a' for the colorbox trigger was misplaced.

However, using #12 in the content view, the preview file view (large filetype icon) is shown now instead of a thumbnail of the video (understandable).

Let me step back... i have setup things as shown in #1. I have created a thumbnail and added it to the the video file type as an image field.
Now prior to applying the patch, i would get the thumbnail rendered properly in the wysiwyg editor, and properly in the content page where i inserted the video, however as discussed here, there was a whole bunch more markup in the editor.

What i was doing prior to the patch was to just edit the source after inserting the video and manually removing all this extra markup. That worked, but is tedious.

So i applied the patch #12, all that extra markup is gone as expected, however the preview thumb is no longer showing (understandable) and in the content view itself, i just see the large filetype icon and not the thumbnail.

I suppose i could probably fix this by not inserting it through wysiwyg but rather using a view.

Im a bit of a drupal newbie here so im not sure of another way to fix this.. is it possible to change the file_entity template maybe?

Thank you very much for your efforts here.

Tom

You can easily override file_entity.tpl.php in your theme (copy the file to your theme's directory, then remove all the markup from there).

I encountered the same problems with the markup in the final result. I've edited my patch to always simply render the file (similar to #12). The major functional difference with #12 is now that no link is created for the WYSIWYG output, which may solve problems getting the thumbnail to show up in the WYSIWYG editor (I'm not sure).

I think this approach is similar to what's being done elsewhere. A few minor touch-ups needed on the patch though:

if($file!=NULL){

Code style. We need some spaces in there.

+ //'text' => drupal_render($variables['item']),

This is obviously not the way to do this, so lets just pull it out completely.

This patch doesn't solve the issue for me. I still have the wrong encoded media placeholder and the colorbox does not work.

I've applied the patch in #14 and it seems to work. However, it writes the html directly in the field. Shouldn't it use a media placeholder, so I could change the colorbox view mode, and have that applied to everywhere where I used the colorbox view mode to show my image?

True. I realized that I am facing the same issue described in #8. Using the instructions in #1 I have a kind of usable solution.

For those using media 7.x-2.x, there was a similar problem here: #1942688: Documents embedded in WYSIWYG get converted to HTML by the editor.

I suggest applying that fix along with this one or switching to the dev branch of media before trying this patch.

With both patches applied, the media syntax remains the same for me.

+1 to #14. Works with latest media(2013-Jul-03).

The patch in #14 does not work for me using the latest dev checkout of media 2 and the dev checkout of media colorbox.

I'm not certain what I've done differently that's caused it not to work. Can anyone shed some light on this?

@Greg Boggs: This might be settings problem. You should enable ONLY "Media Colorbox" display on "admin/structure/file-types/manage/image/file-display/colorbox". One additional thing i noticed, but didn't look for fix, is that you MUST TOTALLY uninstall previous versions of modules before installing latest dev versions.

I'll try again from a fresh install with the latest dev of all modules. I've committed two patches and I'd like to make sure other patches didn't break this one.

Updated incorrect file path

diff --git a/media_colorbox.module b/media_colorbox.module
old mode 100644
new mode 100755

These file permissions changes should not be in the patch.

Here's a reroll without them. (No other changes.)

I finally managed to make this work by using the suggested version of Media colorbox and enabling the Media WYSIWYG View Mode module and also the Colorbox under the admin/structure/file-types/manage/image/file-display/colorbox.

So does #25 mean that this does actually work?

"you MUST TOTALLY uninstall previous versions of modules before installing latest dev versions" means that an update script is needed.

Media WYSIWYG View Mode module is deprecated (well, removed really).
I could not get this to work with file_entity module 7.x-2.0-beta3, media module 7.x-2.0-beta8+2-dev and colorbox 7.x-2.12.

I believe you may be correct in that this module no longer works with the latest release of the media suite for D7. I opened an issue in the Colorbox module because Colorbox is 95% there now that Media switched to using built in Image fields, but that ticket got no attention. So, I believe the path forward is either to update this module to work with the latest media suite, or to write a small patch for Colorbox to fix video support as a part of Colorbox.

~Greg

Attached patch fixed the problems I was having. The previous patches don't seem to have any bearing on the problem anymore.