I have a block which is shown on all subpages under "mypagename", using the following bmock visibility settings:
Only the listed pages --> mypagename/*
Except I now need to exclude one page under "mypagename" for showing this block. Is there a way to easily exclude this page using the standard settings of Drupal 7?
There's nothing in the core UI, no.
hook_block_list_alter() exists for exactly this sort of scenario, though:
Act on blocks prior to rendering.
This hook allows you to add, remove or modify blocks in the block list. The block list contains the block definitions, not the rendered blocks. The blocks are rendered after the modules have had a chance to manipulate the block list.
e.g.
function MYMODULE_block_list_alter(&$blocks) {
if ($some_condition) {
// Remove the block from the list.
unset($blocks[$some_key]);
}
}
Sometimes it may be feasible on the theme level. What blocks I need depends more on type of content than on it's URL, and I do find that for specific subpage I don't need some blocks, whilst I need them for others.
In such cases I simply create a region I output where I need it and don't output where I don't. Main benefit is: I do not need to iterate over configurations and update them when I restructure my page. I only need to update theme. And pretty often I don't really need even that.
Similar benefits are possible with Clive's answer, too, if you take care about setting $some_condition properly.
There seems to be nothing in core, indeed. However, apart from writing your custom module, you can also use the Rules block visibility module as an alternative (and which doesn't require the PHP filter to be enabled either, which you should try to avoid whenever possible). Here is a quote from its project page:
The Rules block visibility module allows Rules components to be used to control block visibility. This provides Drupal administrators and developers extreme flexibility in controlling when blocks should be displayed on their websites, in addition to the default visibility options provided by Drupal.
The general idea is that if you can do it with Rules, you can use it to control block visibility, so the possibilities are limitless.
Need to show a block only for users registered more than a month ago?
Perhaps you have a block that must be shown only between 8am-5pm on weekdays?
What about displaying or hiding a block based on current weather conditions?
All of this can be done by using Rules block visibility.
With that, and as per the "if you can do it with Rules, you can use it to control block visibility" above, you've reduced your question to making Rules "check the path of the current page" (so that the block is only shown on your pages with a path that starts with "mypagename/", but not on a subpage with a path (say) "mypagename/exception").
For an illustration of how to use this module, refer to my answer to "How to stop a Views block from displaying to admins, such as user/1?". It includes a Rules Component (in Rules export format), which you should replace by this variation of it to make it match your specific question):
{ "rules_block_visibility_show_on_selected_subpages" : {
"LABEL" : "Show block on selected subpages",
"PLUGIN" : "rule",
"OWNER" : "rules",
"REQUIRES" : [ "rules" ],
"USES VARIABLES" : {
"module" : { "label" : "Module", "type" : "text" },
"delta" : { "label" : "Delta", "type" : "text" },
"result" : { "label" : "Result", "type" : "boolean", "parameter" : false }
},
"IF" : [
{ "AND" : [
{ "text_matches" : {
"text" : [ "site:current-page:path" ],
"match" : "mypagename\/",
"operation" : "starts"
}
},
{ "NOT text_matches" : {
"text" : [ "site:current-page:path" ],
"match" : "mypagename\/exception"
}
}
]
}
],
"DO" : [ { "data_set" : { "data" : [ "result" ], "value" : "1" } } ],
"PROVIDES VARIABLES" : [ "result" ]
}
}
Note: have a look at the rules_block_visibility.module code also. And notice how it also implements hook_block_list_alter(). So using this approach you have a lot of the Rules (Conditions) power available also.
TRUE(experts only) seems to be your bet. Make it return false for problematic subpage, return true for all the rest of subpages, and return false for everything else/eval(), you can do what Clive says. I findeval()perfectly OK for prototyping, for example, but of course some concerns are perfectly valid and Clive's answer, while slower in development, certainly has benefit of "code only in files".