Closed (fixed)
Project:
Token
Version:
6.x-1.18
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
18 Aug 2010 at 00:53 UTC
Updated:
15 Feb 2012 at 21:30 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
dave reidSomething 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.
Comment #2
SeanA commentedI'm thinking the problem lies with Ubercart, which recommends Token 1.12 on its project page.
Comment #3
SeanA commentedI can't reproduce this either. I enabled various Ubercart modules one by one on a clean install and didn't encounter any warnings.
Comment #4
Anonymous (not verified) commentedDave, 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.
Comment #5
Anonymous (not verified) commentedConfirmed that this patch resolves the issue for me as well.
Comment #6
dave reidOh, I see what's going on.
Comment #7
dave reidI think this is a more proper fix.
Comment #8
avpadernoComment #9
dave reidHrm, 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.
Comment #10
dave reidComment #11
SeanA commentedI had the person who runs the original website try out the fix in #7, but the warnings reappeared. He also says: "I do know that I've installed the latest pathauto and token modules on other drupal installs without warnings, so maybe we've got another module that isn't playing nicely with the others."
Comment #12
wiifmI 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
Comment #13
dave reidComment #14
dave reidComment #15
Kafu commentedHi,
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.
Comment #16
dave reidMarked #1000894: array_merge() errors in token_get_values as a duplicate of this issue. Renaming for better visibility.
Comment #17
dave reidComment #18
millenniumtreeLooks good to me over here. Patch #15 works beautifully. (running Token 6.x-1.16)
Comment #19
dave reidI still can't get this to fail or why this is necessary. This needs a test to prove why it needs to be fixed.
Comment #20
Kafu commentedMaybe it's related to usage of module "ldap_integration" (used also by wiifm in #12). I had problems with it and pathauto/token interaction.
Comment #21
mark_at_kaazing commentedFYI: 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:
Comment #22
reaneyk commentedSubscribing
Comment #23
ludo.rI have same error here :
It happens when $type = 'user'.
It seems also that it does not happen with all users.
Using version 6.x-1.16
Comment #24
terminus commentedWorks 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.
Comment #25
erik2e commentedThe 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).
Comment #26
Kafu commentedComment #27
dave reidI still think this means we have a problem in a module providing tokens. This isn't the right fix.
Comment #28
Anonymous (not verified) commentedI have a similar problem related to LDAP. Would this type of error cause a white screen of death?
S
Comment #29
cgmonroe commentedI 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:
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.