Blocks set with context do not respect <none> block title override

Hey highvoltage,

Thanks for the bug report -- you're correct, I recently changed the block loading logic to be independent of the block module's visibility settings. This also means that currently any block title overrides you do in the block administration page will not have any affect, while a Views block title, for example, is respected because Views builds those blocks dynamically (whose titles you could then override again in the block module).

I'd love to hear more about your needs here as the recent change in context, while cutting some functionality (in terms of layering both context + block role/php/path visibility conditions) opens the door to some exciting new possibilities where modules can alter context-based block visibility rules on the fly.

I'd be open to letting some of this functionality back into the loop (the block title override in particular) but the others definitely lead to some hairy code and more complex visibility logic overall.

Just to get you updated - this sounds like very important functionality for a large class of Drupal site builders out there. I've added it to the list of things to have hopefully by the next alpha release.

I'll keep you posted on the development in CVS if you are interested in testing, etc. Thanks!

This should be fixed as of http://drupal.org/cvs?commit=158876.

This issue seems to have reverted in the 2.0 branch. The attached patch fixes this on sites I have running 2.0.

The patch above didn't work in all cases. This one works better, but now that I dig into it, I'm not sure this is the way to make context respect the subject='' setting.

Young, is block role visibility getting re-imported into the next beta?

I'm currently running 2.0-beta7 and block role visibility is not working.. would be a of great help to site-builders because (for me) there is no way right now to make for example two blocked main pages: one for anonymous users and one for authenticated.

Keep up the good work!!!

Greetings Wappie

PS I'm no real coder but is there a solution in creating a new line under 369 in context.core.inc to check if user is authenticated? Is it maybe doable to write a patch?

Here's a patch that offers a variable named "context_hide_block_titles" which lets you stop all block titles from showing.

Here's a corrected patch that sets the 'context_hide_block_titles' variable's default to FALSE.

subscribing

@DamienMcKenna I'm not sure adding a glabal killswitch for block titles is context's business, look to the theme layer for that.

@jhedstrom What exactly is the issue that your patch fixes? Looks like you're trying to adding custom block titles per context? Can you raise a feature request for this if so.

I'm going to close this issue because the original issue (Blocks set with context do not respect <none> block title override) is fixed, please re-open with details if it's not fixed for you.

I am still seeing the original problem on beta 7:

- at admin/build/block/configure/MYBLOCK I've set title to <none>
- block still shows its original title

Setting the title to any other string fails too for that matter.

Lame. Simpletests are needed I think!

I've just committed a couple of simpletests that show that this isn't a problem with Context in isolation, I suspect your issue is something to do with context interacting with something else.

joachim's issue is with Zen vs. Context.

I want to rename a block and it seems it doesn't get renamed.. the variable is saved in the block... but only the new name is displayed if the block is shown by normal drupal way... If the block is shown by Context.. Then the original name of the block appears...
I have a workaround... disable the block in context. Then enable the block in normal block system. Rename it. And then enable it again in Context. Then the new name appear. Then I can disable the display of the block by drupal system. I'm using Fusion theme.

Encountering this issue with Context 3.0 and a custom theme based on Basic. I'm using inline edit links to take me directly to the the "block_admin_configure" form, using my admin theme (Seven).

When the block is saved, the new subject is saved correctly to the DB - but only for the admin theme, not the currently active theme. If I change the theme value in the database row to my active theme, the overridden subject displays correctly. So, no, this doesn't /really/ have to do with context.

But I am confused as to how to get around this when not using the default block administration screen. It looks like I need to pass the active theme's key into the block form submission. But I don't see how to do that just yet.

FYI, this does not affect block titles for blocks created/managed by Boxes module - since it uses it's own DB table for storing overridden block titles.

This issue is also occurring in Drupal 7 RC1. Any blocks set with the tag are still displaying a title when set with context.

The plot thickens..

On any blocks that come by default, the '', tag is ignored and the title is always displayed. Meanwhile, on blocks that are user created through the UI, no title is displayed even if there is a title. Hope this helps.

I'm getting the same problem

I'm using Drupal 7RC1, Context 7.x-3.0-alpha2

After editing the block title at Home › Administration › Structure › Blocks, the block title rendered on a block displayed through context is unchanged.

When displaying the same block through the core block system, the title behaves as expected.

I'll see what else I can find.

Alright, I've figured out the problem and I have a temporary solution. However it is far from efficient and I think it could be done much better.

context_reaction_block.inc
@@ -324,9 +324,9 @@
         if (!empty($options['blocks'])) {
           foreach ($options['blocks'] as $block) {
             $block = (object) $block;
-            $block->title = NULL;
             $block->context = $context->name;
             $block->bid = "{$block->module}-{$block->delta}";
+            $block->title = isset($info[$block->bid]->title) ? $info[$block->bid]->title : NULL;
             $block->cache = isset($info[$block->bid]->cache) ? $info[$block->bid]->cache : DRUPAL_NO_CACHE;
             $context_blocks[$block->region][$block->bid] = $block;
           }
@@ -397,9 +397,11 @@
           $module_blocks = module_invoke($module, 'block_info');
           if (!empty($module_blocks)) {
             foreach ($module_blocks as $delta => $block) {
+              $blockload = block_load($module, $delta);
               $block = (object) $block;
               $block->module = $module;
               $block->delta = $delta;
+              $block->title = $blockload->title;
               $block->bid = "{$block->module}-{$block->delta}";
               $block_info[$block->bid] = $block;
             }
@@ -415,7 +417,7 @@
       if (module_exists('block')) {
         $theme_key = variable_get('theme_default', 'garland');
         $result = db_select('block')
-          ->fields('block', array('module','weight','delta','region'))
+          ->fields('block', array('module','weight','delta','region', 'title'))
           ->condition('theme', $theme_key)
           ->condition('status', 1)
           ->execute();
@@ -423,6 +425,7 @@
           if (isset($block_info["{$row->module}-{$row->delta}"])) {
             $block_info["{$row->module}-{$row->delta}"]->weight = $row->weight;
             $block_info["{$row->module}-{$row->delta}"]->region = $row->region;
+            $block_info["{$row->module}-{$row->delta}"]->title = $row->title;
           }
         }
       }
@@ -454,6 +457,7 @@
             $context_block = $block_info["{$block['module']}-{$block['delta']}"];
             $context_block->weight = $block['weight'];
             $context_block->region = $block['region'];
+             $context_block->title = isset($block['title']) ? $block['title'] : NULL;
             $context_block->context = $context->name;
             $blocks[$context_block->bid] = $context_block;
           }

I compared contexts means of handling blocks to cores and I found that drupal core passes the 'title' field to the _block_render_blocks function. Currently context is setting that field to null and then sending it. Drupals means of handling this is to then return the default subject for system blocks, however for custom blocks it doesn't return anything.

I believe this issue sort of explains that better: http://drupal.org/node/126070

My temporary solution is to use block_load to get the custom title and then store that into cache, however this may be too tasking on the DB just to return a single field for each block.

Might be better to return all values from the DB where the title column isn't null, then just use that array to quickly associate the title.

Should a new thread be created to address this problem in 6.x-3.0?

Actually, now that I look closer, it looks like it might not be a purely context issue for 6.x-3.0. I'm in the middle of a dual-site migration/integration and I've got the same theme (fusion subtheme) that function in (mostly, I'm still working on the details) the same way and one site is respecting the and one is not. The context, theme, and menu block are configured the same, but one is fusion 1.0-rc1 (respects the ) and the other is 1.0 (ignores the ).

Subscribe

I am having this issue with 6.x-3.x-dev / 2011-Jan-13 release. Should I open a new issue for Drupal 6 since this is marked for 7.x?

I'd love to hear more about your needs here as the recent change in context, while cutting some functionality (in terms of layering both context + block role/php/path visibility conditions) opens the door to some exciting new possibilities where modules can alter context-based block visibility rules on the fly.

I'd be open to letting some of this functionality back into the loop (the block title override in particular) but the others definitely lead to some hairy code and more complex visibility logic overall.

Besides the title override, another side effect of not leveraging the core block rendering is that you're losing the contextual menu entries. My use case is with nodeblock which adds a link to edit the node displayed in a block, but more module which add their own contextual menu entry will suffer from this.

Subscribe.... same problem here

Any chance the patch from #992276: Missing title for custom blocks displayed with context addresses the block title issue?

I tried the patch but with no luck. The patch doesn't solve this issue.

@febbraro that patch is only for custom blocks (belonging to the core block module) and is not generic enough to work with any block.

I can roll my code above into a patch.. I just am not convinced it's the best solution. Sort of hoping one of the maintainers can give some feedback on which direction we should go because I think the problem is a bit larger(using the custom block loader instead of drupal's).

@mikegfx

I'm not certain but don't think you need the block_load() in #26 since that is only getting the values from hook_block_info() which doesn't return the title: http://api.drupal.org/api/drupal/modules--block--block.api.php/function/...

The title is loaded from the database in the following lines anyway.

I created a patch out of your comment above, but I also removed "->condition('status', 1)" form the db_select statement. Blocks get a status of '1' when they are enabled in the /admin/build/block so context shouldn't care about them anyway.

For me, this also fixed #992276: Missing title for custom blocks displayed with context as well since that db_select checks for overridden values of non "active" blocks in the database.

Let me know if this makes sense and/or works for anyone.

acouch, you're correct! Good work! When I wrote the code above in december I'll admit I knew nothing about the d7 data abstraction layer. I have tested your patch and it works exactly as needed. I'll keep testing to see if I find any other bugs. Thanks!

@scor (and others) How does the patch from 36 work for you?

Here does patch #36 works!

Great Job

#36 worked well for me too.

#36 works for me. marked #992276: Missing title for custom blocks displayed with context as duplicate.

We need a unit test for this.

Ok, wrote the test and commited! Thanks everyone.

http://drupal.org/cvs?commit=504532

Sorry but, as for the comments above and version 6.x-3.0, the issue seems to be still active. Is there a simple way to backport it?

subscribe

The block title is a matter of aesthetics

I think, this is not true. The Block title bring us a context. A block without titles are content unities, without contexts. In fact, is not semantic content. (Accesibility issue.. and may be usability issue.)

In my opinion, all block should have a "title". If you not like see this, hide it using CSS or JS.

Regards!

PD: Sorry about my english.

@iorgos: the simple fact is that using <none> in the title is a feature of Drupal core but is broken by using Context thus is a bug of Context.

Seems like this issue has been going on for a while and has not been fixed. I agree with Damien that this is a Context issue... this was not a problem until I upgraded to 6.3 version of Context. Frankly, there are some other problems that have developed, but I'm hunting around for info on those.

UPDATE: So it also appears that Context 6.3.0 also does not honor the show on all pages "except those listed" command within core blocks. So now I have titles I don't want AND can't exclude blocks the way I want... on the pages I want some of these blocks excluded. There is a new issue that has begun on this issue: http://drupal.org/node/1180260

So here's the issue, then: is broken by Context 6.x.3.0 ... Also broken is the 'Show on every page except the listed pages' functionality. I suspect they are related.

This is more than "aesthetics" it has to do with some basic usability. It seems as though this '' issue has been known for a while. Is there a fix planned for the module?

Thanks so much.

Hi,
thanks for posting this, however, why is a Drupal 7 patch in with an issue related to a Drupal 6 problem?

Or can this be applied to the Drupal 6 version as well?

Thanks

ggevalt, the issue affected the 7 version as well, and it was fixed there, but not yet on 6.

Changing status since this was fixed in 7.x.

franz, thanks for clarification. Any plan to fix this in 6? Seems to be occurring on a few theme-related menu blocks as well.
thanks
g

This pours over into performance. Context doesn't respect none when the core block system is disabled, but respects it when core block system is enabled. This is something that should be fixed in 6.x-3.0, and not just in dev.

Personally, I think this really sucks. As I understand it, this means that using the context module overrides the block-specific settings for user-specific visibility settings, role-specific visibility settings, and page-specific visibility settings, as well as the page title. However, it doesn't eliminate those settings (which are part of core Drupal) from the Drupal user interface. This means that site administrators still see those settings as options when they go to admin/build/block and try to configure an individual block, but the options just don't work when they set them. That's terrible UI.

In addition to being terrible UI, this change is terribly documented. I had to hunt through the context module issue queue to discover this, which in other words means it's not documented at all except in the form of comments in a bug report that was filed in 2008 and is still causing people problems three years later.

For my use case, it seems that there is no way to fix this that does not involve either (1) giving up on using the context module as a way to control which blocks appear on different pages of my site; or (2) creating a separate context for each block that needs the level of fine-grained, PHP-based control over block placement which my website (NYSenate.gov) requires (and which was possible directly in Drupal core before yhan turned the context module into an esoteric tool for breaking that functionality and decided to call the resulting mess an "exciting new possibility."

I endorse the frustration of the previous comment. I have taken over management of a fairly complicated D6 site running Context 6.x-2.0 and makes extensive use of the block visibility to hide certain blocks delivered by Context on certain pages. Drupal is warning me that Context 2 is no longer supported, but if I understand this and related issues, an upgrade to 6.x-3.0 will break my site, due to a problem that was identified two and a half years ago?

I understand this kind of frustration, but please try to keep this as informal as an issue queue should be. There is a patch that fixed the D7 version, and nobody even tried to use it on 6.x-3.0 or port it.

I tried to port but I don't have the time to test it, can someone do it?

franz, I haven't tried your patch, but I looked at the code and all it seems to fix is the title. My problem (and evidently the problem for sp3boy as well) is the need to "make extensive use of the block visibility to hide certain blocks delivered by Context on certain pages." I'm running a D6 website, and I discovered that this was a problem after updating a number of D6 modules, including the context module, to their current recommended release. Everything seemed to go smoothly on our development and staging servers, so I pushed the updates onto production only to discover then that this issue existed. The inability to control block placement using visibility settings is a subtle enough problem that it can slip past testing and yet still be a significant problem, as just happened in my case. That's the basis for my frustration. This is a pretty serious bug that was reported three years ago and yet has gone unfixed and isn't even documented in any way that could be considered fair warning, on a module that is being used by more than 20,000 websites.

I'd be happy to work on backporting a patch from D7 to D6, but as far as I can tell, the main problem for me (block visibility) hasn't been fixed in D7 either. I don't see any patches here that fix the block visibility problem, just the title problem. Is there a fix for the block visibility problem?

There's a separate ticket on the block visibility problem that someone recently started here:

http://drupal.org/node/1180260

Sorry this issue is about the block title. It is inappropriate to discuss it here.

FIne, but this is the main thread where I've been able to find any explanation whatsoever of the bug which yhan introduced which has broken my website. It was discussed here more than 2 years ago. I've added a link to this issue ticket at http://drupal.org/node/1180260 so that the module maintainers can reference the discussion that has happened here.

subscribing

I have tried this patch on 6.3 but my custom block titles are still not showing.

Also got hit by this, subscribing and are willing to help out testing any patches that get rolled.

I'll have to look further into this later, as I'm also working with Context on a 6.x site.

Hi
I tried to replicate this issue without success, this is what I did:

1. New clean Drupal 6.22 install
2. moved all blocks to region:none
3. installed: context(6.x-3.0): {context, context layout, context UI}
4. create a context: Conditions: Sitewide-allways-active; Reactions: blocks=navigation{region:left sidebar}
5. Then I played with the navigation block title, set it to: , "other title", and went back to empty and it behaved as it is supposed to.

May be you could provide a test case so I can replicate the issue.

Hm that's strange. Experienced the issue on both locally in my dev. env. and at my customer live site. Perhaps it get triggered i18n? The site got i18n (and block translation) installed, English is not the site default language, thought it is still is enabled.

is the case still that you can't override block titles when you place a block via context, and never through core blocks? that's happening to me..

UPDATE - apparently, if you add the block to core blocks region, change the title, then remove it, then context retains that name for the block title. clearly does not work when core blocks disabled...

yes, only recently I realized this, slavojzizek, and it is also a workaround.

On my site the same thing happens as #67.As long as Core bock is enabled block titles displayed by Context module are overridden. So at the moment I have enabled Core block though I have allocated no blocks by the Core block but only by Context module.

Hello Friends

I have recently solved the issue of not working "Show block on listed pages".

If you use page title or name like : /homeowner-resources then it will not work and block will not show on that page
but if you use specific page node id then it will works fine like : node/5 in text box only then block will appear on specific page

There's a similar issue at #795058: Override Block Titles Via Context UI. It even has a patch in comment #46 that will fix this issue for 6.x-3.x so I'm marking this as a duplicate.

IMO it makes more sense for this to be a setting inside context rather than having context respect the core setting because it is common for people to say "only use context" and advise against using any of the core block settings. If we start the precedent that context respects some of the core block settings where does that line end?

@greggles: it ends with people throwing their arms up in the air and using Panels :)

Counter argument to #71:
If we start adding block settings to the context configuration screens, where does it end?
Will we end up reproducing the entire block configuration form there as well?

Current behavior of context is to respect the title if it is set in system block UI, therefore context should respect the title if it is set to <none>.
The duplicate issue in #795058 is a new feature request, which does not negate the existence of this bug.

I have similar issue when using Context with Blocks from Facet API. The blocks have "Filter by [sth]:" title by default. I want the title to be only "[sth]". Block title override works when used from default Block administration (respects and ""), but not when used from Context.

I think in ideal world it's not Context's responsibility to change blocks titles. But in ideal world Context would be the only way to structure blocks in Drupal. In real world it's unfortunately not and therefore it should extend current Block admin functionality - respect the setting set there (at least the basic ones). Some very important modules (like FacetAPI) don't keep Context in mind and are dependent on the Block admin functionality.

I have the secondary menu block positioned via context in a region. The block title is declared via "admin/structure/block/manage/menu/menu-secondary/configure" as <none> and it's simply ignored.

I use context 3.3

suscribe... this is still happening even with the patch issue #795058

Still happening in context (7.x-3.5).

Does seem to be a problem in version 7.x-3.6

I still have this issue with 7.x-3.7

EDIT : Sorry, I did talk too fast, now it's ok. (Maybe because of caching?)

Apparently this was fixed some time ago.