Fatal error: Call to undefined method stdClass::is_type() in includes/context.inc on line 147

Hm. That error indicate sthat somehow a context object is being passed as not a context object. I'm not sure how that could happen. I've never seen that happen in my usage.

Perhaps content_profile is somehow returning something incorrect in one of its context/relationship plugins?

+1.. getting this with ctools 1.8. I doubt that it's ctool's fault because the context class clearly has this function defined. I'm getting this in conjunction with og panels, which I have to assume is just too outdated.

I also encountered this bug. I could reproduce the bug in a fresh install too.

Steps to reproduce

1. Create three content types (group, album, song).

2. Enable modules Panels, Page manager and Chaos Tools.

3. Create a custom page (admin/structure/pages/add).
Form values:
Administrative title: songs per album per group
Path: node/%group/%album/%song
Optional features: Selection rules: active

4. On argument settings, set the following:
%group: Node: ID: group
%album: Node: ID: album
%song: Node: ID: song

5. On selection rules, add three "Node: type" criteria's and assign each node type. Longer explanation:
5.1 Add "Node: type".
5.2 In "Add criteria" popup, fill in the following values:
Node: group
Node type: Group
And click "Save".
5.3 Repeat steps 5.1 and 5.2 for "album" and "song" (instead of "group").

Now the Selection Rules page contains a table with three rows:
Title;Description;
Node: type;group is type "Group";
Node: type;album is type "Album";
Node: type;song is type "Song";

When you hit the button "Continue" now, the following error appears:
Fatal error: Call to undefined method stdClass::is_type() in /Websites/drupal/drupalsites/drupal7/sites/all/modules/contrib-standard/ctools/includes/context.inc on line 147

The path of the page is now:
admin/structure/pages/add/page-songs_per_album_per_group/criteria

Version information

PHP 5.3.2
Drupal 7.15
Install profile: Minimal
CTools 7.x-1.2
Panels 7.x-3.3

Other information

Tested as user 1.

Debug information

I went to debugging and found out that the error happens somewhere in the function ctools_access_add_restrictions() or, in other words, this is the last function where the content of the parameters look still right.

I think something is wrong with line 1579 in includes/context.inc:

$contexts = ctools_context_select($contexts, $required_context, $context);

In this code line, $contexts gets overwritten with the result of the ctools_context_select() call. I'm not sure what ctools_context_select() is supposed to return, because that is not documented.

ctools_context_select() gets called three times:

1. The first time, $contexts is an array of three ctools_context instances. ctools_context_select() returns a single ctools_context instance.
2. The second time, $contexts is a single ctools_context instance. ctools_context_select() returns FALSE.
3. The third time, $contexts is an instance of stdClass. A fatal error happens.

I've attached some debug information, created with krumo using this code in the ctools_access_add_restrictions() function:

print 'ctools_access_add_restrictions(): before calling ctools_context_select():'; krumo(get_defined_vars());
$contexts = ctools_context_select($contexts, $required_context, $context);
print 'ctools_access_add_restrictions(): after calling ctools_context_select():'; krumo(get_defined_vars());

I have backtraced this to the following code from context.inc:

  function select($contexts, $context) {
    if (!is_array($contexts)) {
      $contexts = array($contexts);
    }

    // If we had requested a $context but that $context doesn't exist
    // in our context list, there is a good chance that what happened
    // is our context IDs changed. See if there's another context
    // that satisfies our requirements.
    if (!$this->skip_name_check && !empty($context) && !isset($contexts[$context])) {
      $choices = $this->filter($contexts);

      // If we got a hit, take the first one that matches.
      if ($choices) {
        $keys = array_keys($choices);
        $context = reset($keys);
      }
    }

    if (empty($context) || empty($contexts[$context])) {
      return FALSE;
    }
    return $contexts[$context];
  }

This method is invoked twice for the bundle argument. This is because the bundle argument is a restricting argument, as it adds information about the argument to the argument context.

The first time this code is executed, a single context is returned. This context ends up being the value of $contexts in ctools_access_add_restrictions(). In the second invocation, the if (!is_array($contexts)) { part is triggered. Now $contexts is a numeric array, while in the first invocation it was an array keyed by the textual context id. The part $keys = array_keys($choices); $context = reset($keys); causes $context to become 0, triggering if (empty($context) || empty($contexts[$context])) {. This causes $contexts to become false in ctools_access_add_restrictions().

Then, in ctools_entity_bundle_ctools_access_restrictions(), $context->restrictions['type'] is set without the code checking if $context is an object. This causes $context to become an stdClass.

My solution is to change the above code snippet to:

  function select($contexts, $context) {
    if (!is_array($contexts)) {
      if (is_object($contexts) && $contexts instanceof ctools_context) {
        $contexts = array($contexts->id => $contexts);
      }
      else {
        $contexts = array($contexts);
      }
    }

    // If we had requested a $context but that $context doesn't exist
    // in our context list, there is a good chance that what happened
    // is our context IDs changed. See if there's another context
    // that satisfies our requirements.
    if (!$this->skip_name_check && !empty($context) && !isset($contexts[$context])) {
      $choices = $this->filter($contexts);

      // If we got a hit, take the first one that matches.
      if ($choices) {
        $keys = array_keys($choices);
        $context = reset($keys);
      }
    }

    if (empty($context) || empty($contexts[$context])) {
      return FALSE;
    }
    return $contexts[$context];
  }

Also, ctools_access_add_restrictions() should check if $contexts = ctools_context_select($contexts, $required_context, $context); returns FALSE and not continue when it does.

Please see the attached patch.

Marking the right branch.

I'm not sure about #2. What if there's an empty array because there were no required contexts? There's at least one access rule like that.

You mean hunk #2? Maybe it is better to check for === FALSE, you're right. Could you fix the parse error in the current 7.x-1.x-dev branch? All patches are now marked as Postponed because the branch they're based off is not testable. See #1300912: theme('advanced_help') has wrong parameters.

Updated patch

This (#11) fixed this problem for me. Haven't extensively tested but so far no weird side-effects, adding a few panels and doing routine config tasks... Thanks, @Jorrit!

I resolved the problem by instantiating a new object of type ctools_context , passing the $type and $data as parameters:

foreach ((array) $contexts as $cid => $context_tmp) {
$context = new ctools_context($context_tmp->data->type,$context_tmp->data); //<- !! HERE !!
if ($context->is_type($this->keywords)) {
// Compare to see if our contexts were met.
if (!empty($this->restrictions) && !empty($context->restrictions)) {
foreach ($this->restrictions as $key => $values) {
...........
}
}
$result[$cid] = $context;
}
}

In the foreach loop I create a new instance of the ctools_context class with data from the $context_tmp StdClass which is taken from the $contexts array. In this way, the PHP interpreter knows about the "is_type()" function as it is defined in the ctools_context class.
It seems to me that PHP knows that $context is an StdClass , but not an object/class instance of type ctools_context.
I personally do not know the root cause. It may be a problem in the way the $contexts array is setup or the version of PHP that I am using PHP 5.3.
The same concept would be applied to this problem in any other part of the context.inc file.
I hope that this helps.

I resolved the problem by instantiating a new object of type ctools_context , passing the $type and $data as parameters:

foreach ((array) $contexts as $cid => $context_tmp) {
$context = new ctools_context($context_tmp->data->type,$context_tmp->data); //<- !! HERE !!
if ($context->is_type($this->keywords)) {
// Compare to see if our contexts were met.
if (!empty($this->restrictions) && !empty($context->restrictions)) {
foreach ($this->restrictions as $key => $values) {
...........
}
}
$result[$cid] = $context;
}
}

In the foreach loop I create a new instance of the ctools_context class with data from the $context_tmp StdClass which is taken from the $contexts array. In this way, the PHP interpreter knows about the "is_type()" function as it is defined in the ctools_context class.
It seems to me that PHP knows that $context is an StdClass , but not an object/class instance of type ctools_context.
I personally do not know the root cause. It may be a problem in the way the $contexts array is setup or the version of PHP that I am using PHP 5.3.
The same concept would be applied to this problem in any other part of the context.inc file.
I hope that this helps.

This bug happened to me on a fresh install with the taxonomy module disabled. Enabling the taxonomy module fixed the problem. Hope that helps :)

Cheers,
Jeff

The patch in #11 resolved the issue for me.

I developed a custom relationship plugin that loaded an og memberhip based on the required context of user. When I added the relationship, I could no longer visit the Selection Rules form due to this issue. Somehow the logged in user context was being half-created on the Selection Rules form.

Then I think we can consider this patch to be tested by the community.

11 looks and tests good, especially with check from #10 included. Committed.

Thanks for committing the patch and git attribution.

Just for future reference, in my case this was caused by missing Uid 0(anonymous user), something had removed it from the database. Adding it back fixed the problem: http://drupal.org/node/1029506