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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Deciphered’s picture

Status: Active » Needs review
FileSize
6.02 KB
DamienMcKenna’s picture

Should't if (!$processing) { be if (empty($processing)) { to avoid "Undefined variable" errors?

Deciphered’s picture

I'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.

DamienMcKenna’s picture

I 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 :)

Dave Reid’s picture

+++ b/token_filter.module
@@ -68,3 +78,76 @@ function _token_filter_filter_tips($filter, $format, $long = FALSE) {
+  list($entity_id, $vid, $bundle_name) = entity_extract_ids($type, $entity);

What 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?

Deciphered’s picture

Status: Needs review » Needs work

Hmm, correct you are sir. I'll have to investigate what I did in WF to overcome that issue and re-roll.

heddn’s picture

Issue summary: View changes

Re: #6
I'm seeing the same issue in wysiwyg_fields, but in there it isn't using the entity_id for anything.

darvanen’s picture

Noted 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.

darvanen’s picture

Should 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.

darvanen’s picture

Here'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.