Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I'm using context to lay out blocks in regions and have just encountered a potential issue with paths containing wildcards. I'll try to explain:
Say I've got a block layout context (context-1) that activates on a given wildcard path. But I need a different block layout (context-2) on a single page whose url falls within in the original context's (context-1) path. How do I override or exclude the single page path (context-2) from the original block layout context (context-1)?
The wildcard path option in Context is excellent and allows me to catch all pages created later under a specific path (and menu with pathauto). I feel there may need to be some kind of exclusion option so when defining which paths activate a specific context you can also specify exclusions from that rule.
The only other thing I can think of to get round this is to have some kind of weighted system where a higher weighted context overrides a lower weighted context. But I think contexts merge rather than override at the moment.
Any thoughts? Maybe there is already a way to do this that I haven't thought of.
Comments
Comment #1
timcosgrove commentedI'm also running into this with respect to using Theme Variables. Because of the way context_active_values() is constructed, and because the theme_section array is associative rather than numerically indexed, each time an active context is iterated over, the previous values are thrown out.
Structure of theme_section is Array ( [title] => [subtitle] => [class] => )
This theoretically makes sense; you don't want more than one title or subtitle. However, you would probably want the ability for one title or another to take precedence. Currently you just get whatever context is evaluated last.
Note also that if the context definition has
'theme_section' =>
array (
'title' => '',
'subtitle' => '',
'class' => '',
),
all the values get emptied. This is arguably not a bug, but it would be nice if it checked for values being empty or not.
Comment #2
redijedi commentedsubscribing
Comment #3
tirdadc commentedSubscribing. This would definitely be handy and a nice improvement for the Path condition.
Comment #4
joachim commented+1
Currently, making a context that fires for (whole site EXCEPT path/foo) is not really doable in a maintainable way -- as far as I can tell, I have to put in EVERY other path on my site and remember to update this if paths change.
Comment #5
jbenjamin commentedcould you not create a second namespace for handling the exceptions? From what i can tell, the module reads the list in order for each namespace, which is where i was running into problems with sledgehammer wildcards. By creating a new namespace (beginning with "z_" i was able to effectively override wildcards.
in my case it was to remove a sidebar region from any page that was a calendar view (*/calendar/*) - the problem was that i also had a context to place blocks within that same region based on path taxonomy. (traditional/*)
the namespace came up roses in this particular instance. Hope this may help!
Comment #6
steven jones commentedIf someone wants to write a condition that excludes menu paths then I might consider it for inclusion, otherwise there is a solution in #5.
Comment #7
a_c_m commentedWorkaround. http://drupal.org/node/450008
Create your context as a site wide context, insuring its at the top of the list (prefix its name with 'a_'), then create a 2nd context, in the same namespace + attribute with the EXCEPT requirements (e.g path/foo).
The 2nd context will override the first, unsetting any of its changes.
A bit of a hack, but it works!
Comment #8
steven jones commentedThe original issue is a non-issue, but the issue in comment #1 is a bug.
Need some documentation about how to do the path exclude thing.
Comment #9
steven jones commentedActually context does do the multiple contexts adding different classes to the body.
Comment #10
steven jones commentedThis is actually a specific use case of #450008: Rename 'Sitewide' context to 'Sitewide/default' context