PHP 5.4 generates frequent errors in some code of mine that calls ctools_access_get_loggedin_context(). The problem seems to be in ctools_get_context(); when called from ctools_access_get_loggedin_context(), it can get into a state where no plugin was found to handle 'entity::user', and it returns $plugin with a value of NULL. Since ctools_access_get_loggedin_context() does not check the returned value, it treats the null object as an stdObject, which raises a warning in PHP 5.4 that floats up into the UI where users can see it.

I don't understand the internals of the plugin system well enough to figure out why no plugin was found in the first place. The only thing I can think of is that I am using the ctools form wizard with anonymous user. I am also using Panels variants that need to test whether the user is logged in or not; it is difficult to tell who is checking the logged in context, since this seems to float down via the menu system.

Since I can't solve the underlying problem, at least ctools_access_get_loggedin_context() needs to handle the NULL context case gracefully. I am supplying a patch that does this, made against 7.x-1.x.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Torenware’s picture

Status: Active » Needs review
FileSize
531 bytes
Torenware’s picture

Kojo Unsui’s picture

Half similar (with php 5.3.18) : on Commons distribution, systematic warnings & notices on panelized pages, for anonymous users only :

Strict warning : Creating default object from empty value in ctools_context_create_user() (line 46 in profiles\commons\modules\contrib\ctools\plugins\contexts\user.inc).
Notice : Undefined property: stdClass::$uid in ctools_context_create_user() (line 61 in profiles\commons\modules\contrib\ctools\plugins\contexts\user.inc).

ddebug_backtrace() returns

#0 ctools_context_create_user(, Array ([type] => current), 1, Array ([title] => Utilisateur,[description] => Un unique objet utilisateur.,[context] => ctools_context_create_user,[edit form] => ctools_context_user_settings_form,[defaults] => Array ([type] => select,[uid] => ),[keyword] => user,[context name] => user,[convert list] => ctools_context_user_convert_list,[convert] => ctools_context_user_convert,[convert default] => name,[module] => ctools,[name] => user,[path] => profiles/commons/modules/contrib/ctools/plugins/contexts,[file] => user.inc,[plugin module] => ctools,[plugin type] => contexts)) called at [..\profiles\commons\modules\contrib\ctools\includes\context.inc:600]

#1 ctools_context_create(entity:user, Array ([type] => current), 1) called at [..\profiles\commons\modules\contrib\ctools\includes\context.inc:1403]

, so as far as I understand it seems to consider that the user is logged ?!

So I temporarily solved it applying #1 patch and adding this ugly test in ctools_context_create_user() (user.inc line 34)

<?php 
if ($data['type'] == 'current') {
  global $user; 
  $data = user_load($user->uid);
  //test if user is anonymous
  if($user->uid != 0){
    $data->logged_in_user = TRUE;
  }
} 
?>

And strict warnings and notices are gone.

Kojo Unsui’s picture

Ok, there is now a patch for current user context for an anonymous user.

DamienMcKenna’s picture

Version: 7.x-1.4 » 7.x-1.x-dev

DamienMcKenna’s picture

Assigned: Torenware » Unassigned

You should only assign an issue to yourself if you're going to work on it, otherwise please leave it unassigned. Thanks :)

mlamothe’s picture

Priority: Normal » Major
FileSize
690 bytes

Here is the proper fix for this issue.

Chris Matthews’s picture

The patch in #8 applied cleanly to the latest ctools 7.x-1.x-dev, but still needs to be reviewed and tested.

rayjames’s picture

Hello, on Drupal 7.77 | PHP 5.6 | ctools 7.x-1.17 I'm getting the same error as the original poster of this issue.
"Warning: Creating default object from empty value in ctools_access_get_loggedin_context() (line 1864 of /ctools/includes/context.inc)."

I have updated to the latest version of ctools 7.x-1.17 with no luck. Do I need need to use the 7.x-1.x-dev branch to fix this? Is it going to be patched into the main branch? It's for a production site so not sure if the dev branch is ok for production. Thanks for your help and time on this.

DamienMcKenna’s picture

@rayjames: Do you have an instance of the site besides the production one which you can test the patch on? You would need to apply the patch in #8 to fix the problem, the fix hasn't been made to the current release.

rayjames’s picture

Hi @damienmckenna , that's what I ended up doing to fix it for now. Do I just keep patching each new release of the module or is this something that will get merged in? Thanks for your time and help on this.

joelpittet’s picture

Status: Needs review » Fixed
FileSize
616 bytes

A bit of a gamble but I've committed this to the dev branch for the next release, I refactored it because it didn't need the nested conditional. I'm pretty confident this does what the patch has in it in #8.

  • joelpittet committed 5d711f5 on 7.x-1.x
    Issue #2212641 by Torenware, mlamothe, joelpittet, DamienMcKenna, Kojo...
joelpittet’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.