The title should say it all. I'm in a situation where the content includes double-bracketed expressions (e.g., "[[something like this]]") that are not intended as file or image references.

However, the media module picks up these double-bracketed expressions, interprets them as buggy image references, and removes them altogether from the output. This might be related to #1070708: Validate Media Markup in Content, except that this bug concerns how the media filter processes these expressions on the server side rather than how the javascript translates them on the WYSIWYG editing interface.

I'm wondering if we might be able to return the original input rather than the empty string when one of these double-bracketed expressions is encountered.

#15 1828580-media-double-brackets-15.patch550 byteslongwave
#10 1828580-media-double-brackets-10.patch1.08 KBlongwave
PASSED: [[SimpleTest]]: [MySQL] 1,094 pass(es). View
#8 1828580-media-double-brackets.patch1.05 KBlongwave
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1828580-media-double-brackets.patch. Unable to apply patch. See the log in the details link for more information. View
#1 media-preserve-double-brackets-1828580-1.patch873 bytesankur
PASSED: [[SimpleTest]]: [MySQL] 5 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


ankur’s picture

873 bytes
PASSED: [[SimpleTest]]: [MySQL] 5 pass(es). View

Here's a patch that changes the function media_token_to_markup(), defined in includes/, to return the original bracketed expression if it could not be converted into a file or image reference.

ankur’s picture

Status: Active » Needs review
ParisLiakos’s picture

Status: Needs review » Needs work

hmm, but then the media_tokens that fail rendering would appear as is? that would be bad...users seeing a json string in the middle of the body text would be not desirable.
maybe the best approach here would be to provide a media_tag_pre_render hook there? so lets say markdown converts this tag first if needed.

Did you try giving markdown filter higher presedence in text formats admin screen btw?
so markdown runs first and media then...or markdown try to convert and destroy media tags as well?

Dave Reid’s picture

Status: Needs work » Closed (duplicate)
siefca’s picture

I'm not using any WYSIWYG editor, just pure-text BUEditor, and also having this problem. The brackets are removed in PHP code, by filter.

gimpel’s picture

Status: Closed (duplicate) » Active

Same issue here when trying to blog something that uses BASH if tests with double brackets.
Thanks a lot for the patch! That fixed it here.

The patch is still applying fine against alpha2 with some hunks and fixes the issue.
Reopening this one because the other report got closed due to something like a brain fart (sorry).

thisisjusthowidoit’s picture

Issue summary: View changes

I ran across the same issue as 'gimpel' and the patch in this ticket fix it for me.

Will this patch work its way into the next Media release ?


longwave’s picture

Status: Active » Needs review
1.05 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1828580-media-double-brackets.patch. Unable to apply patch. See the log in the details link for more information. View

I am running into this problem with some chemical names embedded in my content. As an example I have [[2,2'-[ethylenebis(nitrilomethylidyne)]bis[6-fluorophenolato]]-N,N',O,O']cobalt in a node body and the first part of this is being cut off by the media filter. The patch in #1 worked for me though the files have moved so I am attaching a new patch.

I don't see how it's possible to distinguish between content such as my example and an invalid media tag; I think the filter should just leave unhandled tags alone.

Status: Needs review » Needs work

The last submitted patch, 8: 1828580-media-double-brackets.patch, failed testing.

longwave’s picture

Status: Needs work » Needs review
1.08 KB
PASSED: [[SimpleTest]]: [MySQL] 1,094 pass(es). View

Oops, not running latest -dev on my site. Let's try that again.

digitgopher’s picture

Fundamentally, what is the reason for buggy image references to be removed from the output? In general if there is a problem I would like to know about it so I can fix it, not make it harder to find.

Another thought is to make the expression syntax even less common. For example [[|*|]] instead of [[*]]. Of course, this is somewhat subjective and cumbersome but at least could help.

Or provide a configuration to let the site admin choose which behavior they want?

longwave’s picture

An alternative fix is to make the regex more specific:

define('MEDIA_WYSIWYG_TOKEN_REGEX', '/\[\[{.*?}\]\]/s');

or even

define('MEDIA_WYSIWYG_TOKEN_REGEX', '/\[\[{.*?media.*?}\]\]/s');
rameshbaddam’s picture

I like the suggestion from @longwave.
Better to use define('MEDIA_WYSIWYG_TOKEN_REGEX', '/\[\[{.*?media.*?}\]\]/s'); , this also avoids logs which are in not required

DamienMcKenna’s picture

At the very least it should check for [[{something}]] instead of just [[something]].

longwave’s picture

#10 still applies with fuzz, but the improved regex has been in use on my site for several months now with no issues, so I'm attaching this as a simpler alternative.

joseph.olstad’s picture

Thanks for the patch but it does not apply against 7.x-3.x . This was already fixed /dealt with in the 7.x-3.x branch , please review the 7.x-3.x dev release , see the related issue:
#2825653: MEDIA_WYSIWYG_TOKEN_REGEX in Media Wysiwyg module conflicts with other tokens, using double square brackets [[token]]

We'll fix this in 7.x-2.x once 7.x-3.x gets more mileage/reviews.

joseph.olstad’s picture

Status: Needs review » Closed (duplicate)