Error using install profile with drush and custom box

Hmm. That method is on the base class, so it should be defined. What does your box export code look like?

Have you tried reexporting your box with the newest version?

Have this issue as well, but I get this error when clearing the cache with drush. The problem is that ctools_export_load_object('box') in boxes.module:352 returns an object with only one property, new, that is set to false. Didn't have time to investigate it more, but I hope this can help someone to look deeper :)

object(stdClass)#1763 (1) {
  ["new"]=>
  bool(false)
}

Which version of Ctools are you using? drush cc all doesn't return that with the latest version at this time.

It seems like my issue was due to a messy database. I made a quick work around to get it working temporarily and after I hade update the database and reverted my features I was able to remove my fix and clear the cache with out problems.

I'm not sure what's going on here - I've managed to get round it by adding the following around line 103.

if (method_exists($box,'cache_setting')) {
      $blocks[$box->delta]['cache'] = $box->cache_setting();
    } else {
      $blocks[$box->delta]['cache'] = DRUPAL_CACHE_CUSTOM;
    }

I'm not proud of what I've done, and don't think it's a fix or deserves a patch - but hopefully it'll help in the short term.

I'm seeing this same issue with beta5 and a related one with beta2 I was using previously. Although I'm not that familiar with Boxes it would appear to be a problem with the class constructor or instantiation.

Can some one post the box class they are using that is producing this error? so we can try and reproduce?

And also the steps to reproduce it.

@bleedev & @stevepurkiss

In looking at the code is it possible that the module providing your box (like mydistro_config) is enabled BEFORE the module providing the box type (mydistro)? that would certainly cause this to happen b/c it cannot determine the the box type to instantiate.

Does mydistro_config.info have a dependency on mydistro?

Only thing I can recommend is to add a bit of debugging in boxes_box::factory. My guess is that

$class = ctools_plugin_load_class('boxes', 'plugins', $plugin_key, 'handler')

is not loading the proper class. (for that bit of code $plugin_key will likely be mydistro). The trick is to figure out why that module or box type is not being loaded when your box is being imported. Is mydistro not enabled? Is mydistro module enabled, but the definition of the box type not loaded? you see where I'm going?

this is still happening in beta 7, i had to patch with

if (method_exists($box,'cache_setting')) {
      $blocks[$box->delta]['cache'] = $box->cache_setting();
    } else {
      $blocks[$box->delta]['cache'] = DRUPAL_CACHE_CUSTOM;
    }

Yes, that's the patch brenk28 posted here and it's basically the same approach as #7.

The issue is that autoloading of the box type should take place so you shouldn't run into this. That said, I'm not averse to rolling this in at this point just for practical purposes.

Well @brenk28's patch worked fine for me. Why #1341220: Undefined method error marked as a duplicate when it had a patch and this one didn't? @brenk28's patch was more concise too..

Anyways, all that really maters is how do we get this FIXED and into the next release

EDIT: unfortunately, this patch just moves the problem down to
Fatal error: Call to undefined method stdClass::render() in /DRUPAL7/sites/all/modules/contrib/boxes/boxes.module on line 182

Which can be fixed by a similar method:
$block = method_exists($box, 'render') ? $box->render() : '';

I applyed the patch from #1341220: Undefined method error and fixed the line 182 as in previous post and now, If I go to "Home » Administration » Structure", I get:

     Strict warning: Creating default object from empty value in boxes_box::load() (line 28 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/plugins/boxes_box.inc).
    Notice: Undefined property: stdClass::$delta in boxes_box_load() (line 382 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/boxes.module).
    Strict warning: Creating default object from empty value in boxes_box::load() (line 28 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/plugins/boxes_box.inc).
    Notice: Undefined property: stdClass::$delta in boxes_box_load() (line 382 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/boxes.module).
    Strict warning: Creating default object from empty value in boxes_box::load() (line 28 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/plugins/boxes_box.inc).
    Notice: Undefined property: stdClass::$delta in boxes_box_load() (line 382 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/boxes.module).
    Notice: Undefined property: stdClass::$delta in boxes_block_info() (line 99 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/boxes.module).
    Notice: Undefined property: stdClass::$description in boxes_block_info() (line 99 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/boxes.module).
    Notice: Undefined property: stdClass::$delta in boxes_block_info() (line 101 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/boxes.module).
    Notice: Undefined property: stdClass::$plugin_key in boxes_block_info() (line 101 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/boxes.module).
    Notice: Undefined index: in boxes_block_info() (line 101 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/boxes.module).
    Notice: Undefined property: stdClass::$delta in boxes_block_info() (line 103 of /var/www/minutee/htdocs/drupal/sites/all/modules/boxes/boxes.module).

I switched to Omega and started my own subtheme. It worked fine for a while but after I moved some blocks around, I get:

Fatal error: Call to undefined method view::load() in /var/www/minutee/htdocs/drupal/sites/all/modules/views_boxes/plugins/views_boxes_view.inc on line 388

I was running into this issue and was able to resolve it using the information provided in #12.

I had an existing feature that I needed to extend to include a custom box type, and place it into a context. I added the new module as a dependency to the feature. However, when I added my new box type module to my install profile, it was added underneath the feature, as outlined below:

; Incorrect - configuration before module
dependencies[] = my_feature
dependencies[] = my_box_module

Rebuilding the site while retaining the database would result in the error mentioned unless I cleared out the features cache by flushing all caches at least twice. Results were unpredictable.

To address the problem, and after a lot of trial and error, I moved the module providing the custom box type above the feature referencing an instance of it in my install profile such that:

; Correct - module before configuration
dependencies[] = my_box_module
dependencies[] = my_feature

After fixing my profile to reflect the "Correct" order, the issue was resolved.

It seems like this is an issue for features, as the box being sent to features is of a type that 'does not yet exist' in the features cache until it is forcefully reloaded. So the object being cached is a stdClass instead of an extension of boxes_box.

Adding my_box_module as a dependency to my_feature had no effect on the problem.

Note: #13 seems like it shows an example of an incorrect info configuration (if mydistro contains the box type and mydistro_config contains the configuration).

Running into this issue again, it seems that sometimes features that contain box instances can sometimes "beat" custom box types to initializing. We can address this by making sure that boxes::load and boxes_box_load have handling built in for this circumstance. Below, is one method to address this problem:

• boxes_box::load should return NULL when self::boxes[$delta] is a stdClass.
• boxes_box_load should not return null results in the $boxes array when called without the $delta parameter.

Attached is a patch that implements the solution above for 7.x-1.x.

It might also be nice to patch the Boxes code so that if you get one of these corrupted boxes in the DB it won't cause the Call to undefined method stdClass::cache_setting() error and just skip the bad box.

Nevermind, turns out patch did not apply (even though it didn't give any error). I might have been on the wrong version of boxes.

After applying this patch manually, it worked great!

The patch in #23 worked for me. I didn't have any problem with applying the patch.

Committed, thanks.

removed original reply because I thought it best to start new issue as the title of this one only partly fit and this one was closed as fixed and the patch was committed so I guess it might be a different issue.