Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Full watchdog entry:
Notice: Undefined variable: tokens in panels_cache_object->cache() (line 212 of panels/includes/plugins.inc).
Related code:
// And for tokens:
$tokens = ctools_set_page_token();
foreach ($this->tokens as $token => $argument) {
if (isset($tokens[$token])) {
unset($tokens);
}
}
$this->tokens = $tokens;
Unset the whole variable looks somehow wrong. I guess it should be unset($tokens[$token]); instead.
Update
I'm quite sure now this the solution is correct.
Workflow as I understand it:
- Create
panels_cache_object
This initializes thepanels_cache_object::tokenvariable with all already existing tokens. - Create / render the pane to cache.
This adds additional tokens to the global token cache. - Call to
panels_cache_object::cache()
The code fetches all available tokens into$token, now iterate over the initially fetched tokens inpanels_cache_object::tokenand removes all tokens from$tokenthat were already present, because they don't belong to this single pane. Last step is to assign the cleaned$tokentopanels_cache_object::token
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1173978-panels-undefined-variable-tokens-5.patch | 396 bytes | dixon_ |
| #4 | 1173978-panels-undefined-variable-tokens-4.patch | 396 bytes | fabsor |
| panels-undefined-variable-tokens.patch | 396 bytes | das-peter |
Comments
Comment #1
das-peter commentedI think now I understand a little bit more what the intended goal is: "Add only the tokens to the cache object which are really related to it."
Unfortunately it seems like the "diff" doesn't work since the initial fetch of existing tokens in the constructor (panels_cache_object::panels_cache_object) contains already the cache object specific tokens.
Thus the "diff" removes not only the previous set tokens but also exactly those tokens needed by the cache object.
Only idea atm. is that somewhere a call order was changed what causes the tokens to be set before the cache object is initialized.
Comment #2
das-peter commentedNeeds definitely work ;)
Comment #3
fabsor commentedSubsribing
Comment #4
fabsor commentedI can't contribute to a better solution, as I honestly don't know enough about how the tokens work, but this patch solves the problem for me and I need it for an installation profile make file, so I'm going to do a shameless reroll of this without really contributing anything new =)
Comment #5
dixon_Patch in #4 solve the problem for me too. Here's a re-roll.
It seems unreasonable to me to unset the whole
$tokensvariable, when what we are looking for actually is$tokens[$token]. So it seems like a reasonable fix.Comment #6
Letharion commentedLooks like an issue that use some feedback from merlinofchaos.
Comment #7
das-peter commentedI'm quite sure now this the solution is correct.
Workflow as I understand it:
panels_cache_objectThis initializes the
panels_cache_object::tokenvariable with all already existing tokens.This adds additional tokens to the global token cache.
panels_cache_object::cache()The code fetches all available tokens into
$token, now iterate over the initially fetched tokens inpanels_cache_object::tokenand removes all tokens from$tokenthat were already present, because they don't belong to this single pane. Last step is to assign the cleaned$tokentopanels_cache_object::tokenComment #8
merlinofchaos commentedI agree; committed #5
Comment #9
bryancasler commentedMarked my post as a duplicate of this one #1466692: Notice thrown on page view
Comment #10
bryancasler commentedI can confirm that #5 resolves the problem I had
Comment #11.0
(not verified) commentedUpdated issue summary.