Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
See http://drupal.org/node/195773#comment-855978
[workflow-current-state-name] shows the old state instead of the new state.
Proposed patch:
Disable caching in token.module:
function token_replace($original, $type = 'global', $object = NULL, $leading = '[', $trailing = ']', $options = array()) {
$full = token_get_values($type, $object, FALSE, $options);
return _token_replace_tokens($original, $full->tokens, $full->values, $leading, $trailing);
}
with
function token_replace($original, $type = 'global', $object = NULL, $leading = '[', $trailing = ']', $options = array()) {
$full = token_get_values($type, $object, TRUE, $options);
return _token_replace_tokens($original, $full->tokens, $full->values, $leading, $trailing);
}
Not at all sure of the most appropriate place where to post this issue, or even the category or status. Feel free to move, delete or re-categorize.
Comment | File | Size | Author |
---|---|---|---|
#12 | token_flush_5-dev-reroll.patch | 3.06 KB | MGN |
#12 | token_flush_6-dev-reroll.patch | 3.06 KB | MGN |
#10 | token-262360.patch | 1.16 KB | derhasi |
#7 | token_flush_5-dev.patch | 2.97 KB | Agileware |
#7 | token_flush_6-dev.patch | 2.97 KB | Agileware |
Comments
Comment #1
gregglesWell, we don't want to be flushing the cache by default. Definitely not. However, I can see how certain modules need to do that and shouldn't have to work too hard to do it.
This is kind of a question for eaton, but in my opinion the real solution is to expose control of flushing the cache to functions that call token_replace
So...I propose something more like:
with
What do you think?
Comment #2
gregglesI'd say this is normal, btw.
Comment #3
pete-drupal CreditAttribution: pete-drupal commentedYour solution is certainly more open than my original proposal.
The only (minor) issue I have is more conceptual: caching in general is supposed to be a performance optimization which is meant to be as transparent as possible. By exposing the control of the cache, it is no longer transparent; the caller of token_replace() must now decide on whether to enable or disable the caching mechanism. Based on what criteria? How can the caller decide? I'm assuming a black-box approach where the caller doesn't know about the implementation details of tokens.
I guess it would be up to the provider of token entries to document whether or not to clear the token cache for each type of token provided. If at least one non-cacheable token is to be replaced in a string, caching should be cleared or disabled for that token by the caller.
In fact, cache-support could be a property of a token, set by the token provider (maybe with the ability for a caller to override the preset in very tricky cases). But normally speaking, the caller should not have to be aware of all this.
But again, practically speaking, I don't see an issue to go ahead with the proposed change.
Comment #4
gregglesI'm not sure how uncommon or inappropriate this style is - node_load exposes control over the cache to the caller - http://api.drupal.org/api/function/node_load
I agree that knowing whether or not a call to a function needs to clear the cache can depend on a lot of things. In my experience it tends to depend on which other modules are installed on a site.
Comment #5
Agileware CreditAttribution: Agileware commentedI came across this issue and needed it changed so I've made a patch against the 5.x-1.11 version.
I am using the auto_nodetitle module and when creating multiple auto node titles from tokens at once you need the cache cleared or you get duplicate (and incorrect) titles.
I think it increases the usefulness of the functions and I can't see any reason why not to make this change.
Comment #6
Agileware CreditAttribution: Agileware commentedThere is a patch for auto_nodetitle that relies on this patch being submitted before it will work. It is here - http://drupal.org/node/355067#comment-1292104
Comment #7
Agileware CreditAttribution: Agileware commentedDoes anyone have any objections to adding this functionality?
Here is the patch re-rolled for the current D5 & D6 dev versions (both 2009-Apr-21).
Comment #8
mrjavum CreditAttribution: mrjavum commentedThanks, Agileware !!!
This patch helps me with this ussue:
http://drupal.org/node/452802
Comment #9
derhasi CreditAttribution: derhasi commentedI would not add a full flush to token, I'd rather add the opportunity to define an additional or custom token id, for example in the
$options
-array of functiontoken_get_values()
.So we could replace line 286 (in D6dev - within
token_get_values()
) with:This would avoid, that a huge amount of data has to be recached, when only one single object was needed to.
Comment #10
derhasi CreditAttribution: derhasi commentedcreated the patch for current D6-dev alike #9
- added
$options['flush']
for firing flush intoken_get_values()
- removed
$option['token_id_prefix']
to avoid ID duplicatesFor example I'm using that for differentiate between "loaded node" and "changed node" with suffixes "node" and "changed".
Comment #11
derhasi CreditAttribution: derhasi commentedAfter discussion on IRC with eaton and greggles best practice for that issue would be to use the patch in #7 by Agileware for the current DEVs (D5 & D6). So please ignore #9 & #10.
For a further view on Drupal 7's token, there will be opened an issue for further discussion on the general caching method for token, that will try to inspect the need and necessary complexity.
I also succesfully tested patch in #7 for D6.
Comment #12
MGN CreditAttribution: MGN commentedSame patches as in #7, re-rolled against the latest devs.
It would be great if this could be committed. I've verified that this can be used to fix the problem reported in #543506: Problem with tokens when using a custom_bredcrumbs_paths. That issue is postponed until this issue is resolved.
Please let me know if there is anything else I can do to help this along. Thanks.
Comment #13
MGN CreditAttribution: MGN commentedAny feedback on how to proceed with this?
Comment #14
hadsie CreditAttribution: hadsie commentedthe patch in #12 is working for me as well.
Comment #15
Agileware CreditAttribution: Agileware commentedWe just have to wait for one of the module maintainers to commit it I guess.
Hopefully someone will get time to do it soon as I have other issues that depend on this patch.
Comment #16
gregglesThanks all - now committed to 6.x http://drupal.org/cvs?commit=268510 and 5.x http://drupal.org/cvs?commit=268514
This problem no longer exists in the 7.x version of the module so I think we're as done as we can be with this issue.
Comment #17
Agileware CreditAttribution: Agileware commentedCool thanks
Comment #18
MGN CreditAttribution: MGN commentedThanks greggles!