array_merge() errors in token_get_values

Go to admin/reports/status and it will let you know which modules are causing this problem.

I also see this issue, but it only pops up about one in every 100 times I load a page, and goes back away.

admin/reports/status shows all green.

From what I have noticed, this seems to be happening with the token module. What I narrowed it down to occurring was:

1) The other 'non-global' tokens get created.
2) Token module checks if the global tokens exist (they don't at this time).
3) Token module creates global set of tokens.

However, it seems like the non-global tokens that were created get wiped out and so its trying to merge the global tokens against something that no longer exists. The patch I wrote basically moves the code so that the global tokens get created first and the other type after. It **seems** to fix the issue though it requires further review and testing.

I still think this is happening by some kind of edge case, otherwise this would have been reported way sooner. This is treating the symptom, but not the cause.

You're right - I did some more testing and found that while the errors no longer show up on the page, some other strange issues are occurring. As a note, they involved

1) Pathauto
2) LDAP Integration (specifically the LDAP Data module)

which I'm trying to figure out on what the issue could be.

Here is the explanation I have been able to build:

If you set LDAP Data Synchronization on "Every time user object loaded in Drupal"
(the problem does not seem to happen otherwise)

you enter this process (read "calls" between each line):

module_invoke_all('token_values', 'global')

token: token_token_values $type=global

drupal_get_title
menu_get_active_title
menu_get_active_trail
menu_set_active_trail
menu_tree_page_data
menu_tree_check_access
_menu_tree_check_access

_menu_link_translate
   execute menu item load_functions for item
   [link_title] => My account
   [load_functions] => a:1:{i:1;s:22:"user_uid_optional_load";})
   [page_callback] => user_view
   [access_callback] => user_view_access

user: user_uid_optional_load
user: user_load
user: user_module_invoke load
ldapintegration: ldapdata_user load    

since we are in "Every time user object loaded in Drupal" (would stop otherwise)

user: user_save
user: user_module_invoke update
pathauto: pathauto_user $op = update
pathauto: pathauto_get_placeholders
token: token_get_values  with flush = true => empties $tokens

the problem is that token_get_values is called recursively (see first and last line of the process)
you run it once then it gets called
once for the user you want to see the profile of
and once for current user
note the last line of the process: $tokens array gets emptied before rebuilding it for the current user so $token data for the profile of the other user is erased => hence raising the error ...

i guess
$tokens['user']['current user id'] and $tokens['user']['other user profile id']
should be kept somehow through "Special-case global tokens" piece of code
and remerged after...

I had these error messages after creating a new unverified ldap user. Changing ldap/data/syncronizing options to "When user logs in" fixed the issue. For us this was fine as it suited our requirements. It was previously set to "Every time user object loaded in Drupal"

As comment 8 indicates, this is caused by someone resetting the tokens static cache during module_invoke_all('global', 'default').

There was a $temp_tokens variable that was always being set with the current tokens, so replaced $tokens[$type][$id] with it for the case that tokens got wiped and it is also working. The advantage of this patch vs the other is that if someone decides to do the same, ie wipe the internal cache, but during $token[$type][$id], it won't fall prone to a similar error.

However, I'd advised looking into *why* someone would be wiping the cache while generating tokens also.

Changing title to reflect that the issue can happen during other situations (I am getting it during custom module's database updates).

If tokens change during the page request it makes sense to clear them.

For example, autonodetitle creates a temporary title of "ant" so when Pathauto gets tokens it needs to flush them in case the "ant" token title is set.

I'm not sure why this failed testing :(

I didn't review the code.

hefox clarified the cause of this being a call to token_get_values from *within* a call to token_get_values. That is somewhat irregular. I can imagine it happening if you build the tokens on a node where a field is using a filter that includes token processing.

#10: 1000894_token_array_merge_errors.patch queued for re-testing.

I tested the patch and it seems to solve the problem for me. I do need to rebuild LDAP data on every user load so this will really help me out.

I can't tell why the testing failed either... resubmitted to see if it was a fluke.

subscribe

This is a duplicate of #886200: array_merge() errors in token_get_values.