After adding a block as content in a panel, the Configure block link shows for user 1 even when the block module is disabled because the if statement on line 125 of ctools/plugins/content_types/block/block.inc only checks user_access() and user 1 returns TRUE for even non-existant permissions.

Adding a module_exists('block') condition to the if statement is one solution.

Comments

Soren Jones’s picture

StatusFileSize
new526 bytes
dixon_’s picture

Title: Configure block link shows for user 1 even when block module is disabled » Make block panes work without block module installed
Component: Plugins system » Code
Assigned: Unassigned » dixon_
Category: bug » feature
Priority: Minor » Normal
Status: Active » Needs review
StatusFileSize
new1.25 KB

Here's a simple patch that makes block panes work without block module installed. It actually works pretty well. The only thing that modules implementing hook_block_view() will notice, is that they won't get a full $info object passed around. But, the object still contains the most vital information, module, and delta. The $info object won't contain theme, region and weight, but those properties are rarely used inside hook_block_view().

The patch also fixes the issue mentioned in the OP.

So, all in all, I'd say this is a pretty good trade off for making it possible to use blocks without block module installed.

rafaqz’s picture

The patch isn't applying for me in current dev version:

Checking patch plugins/content_types/block/block.inc...
error: while searching for:
$block->title = NULL;
}

if (user_access('administer blocks')) {
$block->admin_links = array(
array(
'title' => t('Configure block'),

error: patch failed: plugins/content_types/block/block.inc:122

Thanks would be really great to have this working.

merlinofchaos’s picture

Status: Needs review » Fixed

The patch applied just fine fo rme; I committed and pushed it. This is awesome. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

dixon_’s picture

Status: Closed (fixed) » Needs review
StatusFileSize
new911 bytes

Looks like the changes introduced by the committed patch in this issue, was reverted in another. Looking through the Git logs things got reverted here: #1275886: Error - Notice: Trying to get property of non-object in menu_block_view_alter()

Quoting tim.plunkett in comment #63 in that issue:

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.

However, I don't agree with Tim ;) The changes introduced by that issue makes it impossible to run a Panels site using block content types without Block module since it's querying the {block} table. The whole point of this patch was to be able to do that, because most blocks do work by passing a stub $info into hook_block_view().

So here's a new patch that fixes the problem again :)

merlinofchaos’s picture

The structure is odd where we first build an $info, then if block module exists we throw it away. Can we reorganize its so we only construct the partial $info block if necessary?

merlinofchaos’s picture

As I think on it, I think I'd rather have the empty $info construct originate in _ctools_get_block_info() because the calling function doesn't really care about that detail anyway.

merlinofchaos’s picture

Status: Needs review » Fixed

Looking at the current code, this patch is no longer necessary.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.