media wysiwyg tokens with html are corrupted on save

Thanks for the issue.

A workaround would be to use media_ckeditor module and configure it accordingly.

so you're using the wysiwyg module with the ckeditor library, this is good to know, I didn't realize that the media module was being used that way. It'd be nice to make media play nice with your configuration as well.

not sure if this is a bug yet, it might require a combination of documentation or some helper code to help people figure out the configuration easier.

if this does require a patch, it'd have to be written in a way that doesn't break the standard implementation that uses media_ckeditor

How about we start by isolating when this started to occur, so this is since 7.x-beta2 according to the description, however if you are able to restore your database, could you go back to beta6 and see if the issue occurs there?

Note: it could be a configuration issue as well, media since beta8 no longer uses variables to store certain configuration
#1792738: Allow custom file view modes for WYSIWYG display

and this commit:
http://cgit.drupalcode.org/media/commit/?id=31e20aef657ac223f58c3d9228cd...

This change I speak of came in at beta8.

If you wanted to upgrade to something newer than beta2 then I'd suggest beta6 in the meanwhile, unless of course you're willing to continue helping us fix this.

any ideas?

as for file entity, I recommend the latest version of file_entity.

You might also want to try these two patches for file_entity, this is what I use.

- projects[file_entity][patch][2000934]
https://www.drupal.org/files/issues/allow_selection_of-2000934-30.patch

#2000934: Allow selection of which folder a file is to on the file/add form

- projects[file_entity][patch][2198973]
https://www.drupal.org/files/issues/file_entity_override_widgets-2198973-01.patch

Not sure if this suggestion will help at all.

Ok, thanks, hope we can resolve this soon.

I've run into this as well (or at least I think it's the same issue!)
My setup has file_entity 7.x-2.0-beta3, media 7.x-2.0-beta10 with media_wysiwyg also enabled, ckeditor 7.x-1.17 and media_ckeditor 7.x-2.0-alpha3 (i.e. latest stable versions of all those as of today) plus a couple of patches to media_ckeditor for unrelated issues.

I have a long-text caption field on my image file entity type, which I allow to be overridden in the media browser.

What appears to be happening is that the recent versions of media_wysiwyg and media_ckeditor use an identical code pattern to check for html-formatted fields in the overridable fields (identified by having both a value and a format), and then ensuring that the value-which-possibly-contains-markup is URL encoded so that it doesn't break the JSON value in the media token. This makes sense, and those tokens are swapping between token and markup much, much better now than they were in previous versions.

Unfortunately neither module seems to have implemented anything that decodes that field again. The media_wysiwyg_filter_field_parser function has a comment that "Fields that use rich-text markup will be urlencoded", but nothing I could find actually decodes those values, and so the URLEncoded value value is what appears when the file entity is actually rendered, and also when you attempt to edit the fields again.

I've made a patch to that function to notice format-and-value tags, and to URLdecode the values when appropriate. This has solved the issue for me, and should do so for people using WYSIWG rather than CKEditor and Media-CKEditor as well, due to the shared code pattern. This should work with both 2.x-dev and 2.x-beta10, since those are currently the same commit.

ok great stuff @LittleRedHen , while you're into it and if its not too much trouble can you also confirm that this patch is safe /compatible with media_ckeditor configurations?

@LittleRedHen, wondering if this type of condition should be used?:

 if (!module_exists('media_ckeditor')) {

@joseph.olstad - Using media_wysiwyg with media_ckeditor is actually my use case. The URL decoding is definitely still needed when media_ckeditor is in use, because media_ckeditor uses an identical processing of html values in its override of Drupal.media.formatForm.getOptions.

There may be a more appropriate location for this fix, though. It does need to be part of the token-to-markup filter, but perhaps media_ckeditor ought to implement hook_media_wysiwyg_token_to_markup_alter and do its own URLDecoding in order to reduce the co-dependecy between these two modules a bit? Or else perhaps the handling of HTML-field override ought to be refactored out of Drupal.media.formatForm.getOptions into something that media_ckeditor isn't overriding?

The patch at #19 is a bit of a quick and dirty solution that will get my production system functional again (I use drush make for deployment so need a linkable patchfile). Actual integration may need a bit more design work...

@LittleRedHen , I think your patch is better than no patch. RTBC? commit?

fixed in dev branch , beta11 will be comming soon, maybe tomorrow or a few days from now.

I have a (possibly) related problem, but this patch does not help me at all. I have opened a separate issue at #2832384: media_vimeo and media_wysiwyg tokenhandling broken except when using the dev version of wysiwyg.

I can confirm that this patch fixes the same error if you happen to be using ckeditor_media with wysiwyg rather than media_ckeditor. Thanks for the patch!

I know this is several years old, but I am having the exact same issue.
In my case it is only happening when only one input format is available on the textarea (by using better_formats module) and there is no format select element in the form. If there is more than one format and the select box is present, it works.

im using Media 7.x-2.x-dev

@loze , if you have a screenshot handy, maybe attach it.