Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comments
Comment #0.0
SpleshkaFixed placeholder name.
Comment #0.1
SpleshkaNow it looks much better )
Comment #1
andypostSuppose the whole block.inc should not work when block module disabled
Comment #2
SpleshkaWhy 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.
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedThere is already a module_exists() call inside ctools_block_load_block(), so this patch seems unnecessary.
Comment #4
merlinofchaos CreditAttribution: merlinofchaos commentedBetter status. #1754770: _ctools_block_load_blocks() breaks sites when Block module disabled.
Comment #5
SpleshkaYour 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:
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:
This issue is still critical, since breaking normal operation of the site.
Re-roll patch for a new 7.x-1.x.
Comment #6
andypostThis 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
Comment #7
Spleshka@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.
Comment #8
merlinofchaos CreditAttribution: merlinofchaos commentedWe 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?
Comment #9
podarokgrrrr
ctools tests broken
this patch never be tested by bot before tests fixed
http://qa.drupal.org/pifr/test/111139
Comment #10
andypostIn case of none-existent block the return value would be stdClass but without patch it returns NULL
so this should be separate condition and only here new stdClass instantiated
Comment #11
SpleshkaOk, fixed your notices.
Comment #12
andypostThere'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
Anyway you need to make sure that block table exists!
Comment #13
SpleshkaStill 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.
Comment #13.0
SpleshkaImproved my English :)
Comment #15
Chris Matthews CreditAttribution: Chris Matthews as a volunteer commentedThe 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.