Closed (fixed)
Project:
Custom Formatters
Version:
6.x-1.4
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
9 Oct 2010 at 05:49 UTC
Updated:
29 Mar 2011 at 21:24 UTC
Jump to comment: Most recent file
Comments
Comment #1
dave reidHooray! Another module that uses a private internal of token.module that shouldn't have.
Comment #2
butler360 commentedSubscribing.
Comment #3
chrisal commentedComment #4
derekdunagan commentedTo fix this issue, replace line 399 of custom_formatters.module:
return _token_replace_tokens($formatter->code, $full->tokens, $full->values, '[', ']');
with:
$tokens = token_prepare_tokens($full->tokens, TOKEN_PREFIX, TOKEN_SUFFIX);
return str_replace($tokens, $full->values, $formatter->code);
Comment #5
jdwfly commentedGood job drkdn, I can confirm that his fix works.
Comment #6
joelstein commentedHere's a patch of #4. Works for me.
Comment #7
decipheredCommitted to DRUPAL-6--1
Comment #9
pianomansam commentedPatch provided in #7 confirmed to resolve this issue. #7 states that this patch committed to DEV version, but has yet to make it production version, therefore I've reopened this issue with the proper status until the maintainer gets this patch into production code.
Comment #10
SchwebDesign commentedthanks for reopening this- it helped me find the issue as well.
Comment #11
leosat commentedDear commiters, please, patch the module!...
This issue forced me to make my custom module with the following thing (WHICH IS A WRONG PATH, but it allows me to update custom formatters modules without the authors applying the necessary patch):
<...>
function _token_replace_tokens($code, $tokens, $values, $a = '', $b = '') {
$_tokens = token_prepare_tokens($tokens, TOKEN_PREFIX, TOKEN_SUFFIX);
return str_replace($_tokens, $values, $code);
}
<...>
Comment #12
Rhicreate commentedsubscribing to bookmark patch until it's in production release.
Really useful module though, can't believe I've only just discovered it.
Comment #13
jdwfly commentedJust in case you don't know this, if something is committed to the dev branch it is considered fixed. Just because it hasn't been made into a release is no reason to reopen a fixed issue.
Comment #14
pianomansam commentedThank you for the insight, jdwfly. What is the proper channel, then, to request that a bug fix be brought to the production branch from the dev branch?
Comment #15
victoriachan commentedI need to apply this patch to the 6.x-1.4 version. So I've made a new one for 6.x-1.4. It's identical to the one submitted above, except for the line numbers.
Cheers.
Comment #16
tsvenson commentedOki, I am now quite upset that this patch hasn't triggered a release of a new official version.
I have spent half the night trying to find out what caused the infamouse #434394: 'HTTP error 0 occurred' on image upload issue on a site I am working on.
After finally finding http://drupal.org/node/659206#comment-3001506 I got past that, just to hit this issue instead. As soon as I patched it I turned AHAH back again and it worked without problems.
It's solved for me, but I am certain others will run into the same problem unless this module gets a new release with this fix included.
Comment #17
nicholas.alipaz commentedJust thought I would say that I too would like to see a new release that has this. I hadn't noticed it and it was a critical bug so was breaking my sites. A critical bug certainly merits a new release IMO.
Fixed on October 13th 2010 http://drupal.org/commitlog/commit/12788/59718f038cc0ef71b988473e91f4f21...
Last release March 1st, 2010 http://drupal.org/node/729904
Todays date March 29th, 2011!