From #2055307: Is there any valid reason why this filter can't cache?:
As for the context, the concept is that upon saving/updating any entity that is using this filter and has valid tokens in the available text fields, the tokens would be modified to add enough context so that when the tokens are processed an entity_load() function could be called.
Obviously to do this a non-standard token format would have to be used, but then during the process stage the token would be transformed back to it's original state before being passed through token_replace().
Something like: [current-date:year|entity_type:node|entity_id:1]
In Wysiwyg Fields, I also used a 'cache' timestamp so when re-editing Filter would re-process the tokens again even if they seemingly hadn't changed (to account for changes in the token values themselves).
Attached in comment #1 is a patch using this approach. It is definitely a complex issue, and while I haven't done the testing to back it up, I suspect that this approach will improve performance as it's don't the heavy processing only when the Entity is being saved.
The added benefit of this implementation is that you could manually define the context of your tokens when entering the tokens, so you could have a Node token referring to another Node, or have a User token in a Node body field that actually works.
What hasn't been done is the language handling, but it shouldn't be a huge issue to have that added.
Comment | File | Size | Author |
---|---|---|---|
#10 | token_filter-context-2075663-10.patch | 6.59 KB | darvanen |
#1 | context-2075663-1.patch | 6.02 KB | Deciphered |
Comments
Comment #1
Deciphered CreditAttribution: Deciphered commentedComment #2
DamienMcKennaShould't
if (!$processing) {
beif (empty($processing)) {
to avoid "Undefined variable" errors?Comment #3
Deciphered CreditAttribution: Deciphered commentedI'm not sure if it's necessary given that the variable is populated with a value from drupal_static(), so it's never undefined. It couldn't hurt, but I don't know if it's necessary in this case.
Comment #4
DamienMcKennaI hadn't compared the rest of the function, only the patch, and I have an automatic reaction to syntax like that, so if it's referencing a static then that's fine :)
Comment #5
Dave ReidWhat happens when I use this on a brand new node. Since this runs on hook_entity_presave() isn't $entity_id going to be NULL?
Comment #6
Deciphered CreditAttribution: Deciphered commentedHmm, correct you are sir. I'll have to investigate what I did in WF to overcome that issue and re-roll.
Comment #7
heddnRe: #6
I'm seeing the same issue in wysiwyg_fields, but in there it isn't using the entity_id for anything.
Comment #8
darvanenNoted in #2144145: Use menu_get_item instead of debug_backtrace to determine context that we need to make sure this doesn't break Panels or Page manager, I think this is a better approach than the one offered in the linked issue.
I think it might be worth kicking off a 2.x version for this considering how long 1.x has been stable and how many sites are using it.
Comment #9
darvanenShould be able to get around #5 with a combination of hook_entity_insert and hook_entity_update followed by field_attach_update to avoid re-calling the insert/update hooks.
Comment #10
darvanenHere's a patch that gets around the id issue with hooke_entity_presave(), it definitely gets the entity ID.
But... it doesn't work yet, and I'm afraid I don't fully understand what's going on, it would be great if someone could explain it or pick it up.