array_merge() errors in token_get_values

Something is returning broken data then. This is not something I can reproduce with a clean version of core, so it's some contrib module at fault.

Dave, the problem happens when token_get_values is called with $type="user". In my case, $tokens[$type][$id] is sometimes set to null at line 320, when the hook is invoked to get global default tokens. That certainly suggests a misbehaving module, but I can't set aside enough time right now to track down the cause.

But I was puzzled why $tmp_tokens is set at line 310, but then not used later. Assuming this was done for a reason, I took a guess and changed line 323 to pass $tmp_tokens to _token_array_merge() instead of $tokens[$type][$id]. This'd make sense if $tmp_tokens was intended to make sure an array was always passed. Sure enough, that fixes the error on my installation.

I've attached a patch in case this is indeed the fix. Let me know if you have any questions ... and thanks.

Oh, I see what's going on.

I think this is a more proper fix.

Hrm, so I tried to write a regression test for this and I cannot get it to fail without resorting to broken code (which I shouldn't have to do). So while this is a good cleanup, I'm not sure how it will actually fix the issue at hand.

I am having the exact same issue on my environment, running the latest version of pathauto and token.

Patch #8 did not resolve any issues, and the error message still happened after applying it.

Patch #4 seems to have resolved the issue (no more errors), and pathauto does not seem to be generating any more [user-raw] URL's

Perhaps I have the same module that is causing this loss of $user object as OP. Full list of enabled modules:

* admin_menu
* cck
* ckeditor
* colorbox
* ctools
* exportables
* features
* google_analytics
* imce
* input_formats
* jquery_ui
* jquery_update
* ldap_integration
* linkit
* menu_breadcrumb
* noreqnewpass
* page_title
* pathauto
* pathologic
* pollfield
* realname
* stringoverrides
* strongarm
* token
* views
* views_menu_sort
* wysiwyg_filter

Hi,

I have a similar issue. As wiifm: patch #7 didn't work, while patch #4 seems to have solved the problem.

Attached is patch #4 "ported" to last stable release of Token module.

Marked #1000894: array_merge() errors in token_get_values as a duplicate of this issue. Renaming for better visibility.

Looks good to me over here. Patch #15 works beautifully. (running Token 6.x-1.16)

I still can't get this to fail or why this is necessary. This needs a test to prove why it needs to be fixed.

Maybe it's related to usage of module "ldap_integration" (used also by wiifm in #12). I had problems with it and pathauto/token interaction.

FYI: I also use ldap_integration (and token 6.x.1.16) and only see this issue during the password reset upon landing on the one-time login link. I land on: /user/19/edit and see:

warning: array_merge() [function.array-merge]: Argument #2 is not an array in [sanitized]/all/modules/token/token.module on line 359.
warning: array_keys() [function.array-keys]: The first argument should be an array in [sanitized]/all/modules/token/token.module on line 362.
warning: array_values() [function.array-values]: The argument should be an array in [sanitized]/all/modules/token/token.module on line 363.
warning: Invalid argument supplied for foreach() in [sanitized]/all/modules/token/token.module on line 430.
warning: Invalid argument supplied for foreach() in [sanitized]/all/modules/pathauto/pathauto.inc on line 566.

Subscribing

I have same error here :

    warning: array_merge() [function.array-merge]: Argument #2 is not an array in \sites\all\modules\token\token.module on line 359.
    warning: array_keys() [function.array-keys]: The first argument should be an array in \sites\all\modules\token\token.module on line 362.
    warning: array_values() [function.array-values]: The argument should be an array in \sites\all\modules\token\token.module on line 363.
    warning: Invalid argument supplied for foreach() in \sites\all\modules\token\token.module on line 430.
    warning: Invalid argument supplied for foreach() in \sites\all\modules\pathauto\pathauto.inc on line 566.

It happens when $type = 'user'.
It seems also that it does not happen with all users.

Using version 6.x-1.16

Works for me. Without this patch, I can't synchronise profile data with my LDAP directory using ldap_data. I do also have RealName installed, FWIW.

The patch at #15 fixed the issue.

I'm using Token v6.16, and the error was on the order page, using Ubercart v2.6 with uc_node_checkout 6.x-2.x-dev (was also present with 6.x-2.0-beta8).

I still think this means we have a problem in a module providing tokens. This isn't the right fix.

I had the same problem. In figuring out what was going on, I found that code changes in the 1.18 release should fix this. So, I am marking this as fixed. Here is why:

The underlying problem is that some hook_token_values implementations will cause token_get_values to be called recursively with the "flush" option set. In the versions < 1.16, the cache clearing was done before the "running" recursive check was made. Then the function was exited because of the recursive check. In versions >=1.18, the check for recursion is done first... so the flush option is ignored.

E.g.: in my case with version 1.16:

1. token_get_values($type, $object... ) is called.
2. the $tokens[$type][$object_id] cache is filled via calling the token_values hook with the type set.
3. In order to fill the the $tokens['global']['defaults' cache, the token_values hook is called with the type 'global'...
4. In my case, the token modules token_token_values function would ask for the URL alias.
5. pathauto would then call tokens_get_values again... WITH THE FLUSH FLAG SET and the $RUNNING static var set
6. the cache would be flushed and the just filled value for $tokens[$type][$id] cleared
7. the recursion check would see that $Running was set and exit the function
8. array_merge would fail, because the cache had been cleared and the value was null

This will not happen in 1.18 because Step 6 and 7 above are swapped in this new version. So the recursive call check will exit the function before the cache flush option is processed (i.e. 1.16 - Step 6 is effectively dropped from the above process). In addition, the new way of determining the related id should keep other possible "overwrite" conditions from happening.