Block "Show Block on specific pages" is overridden by context

I also have experienced this problem. It's actually a pretty significant problem. And I think it's related to this: http://drupal.org/node/345050 which is an issue that's been around for a while that context makes the core block title functionality disappear...

So my issue is that the contexts I create are problematic given that I can't also have the "show on every page except the listed pages" functionality. Seems like a major bug to me.

And given that I can't revert back to context 6.2 version, i really hope the maintainers can tackle this one soon.

thanks

g

I suspect this is 'works as designed'.

I think it would be rather confusing if I created a context, defined its conditions, added a block to it, and then found the block wasn't always showing, because of some settings in a completely different part of the UI!

I wouldn't imagine it is 'works as designed', since lots of other block properties are set in the block admin page, especially considering this used to work.
On my site, this actually does work for blocks that existed before the update to this version.

Agree with xenophyle. Disagree with joachim. What's "confusing" is to have the context module essentially disable functionality that is part of core Drupal while still leaving in place the core Drupal UI which makes it appear that the functionality is still available.

FYI, there is some discussion of this in a separate issue ticket titled "Blocks set with context do not respect block title override":

http://drupal.org/node/345050

Sheldon is right. There are 2 options:

1) Hide the UI that is being overriden. IMO this is better, because it's cleaner. If you decide to use context, you should work all visibility settings here.

2) Do not override core settings. This might be complex and cause unexpected behaviour. Should both settings make an "AND" or an "OR" ?

BTW, why do you need to place a block in Context and configure visibility through block UI? Is there a real use case for that? Can't you just place it in core block admin page?

Also, you could create more contexts, which is ideal when working with contexts (have a lot of them).

For the example, if you have a context that has

path1/*
path2/*

But you don't want a block to display on path2/*, then it shouldn't be in this context. You need to create another one and list the paths.

I'd agree with Franz - the whole purpose of using contexts, the initial reason the Context module was written, was to have a better way of doing the visibility rules without pulling your hair out over custom PHP in this stupid little text field; I'll see about doing a patch to just hide the visibility field as you really should do one or the other.

All of the other problems with block titles, etc, those are a different issues and are handled in #345050: Blocks set with context do not respect <none> block title override (and possibly others) - lets keep this to one issue per problem, people :)

Well, in my use case I have a fairly complicated D6 site that makes extensive use of the block visibility to hide certain blocks delivered by Context on certain pages. My website is www.nysenate.gov, which includes sections for each of the 62 senators in the New York State Senate. Each senator's section includes a number of blocks specific to senator pages. Similarly, we have sections on the website for each senate COMMITTEE, and each committee page includes a number of blocks specific to committee pages (such as a block to display the calendar of meetings for that committee). In addition to senators and committees, we're doing something similar with a couple of other content types on our sites -- "events" and "initiatives."

That sounds like a good use case for the context module, right? I've created a "senator" context, a "committee" content, an "event" context and an "initiative" context to apportion blocks for each of these content types.

However, individual senators sometimes make requests to not display certain blocks on their senator pages. To accommodate these requests, we've been using custom PHP to control block visibility. This combination of the context module and the block module's PHP visibility settings worked fine untll I upgraded to Context 6.x-3.0, and now it's broken. It appears that the only way I can fix this now is to stop using the context module and write a whole bunch more "custom PHP in this stupid little text field," or else create separate contexts for each separate block that uses PHP logic to affect visibility on senator pages, committee pages, event pages and initiative pages. Either of those approaches is going to take a lot of work to implement and will make for very messy website maintenance going forward.

If you want to argue that this is a use case which the context module is not intended to address, I suppose there's an argument for that. However, I can't see any good argument for having a module whose functionality changes in this fashion from one version to the next without any documentation or warning. It's also bad in terms of user interface to have a module which disables functionality that Drupal developers expect to exist because there are form fields for it in the core block module's user interface. If the context module is going to disable functionality that exists in Drupal core, this change needs to be clearly documented and reflected in the core block UI.

@sheldon: honestly, what you're doing is really confusing - why use Context at all if you're just going to use Block Visibility Rules anyway? Given that "control[ing] block visibility and menu active classes on a per-context-basis rather than patching together many disparate elements" was a key rationale behind building Context, I'm tempted to just mark this as "won't fix".

@DamienMcKenna:

Well, one reason we tried using the context module is that we have so many blocks on nysenate.gov that controlling them all via the standard Drupal block module UI was getting complicated and confusing and even creating some vexing timeout errors on the server end when we would save changes at admin/build/blocks. The context module let us group all of the blocks that were specific to the "senator" content type. Likewise, it let us group all of the blocks specific to the "committee" content type, etc.

So, for example, we have the following blocks which I have associated with senators' pages using the context module and the context UI (this is a partial list):

About this blog
Social buttons
Senator's Featured video
District_map
Upcoming events
My Committees
Senator Quickpoll
...etc...

Now, suppose that Senator Smith says, "I don't want the Social Buttons or the Quickpoll" to appear on my pages. How do we give Senator Smith the option of turning those blocks off on his page, without turning off those blocks on the pages of Senator Jones and all the other senators?

Our approach until now has been to use the PHP visibility option to let each block call a function named nyss_blocks_display() which returns a value of true or false, depending on various tests, e.g., "Has senator Smith checked the 'Hide quickpoll' checkbox?"

You're telling me that my only option should be to give up on using the context module to organize display of blocks for senators on our website, because you think it is "confusing" to do that in combination with block visibility rules. However, it would be much MORE confusing for us to have to make each block conduct TWO tests before deciding whether they display or not. If we don't use the context module, our PHP logic for each block for a senator has to first test, "Is this a senator's page," and then, "Has senator smith checked the 'Hide quickpoll'' checkbox?"

The context module therefore offered considerable simplification to our task of managing block placement on NYSenate.gov, but it is only useful to us if we can still use PHP logic to toggle whether individual blocks display within each context. This functionality existed and was useful to us until version 3.0 of the context module took it away. If your response is "won't fix," then I guess we're screwed. It's evident, however, that I'm not the only person who wants this functionality. (I didn't create this ticket originally. Someone else did.) Moreover, other users (such as sp3boy in the other issue ticket that I referenced above) have also expressed frustration that this won't let them upgrade to context 3.0 without it breaking their site.

You're telling me that my only option should be to give up on using the context module to organize display of blocks for senators on our website, because you think it is "confusing" to do that in combination with block visibility rules. However, it would be much MORE confusing for us to have to make each block conduct TWO tests before deciding whether they display or not. If we don't use the context module, our PHP logic for each block for a senator has to first test, "Is this a senator's page," and then, "Has senator smith checked the 'Hide quickpoll'' checkbox?"

If you're going to use PHP anyway, it is better that all checks are in one place, rather than partly in context and partly on some PHP code.

You could simply write a context condition plugin for this use case. That would be just perfect.

franz: I don't think you understand the use case as I have outlined it above. Either that, or I don't understand what a context condition plugin does. As I understand it, a context condition plugin contains the logic necessary to test whether or not a page is in the "senator" context. But how would that let me suppress display of an individual block such as the "senator quickpoll" block on the page of Senator Smith, while still allowing that same block to display on the pages of all other senators?

It seems to me that writing a custom context REACTION plugin is the way to fix my use case. I started looking at context_reaction_block.inc as a way to do this but haven't figured out how to do it yet.

If writing a custom condition plugin or a reaction plugin will fix my problem, fine, I'm willing to write one. I haven't written custom context plugins before, but I'm willing to learn.

No, you misunderstand the way to use a context, and I don't blame you for that, as it is not very intuitive. Instead of thinking of a context like "a section" or "a kind of page", you must think of it rather as a "situation where this reaction applies".

In this case, your context should be something like "senator_poll", which means: "Poll block on senator pages that chose them to be enabled", in which you could have the condition for senator page AND another custom condition for checking the senator preference. So, in a senator page you can have a "senator situation" and a "senator that wants poll block situation", each of these with their proper reactions (usually blocks). For complex usages like these, it is common to have single-block contexts.

From another perspective:

Think of all your blocks being configured in core. Think of all the visibility settings. Now group all the blocks with EXACTLY equal visibility setting. Each group can be a context.

Example: You have user_login on every page, poll on senator pages if senator approves, senator bio on senator pages, senator last posts on senator pages. Your groups would be:

group 1

user_login

group 2

senator poll

group 3

senator bio
senator posts

Each of them can be turned now into a context straight-forward. You can notice senator pages might have all 3 contexts enabled, which is fine.

franz: I understand what you're describing, and I guess we can try to make that approach work. However, it seems MORE complicated to me than the approach I've been using up until now of layering the existing blocks visibility functionality that comes with Drupal on top of the context module. Instead of creating a single context to handle senators' blocks, NYSenate.gov would have to create about 10 contexts, 9 of which are subcontexts of the "senator" context.

Also, senators are currently controlling which blocks appear on their pages by checking or unchecking CCK fields on their senator nodes. (NYSenate.gov has a "senator" content type with fields that include the senator's biography as well as various settings fields that include things such as checkboxes that control which blocks the senator wants to display. Each senator has exactly one node of this content type.) I don't know of any way to use the context module so it uses CCK fields to set conditions. Are you saying I would have to write a context condition plugin to do that? Is that really going to be easier than using the visibility options that come built in with the block module in Drupal core?

Context doesn't seem to be flexible up to this point, but if you see it that way, I still prefer to maintain 10 contexts that are similar and use the same codebase (a custom plugin for the CCK) than maintain 10 (or more) PHP visibility settings.

It might be the case you'd need some other module or to extend context in some way to achieve this more easily.

subscribing

While I can understand that some sites are hard to get exactly the way you want, Context is used specifically to NOT deal with the Block visibility settings. I suggest you make your Context's more granular and have some custom conditions/reactions (as franz suggested) to allow each Senator to enable/disable certain contexts that control those boxes.

If Context is designed to ignore Block visibility settings, you should at least reflect this in the Drupal user interface by having the Context module hide the visibilty settings from the "edit block" user interface. Otherwise, users will be confused by seeing options in the user interface that don't work as described. The Context module should document the fact that it is disabling some of the functionality in the core Drupal UI.

Well, I dont think they should be hidden b/c you can still place a block into a region on the BLocks page and the normal block system will work, so hiding it is not the correct thing to do. All of my sites hide that block screen by doing an menu alter so that no one can use the block screen at all.

That said a message on those setting might be helpful. If you want to write a patch for that we can commit it.

I'm not going to write a patch for this, because that patch wouldn't fix the problem on my website. For the time being, I've rolled my site back to the earlier version of the Context module from when it was still compatible with block visibility module. That's the only option available for me to fix the places that broke on the Senate website when I upgraded to the newer version of the Context module. Longer-term, I'll have to decide whether to try to come up with a fix that works with the current Context module or discontinue using Context entirely.

From the discussion here, it sounds like the only way I might be able to get my site working with the current Context module will be to follow franz's suggestion and "simply write a context condition plugin." I assume "simply" is intended ironically, since it is certainly less simple than the little PHP snippets in the block visibility settings that I currently have working with the older version of the Context module. And will I have to write a separate plugin for each of the 10 or so different blocks where this is an issue on my website (each of which is currently controlled by a slightly different PHP snippet in the block visibility settings)?

I guess I'm going to have to figure out how to write context plugins. Can someone at least point me to some reference information that explains the difference between a "condition plugin" and a "reaction plugin"? I think I understand what a "condition plugin" does. It tests whether a particular page on the website belongs to a specified context, correct? But what does a "reaction plugin" do?

I tend to agree with your arguments Sheldon.

My scenario is that I have a 3 global contexts.
On Season
Off Season
Lead Up Season

I would like some of my blocks to be visible in On Season & lead up Season, currently to do this I have to code it in my module (or make a context per block), however it would be nice to code it in the PHP section of my block visibility settings, even cooler would be if my block had a back reference to context and I could set visibility based on context :) so we get a reverse functionality.. I can see how this could all become very confusing and I do see the why it was done this way, however, adding in a switch between this mode and the other could solve this problem.

have you seen this module: http://drupal.org/project/context_respect
I have not tried it but it may help.

@Sheldon, if I can remember your use case well, I don't think you'll need that many condition plugins. If you collect the PHP snippets I'm sure you can refactor them into a single one.

You can check the existing condition plugins. They are very simple. I'm saying "simply" not as an irony, because it's not much more than a PHP snippet, and if you're able to properly design a single one to work on all cases, you'll be gaining in code maintainability.

I think there are docs in API.txt.

@franz: OK, here's an example of a condition for which I need to be able to test:

1. Does one or more of the following three conditions exist:
   1. I am on the full node page of a node (blog post, news release, event announcement, video, etc.) that has a nodereference to a node of content type "senator"?
   2. I am on the full node page of a senator.
   3. The page that I am on begins with the path "senator/" followed by the a patch specific to one of the senators on our site, e.g., "senator/eric-adams"?
2. If so, does the nodereferenced senator node have a flag or CCK value set to "display call to action block on senator's pages"?

If so, I would be in the the "display senator's call to action block" context.

FYI, I have a nyss_senator() function already defined that does tests for the first three conditions listed above and returns the loaded senator node if so. That function is expensive to run, so I don't want to have to run it repeatedly. I've therefore created the following hook_init function:

function nyss_senator_init() {
  // Determine what Senator, if any, this page belongs to.
  $senator = nyss_senator();
  if ($senator) {
    context_set('nyss', 'content_type', 'senator');
    context_set('nyss', 'senator', $senator);
  }
}

To minimize performance load, I would like the "display senator's call to action block" context to first use context_get to determine whether the "senator" context is set and retrieve the senator node. The "display senator's call to action block" context is therefore effectively a subcontext of the "senator" context. Can a condition plugin test to determine whether other contexts are already set?

I found this issue very late in the game here and this issue might be dormant, but I'll throw out an answer anyway.

#27, the way I would do it is to write three separate context condition checks (as outlined in your #1/#2/#3), add all three of them to your context, and select the checkbox "Require all conditions" on the context edit page. The context won't know about each other but it would seem to accomplish what you are after.

This became an issue for me after upgrading to 3.0. I tend to agree with Sheldon's arguments because I have a legacy use case that is similar, though far less complex: I group eight "products" in a "product" section. I have a block for each product, and on any one product page I show the other seven in a sidebar. I'm using one context for this because all share other conditions and reactions. The only difference is in block visibility, which I had been controlling in the block interface before the upgrade. It now no longer works as discussed above.

I could create eight contexts in place of the one, and that's not a lot of work. I'm not in love with the idea because the eight would have only one difference between them. I noticed this issue when I built eight replacement blocks. It was a matter of changing one context to fix them all. I guess I could have created eight block visibility contexts and one context for the common reactions, but that's adding more to manage. I'm asked to add more products and scaling this up is looking unpleasant.

I'm no fan of the block system and I like the Context module a lot. My use case aside, it seems to me that we should let blocks control their own visibility at least because they can be used outside of Context. I understand franz's argument in #16. My head is just not there yet. My two cents anyway.

This issue is present also in the 7.x branch. I don't want to start a new discussion for that version of the module, but I think that letting people decide how to handle visibility settings for blocks gives more flexiblity to the whole system (and here I'm talking about Drupal).
I understand what Franz says, but sometimes it just add more complexity to something that could be handled with a few lines on the blocks visibility settings and not all Drupal users are able to write a Contexts plugin. This sounds like an unnecessary limitation.
The point is also that is what people expect having access to the "Show block on specific pages" form. This seems confusing and I don't understand the reason to put this limitation on users actions. You never know how people end to use a module.

Solution on #25 worked well for me: Context Respect Module seems to be the soluton.

Many thanks to @gamelodge.

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 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

Thanks and Regards
Ravinder

I've just come back to this thread after many months and am pleased to report that the Context Respect module worked well when I tried it in Drupal 6:

https://drupal.org/project/context_respect

My thanks also to @gamelodge for suggesting it.

Context Respect Module - perfect! Worked a charm! :-)

Sorry if am on the wrong section but the show blocks on specific pages isn't working in drupal 8, has anyone come up with a solution?

Using https://drupal.org/project/context_respect would be the worst approach IMO!
Debugging why the block does not appear on the page would become a huge problem. This is a clear example of a bad practice!