Hi,

Thanks for such great module.

After I updated Chaos Tools from 7.x-1.0 to 7.x-1.2 I got WSOD. In log I had next message:

a:6:{s:5:"%type";s:12:"PDOException";s:8:"!message";s:300:"SQLSTATE[42S02]: Base table or view not found: 1146 Table '[basename].block' doesn't exist: SELECT b.*
FROM 
{block} b
WHERE  (b.theme = :db_condition_placeholder_0) 
ORDER BY b.region ASC, b.weight ASC, b.module ASC; Array
(
    [:db_condition_placeholder_0] => [themename]
)
";s:9:"%function";s:27:"_ctools_block_load_blocks()";s:5:"%file";s:113:"/path_to_domain/sites/all/modules/ctools/plugins/content_types/block/block.inc";s:5:"%line";i:101;s:14:"severity_level";i:3;}

It happens when I removed module Block from my site (I use Panels Everywhere instead). I don't use any blocks on the site, but if I try to output menu panes they are rendered as a block. And when Ctools tries to get information about this block from database (from `block` table) I get this error.

Solution
We should simply check whether Block module are installed or not. Patch attached.

Thanks for your time and consideration.

Best regards,
Spleshka.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Spleshka’s picture

Issue summary: View changes

Fixed placeholder name.

Spleshka’s picture

Issue summary: View changes

Now it looks much better )

andypost’s picture

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

Suppose the whole block.inc should not work when block module disabled

Spleshka’s picture

Why shouldn't it work? We have to render it in some block or panel anyway. So if module is disabled we simply should not load data from the {block} table.

merlinofchaos’s picture

Status: Needs review » Closed (won't fix)

There is already a module_exists() call inside ctools_block_load_block(), so this patch seems unnecessary.

merlinofchaos’s picture

Status: Closed (won't fix) » Closed (duplicate)
Spleshka’s picture

Status: Closed (duplicate) » Needs review
FileSize
1.12 KB

Your issue #1754770: _ctools_block_load_blocks() breaks sites when Block module disabled. still has bugs. If you return simply empty array instead of block info, hook_block_view_alter() wouldn't be called. See this peace of code:

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);
  $block = module_invoke($module, 'block_view', $delta);

  if (!empty($info)) {
    // Allow modules to modify the block before it is viewed, via either
    // hook_block_view_alter() or hook_block_view_MODULE_DELTA_alter().
    drupal_alter(array('block_view', "block_view_{$module}_{$delta}"), $block, $info);
  }
  $block = (object) $block;

So if Block module is disabled you will return empty array here. In this case hook_block_view_alter() will not be executed.

This could break some other modules logic. For example, i18n_menu localize menu items only during hook_block_view_alter(). See this peace of code from i18n_menu:

function i18n_menu_block_view_alter(&$data, $block) {
  if (($block->module == 'menu' || $block->module == 'system') && (i18n_menu_mode($block->delta) & I18N_MODE_MULTIPLE)) {
    $menus = menu_get_menus();
    if (isset($menus[$block->delta])) {
      if (empty($block->title)) {
        $data['subject'] = i18n_string_plain(array('menu', 'menu', $block->delta, 'title'), $menus[$block->delta]);
      }
      $data['content'] = i18n_menu_translated_tree($block->delta);
      // Add contextual links for this block.
      if (!empty($data['content'])) {
        $data['content']['#contextual_links']['menu'] = array('admin/structure/menu/manage', array($block->delta));
      }
    }
  }
}

This issue is still critical, since breaking normal operation of the site.

Re-roll patch for a new 7.x-1.x.

andypost’s picture

This actually related exactly to a menu & i18n_menu which tightly depends on block module so no way to render a menu without block enabled. Suppose this require a follow-up for i18n issue queue

#5 look more like hack that solves this problem but could cause unpredictable trouble with integration other modules

Spleshka’s picture

@andypost, this is really small hack. But in other case we should create new plugin for all menus and create issue in 18n_menu. This could cause a lot of troubles with existing sites that users menu blocks as panes.

merlinofchaos’s picture

We have a question:

If block module is disabled, should we actually be calling that specific alter function? Some people have said yes, others have said no. I erred on the side of no, perhaps, because slightly wrong data is better than actual crashes.

What are other people's thoughts on that?

podarok’s picture

grrrr
ctools tests broken
this patch never be tested by bot before tests fixed
http://qa.drupal.org/pifr/test/111139

andypost’s picture

Status: Needs review » Needs work
+++ b/plugins/content_types/block/block.incundefined
@@ -124,12 +121,23 @@ function _ctools_block_load_blocks() {
+  $info = new stdClass;
...
+  if (module_exists('block')) {
...
+    if (isset($blocks[$key])) {
...
+  return $info;

In case of none-existent block the return value would be stdClass but without patch it returns NULL

+++ b/plugins/content_types/block/block.incundefined
@@ -124,12 +121,23 @@ function _ctools_block_load_blocks() {
+  else {
+    $info->module = $module;
+    $info->delta = $delta;

so this should be separate condition and only here new stdClass instantiated

Spleshka’s picture

andypost’s picture

There's a should be proper fix for menus exactly - introduce a menu.inc special plugin taking ctools/plugins/content_types/page/page_secondary_links.inc
as example and then fix i18n_menu. Easiest way - to add @todo with link to i18n issue and call i18n_menu_block_view_alter() while there's no other way to get multilingual render yet.

OTOH core blocks (not custom blocks) are accessed without block module enabled. So actually there's no need for block module to work with blocks of core modules. This is a very needed feature for panels_everywhere so probably better to move the issue to it's queue

@merlinofchaos Suppose if ctools could "emulate" the core's blocks behaviour probably it needs to fire hooks and i think there's could be special $conf variable to enable the feature (fire block hooks) other way no ability to build multilingual site using panels_everywhere without block module

+++ b/plugins/content_types/block/block.incundefined
@@ -85,9 +85,6 @@ function _ctools_block_content_type_content_type($module, $delta, $block) {
-  if (!module_exists('block')) {
-    return array();

Anyway you need to make sure that block table exists!

Spleshka’s picture

Still don't understand why patch in #11 is not works for you. It solves i18n_menu issue and do not breaks previos behavior.

I digged deeper into 18n_menu and realized that there are no proper way to change module logic. On the other hand we could create new ctools plugin for the menu output, but there will be no migration from current menu blocks to a new plugins. So my patch is the easiest and maybe the best way to solve this issue. If you disagree with me, please, provide your own patch.

Spleshka’s picture

Issue summary: View changes

Improved my English :)

Chris Matthews’s picture

Issue summary: View changes

The 6 year old patch in #11 to block.inc applied cleanly to the latest ctools 7.x-1.x-dev, but still needs to be officially reviewed and tested by the community.

Checking patch plugins/content_types/block/block.inc...
Hunk #1 succeeded at 90 (offset 5 lines).
Hunk #2 succeeded at 126 (offset 5 lines).
Applied patch plugins/content_types/block/block.inc cleanly.