Error - Notice: Trying to get property of non-object in menu_block_view_alter()

Same error, no Quick Tabs, lets look what else could do this? What modules you use? My site is Ctools/Panels based with plenty of modules.

We're also using a Ctools/Panels based site, with no Quick Tabs, and getting this same issue.

same problem here, but its not for quicktabs module, but its the same type of error. I'm using views slideshow block and trying to put it in a panel page and get hit with that same error.

These errors are due to PHP 5.3+ as its throwing out alot of NOTICE errors. these errors arent fatal, but just anonying and basically tell you to update your code im guessing. You can disable these Notice errors in your php.ini file or tackle the problem.

One solution i did was edit the module/menu/menu.module file and on line 476 and below I removed references to anything $block.

Obviously you wouldn't want to do that since its hacking core. Well at least I found the culprit that is causing the problem. The error is saying the variable is not an object, but in fact it is an object. So I dunno... -_-

If anyone solves this, I would love to learn what this was all about... =)

I was able to track this down using a quick-n-dirty backtrace technique to the offending code in ctools_block_content_type_render.

In my case, there were a set of panel pane blocks that were enabled in our site's header mini-panel. The blocks were provided by core modules (a user menu, and the search_form) but were somehow *not* enabled for our custom theme and were therefore not returned by the _ctools_block_load_blocks() call to populate the block info.

Thus, when the hook_block_view_alter() is called and a valid $block object is not passed (aka, "block info", in the ctools code), various modules will balk with the error here, expecting the $block argument to actually have the require members.

The following patch made the errors go away for me, and mimics code in core block module's block_load function.

Oops, forgot to remove debugging code.

Getting the same error here with our panels and ctools.

Looks legit and does the job.

Should we alter an empty block or not call the alter? I'm not sure what the value of calling the alter on an empty block is?

Subscribing

subscribe

@merinofchaos:

Maybe you're confusing empty "$info", with empty "$block".

There are certain conditions when _ctools_block_load_blocks() won't return any info even when a block exists in the database or in the code but is not enabled for the current theme. This is completely independent of whether or not the block itself has any content/data or not. The content is produced, without fail, via the module_invoke(), however its then uanable to run the alter hook because the $info object containing the module name and delta wasn't created properly.

The case, as it happens here, is that 1) the menu_block_view() executes, and creates the $block as expected, but then 2) since $info is empty because it didnt exist in the database call, we need to populate it with its defaults, so the alter hooks run appropriately.

Perhaps the better solution is to modify the database call in _ctools_block_load_blocks() to remove the condition for the current theme?

Thanks for the patch - works for me too.

For me the database call in _ctools_block_load_blocks() should stay as is since I think it's the right approach to filter for the current theme.
But we could move the code to set the default into _ctools_get_block_info() - change the code to this:

function _ctools_get_block_info($module, $delta) {
  $blocks = _ctools_block_load_blocks();

  $key = $module . '_' . $delta;
  if (isset($blocks[$key])) {
    $info = $blocks[$key];
  }
  else {
    $info = new stdClass();
    $info->module = $module;
    $info->delta = $delta;
  }
  return $info;
}

What I don't know is if there's somewhere code that checks for an empty return of _ctools_get_block_info() as part of a condition.
Followup: Looks like _ctools_get_block_info() in ctools is only used on one place - adding a default info shouldn't break a thing.

I'm encountering this similar problem with one of our modules.

In my case, what I'm understanding is the following:
1°) Ctools tries to render a block of mine via ctools_block_content_type_render()
2°) This function requests info from this block via _ctools_get_block_info()
3°) Blocks are listed, and a drupal_alter('block_list', $block_info) is executed. From the 40 blocks found, this alter removes 37 blocks. Most blocks are removed by the overlay module, because my current page is displayed as an overlay. Nothing too suspect to me so far.
4°) Then, (we're back in ctools_block_content_type_render()) that's when the drupal_alter(array('block_view', "block_view_{$module}_{$delta}"), $block, $info) is triggered, but with an uninitialized $info. That explains the notices my module triggers, but we've also menu.module that triggers it.

Actually I'm not 100% sure of what should be done to address this issue. But as merlinofchaos asked, I wonder if calling the block_view_alter when $info is empty shouldn't be avoided, as a module previously requested to remove it from the list.

Example:

if (!empty($info)) {
  drupal_alter(array('block_view', "block_view_{$module}_{$delta}"), $block, $info);
}

Your opinions?

subscribing

@pacproduct: are you saying that overlay module is removing 37 of 40 blocks during the call to drupal_alter('block_list', $block_info); inside _ctools_block_load_blocks?

Update: If so, is this an appropriate way to *hide* blocks from being rendered?

Update 2: To answer my own question, duh, yes. hook_block_list_alter is exactly the way to alter rendering of blocks.

Let's examine @pacproduct's step 4 in #14 above more closely.

In your example, even if the info is removed for 37 blocks during the hook_block_list_alter from the overlay module, this does not actually prevent ctools_block_content_type_render() from calling the module_invoke($module, 'block_view', $delta);

I think its just really odd that ctools can call hook_block_view without needing the block info at all, but to then alter the same block, after having been built, you need to know the $info->module name and the $info->delta from the _ctools_get_block_info call, when we already have both pieces of information before that call.

This means those 40 blocks are still having their module's hook_block_view function called, regardless of whether _ctools_get_block_info returns a value or not, right?

After the call to _ctools_get_block_info(), what if we just put a

if (empty($info)) {
  return;
}

Thoughts?

After all the analysis #18 seems reasonable. Only thing, I was a little worried about, was if it could be a problem if we return nothing.
But if I'm right, these ....content_type_render() functions / callbacks are used in ctools_content_render() which checks for an empty return and skips further processing in such a case.
Conclusion on my side - #18 seems the right way to go and may has a positive side-effect regarding performance.

I would have thought solution #18 should work, and that it wouldn't be a problem to return nothing as ctools_block_content_type_render() already does so at line 147 if the whole $block is empty:

  if (empty($block)) {
    return;
  }

So, I altered following function to make it like this:

function ctools_block_content_type_render($subtype, $conf) {
  list($module, $delta) = _ctools_block_get_module_delta($subtype, $conf);

  $info = _ctools_get_block_info($module, $delta);

  if (empty($info)) {
    return;
  }

  ...

But after test, in my case the overlay turns out to be almost empty with this piece of code (all but the breadcrumb is gone) :(

@pacproduct: Did you verify that the blocks are properly registered for the theme you use? I had a similar issue with facetapi blocks while verifying the stuff for my response in #19. It turned out that the facetapi blocks weren't properly registered to the necessary theme until I cleared the cache and visited the block management page again (Check the table block).
And since this was clearly a facetapi / block management related issue I decided to vote for #18.
Would be great if you could check if your issue is caused by something similar.

verify that the blocks are properly registered for the theme you use

There are cases when the blocks are *not* added for a theme.

This is exactly what i said in #12, as my initial rebuttal. How does one go about ensuring the blocks are registered when you install from a profile and all the block configs are in the code? This is particularly true when everyone is trying to stay away from core block module with a ten-foot pole, (using panels and context, to solve block module layout issues) why should we actually depend on it to "register" a block for a given theme?

All the blocks of my particular module are attached to the admin theme:

+-----+----------+------------------------+-------+--------+--------+--------+--------+------------+-------+-------+-------+
| bid | module   | delta                  | theme | status | weight | region | custom | visibility | pages | title | cache |
+-----+----------+------------------------+-------+--------+--------+--------+--------+------------+-------+-------+-------+
|  65 | co****ea | co****ea_member        | seven |      0 |      0 | -1     |      0 |          1 |       |       |     8 | 
|  66 | co****ea | co****ea_login         | seven |      0 |      0 | -1     |      0 |          1 |       |       |     8 | 
|  67 | co****ea | co****ea_new_user      | seven |      0 |      0 | -1     |      0 |          1 |       |       |     8 | 
|  68 | co****ea | co****ea_edit_account  | seven |      0 |      0 | -1     |      0 |          1 |       |       |     8 | 
|  69 | co****ea | co****ea_reset_pass    | seven |      0 |      0 | -1     |      0 |          1 |       |       |     8 | 
|  70 | co****ea | co****ea_perso_info    | seven |      0 |      0 | -1     |      0 |          1 |       |       |     8 | 
| 124 | co****ea | co****ea_edit_info     | seven |      0 |      0 | -1     |      0 |          1 |       |       |     8 | 
...

I did not have time to debug further, but I probably don't have any info on these blocks because they are considered as useless by "overlay". So, I don't have info on them, and so they're not rendered...
If I'm right, I guess we cannot afford to just return nothing when we don't have info on a block.

Let's go back to NR so it doesn't fall off my radar by mistake.

I understand now that we can legitimately have a blank $info. Panels doesn't care about the configuration within the theme, so I think faking up an $info is probably a legitimate choice. I'm going to need to come up with a repro situation to make sure things work the way intended in that case.

Sub, getting this error as well using panels and view field modules.

I was wondering... wouldn't the best solution be, in that particular case, not to trigger the hook_block_list_alter?

We could imagine a call to _ctools_get_block_info(); that would always retrieve info about a block, whatever the current context this block is in at this moment. By adding a parameter to this function for example. Because we know that in "ctools_block_content_type_render()" we always need it.

More generally, shouldn't a function called "_ctools_get_block_info()" always return info about it?

subscribe

subscribing - same issue with custom block loading into panels

Subscribe same issue.

The base requirement for the block_view alter is that it expects the $block parameter to have two required members: $block->module, and $block->delta. Technically speaking, both of these things are already existing before the call to _ctools_get_block_info(). Assuming we were going to allow hook_block_view and its alter hook to run, then, isn't calling the database for the block info completely unnecessary in the first place? This is kind of what das-peter was suggesting in #13, which looks like a valid solution too.

The database call is needed for things like i18n that add additional data there.

Ok. so then the final question that never completely got answered is, does it make sense to always build the default info object?

Eg, move the code snippet from http://drupal.org/files/issues/ctools-default-block-info-1275886_0.patch *inside* of the call to _ctools_get_block_info()?

jwilson3: Yes, I believe that makes total sense.

Subscribing. I'm getting this error too.

jwilson3: so is that a patch you could roll? (comments in #32 and agreed upon in #33). I can dive in, but you seem to already know the correct spot...

The core of the issue here is that CTools try to integrate with two facilities that are private to the block module:

• The {block} table, that determine how a block should be rendered depending on the theme and on the region it is placed in;
• The hook_block_list_alter() function that modifies how blocks are rendered *when rendered by the block module*.

CTools doesn't need to (and should not try to) mess with any of those.

I think what we should do here is:

• Only use the result of hook_block_info() (and the corresponding hook_ctools_block_info()) to define and render blocks
• Use the title of the block (from the {block} table) only for block exposed by the block module and only as the *default* setting for override_title and override_title_text

Here is a patch that implement this strategy. Do we need an upgrade path somewhere?

Damien's patch from #36 works like charm and I think it's the most elegant solution too. Thanks!

Works right to me too.

Thank you @Damien.

Damien:

The reason I went with that private strategy is that i18n does its thing in a similar fashion, and by going through the block info, i18n can translate block info. Without it, the block titles do not get translated.

Patch in #36 fixes all instances of the errors om my setup (which were mainly showing on panels pages).

The reason I went with that private strategy is that i18n does its thing in a similar fashion, and by going through the block info, i18n can translate block info. Without it, the block titles do not get translated.

i18n translates the title of blocks *when they are used by the block module*. That the title of the blocks is managed and translated differently when used in a Panels feels by design to me.

Sorry but just to clarify. Are we discussing the use of the core locale module or the contrib i18n module?

The patch works and seems logical, but I'm not using i18n, so I won't RTBC.

@jpstrikesback: we are talking about the contrib module.

Works for me and several others RBTC? can we move i18n to a separate issue to we can get this committed?

I'm building a site with heavy use of panels, ctools and some custom modules producing block content. Eventually, I will need to implement i18n since there are two official languages in my country (Norway).

I'd be more than happy to test patches in an i18n environment. As I understand the situation right now, the patch suggested bypasses the translation of block titles. A possible solution would be to build a blank #info (#24) that i18n can hook into and do it's magic.

For the record: This patch breaks too the translation of block content (i18n_block) introduced here #1168272: Drupal blocks are shown untranslated.

This is the aproach @das-peter proposed and that works with i18n_block.

after updating ctools to the latest dev .. my errors disappeared.. it was appearing when i create a slideshow view block and loaded it in via panels.

Hey @duckx. I just updated and get the error again, so it's still an issue.

@rickmanelius have you applied #48? Does it fix the issue in your environment?

@jherencia. I'm using patch #36 without issue. #49 seemed to imply that there was a fix without a patch... hence my comment. I haven't tested #48 yet, but can confirm #36 works.

@rickmanelius #49 fixes this problem but disables the possiblity to render blocks in different languages via i18n and i18n_block.

If you can, please test #48 in your environment, in order to get some feedback.

I've just applied #36 and #48 (separately, reverting back in between) to 7.x-1.x-dev (2011-10-16) and can confirm they are both working for me. I am not using i18n nor i18n_block.

#48 solved the issue for me. Not using i18n modules.

#36 solved my issue as well...Thanks Damien!!

I like the simpler solution, myself. Committed and pushed.

I have blocks in sidebars on some pages. On one page, I'm using panels to disable the sidebar regions. On that page, I am placing a block that is in a sidebar on other pages. That gives me:
Notice: Undefined property: stdClass::$title in ctools_block_content_type_render() (line 162 of /var/www/d7/sites/all/modules/ctools/plugins/content_types/block/block.inc).

_ctools_block_load_blocks() calls ctools_block_list_alter(), which removes all blocks assigned to a sidebar region when sidebars are disabled. So then, the fake $info object is built in _ctools_get_block_info(), which doesn't have a title, so if ($module == 'block') { $block->title = $info->title; } causes the notice.

Rerolling the patch from #36, it addresses the OP and my problem. I'm still not fully sure about the i18n concerns.

This issue has been coming up for me since updating ctools when 7.12 was released. The changes in #48 are in the dev version so I have applied the patch at #59 which fixes the error message. I am not using i18n either.

Thanks
B

I was still getting these same error messages any time I saved a custom block:

Notice: Undefined property: stdClass::$title in ctools_block_content_type_render() (line 162 of .../sites/all/modules/ctools/plugins/content_types/block/block.inc).

(Using 7.x-1.x-dev with all caches cleared multiple times.)

These were basic drupal custom blocks containing plain text that were being displayed in the standard Garland theme regions. — no panels or anything. I ran the patch from #59 and now the errors don't appear anymore.

Latest patch sadly does not apply. :(

Well, #1252398: Make block panes work without block module installed changed the exact same stuff, and was mostly a workaround for the code that this issue removes.

Oh I should've paid attention and used git am. Sorry, but I did credit you at least.

Hi there, #63, which is in RC2, broke any page that has User login pane block.
See #1488888-6: Blank start page after update to the latest dev or to the rc2.

That's exactly my problem ....
I'm using D 7.12 and CTools 7.x-1.0-rc2. When I add user login widget to a panel, the front page gets completely blank, no errors. The rest of the site works just fine.
Apache log shows the following error;
PHP Fatal error: Call to undefined function _ctools_get_block_info() in drupal-root-dir/sites/all/modules/ctools/plugins/content_types/block/block.inc on line 438

UPDATE: 2012-03-30
Upgrade to recently released CTools 7.x-1.0 solves the problem