| Project: | Context |
| Version: | 7.x-3.0-beta2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I have four contexts, all of them are showing a block in the same region and I want only one of them to be active. (Two blocks in this region would mess up):
"sidewide": does actually nothing, is used for the context filter (this context has no block)
"default": Always active, except A or B is ative. So I put a context filter with *, ~A, ~B.
"A": Only for specific paths active, so I put a path filter: sectionA, SectionA/*
"B": This is a subsection of A, so I put a path filter: sectionA/sectionB, sectionA/sectionB/*
If I browse to sectionA/sectionB/test I have to blocks showing up and the side is messed up. But this is no surprise, as far as both contexts "A" and "B" are active because of there paths. To solve the problem, I put context filter into "A" and this is where the bug shows up. (At least I think it is one):
I put an context filter to "A": ~B and require all conditions.
Now I expect "A" to be hidden if "B" is active even if the path filter would let "A" get through. I browse to sectionA/sectionB/test and there is only the block of "B". Correct. But if I browse to sectionA/test then there are two blocks showing up: the one of "A" and the "default". So if "A" gets a context filter, the context filter of "default" is kind of destroyed.
I hope you get what I want the problem is. It seems quite complex to me..
Comments
#1
Hey majorbenks,
Thanks to your detailed account of the problem, I was able to replicate it. Context conditions don't support negative conditions based on contexts which depend on a context condition. In your case, context A is not active based on whether context B is active. The way contexts are processed, the default context condition is processed in the same pass as context A so it doesn't see A as active so that its activation is blocked. Once a context has been deemed active there is no support for deactivating it.
A way to get around this may be to reduce the level of dependencies on context condition. One way would be instead of A having a context condition, it could have a negative path condition, such as ~sectionA/sectionB and ~sectionA/sectionB/*.
If you (or someone else) would like to work on a patch to allow this support an option to investigate for development would be to create a mechanism for contexts to deactivate based on the context condition as well as adding a check for potential infinite that could now exist during the reprocessing of context conditions when the set of active contexts change.
In the mean time, this should be noted in the help field under the context condition. I'll be sure to write a patch to add that later.
#2
Here's a patch to add a note about contexts that depend on other negative contexts. It just adds the following to the help dialogue:
"Contexts with negative conditionals that depend on other contexts with negative conditionals will be processed at the same time, and therefore will not work."
It's a little wordy for a help dialogue, but this should be documented somewhere.
#3
Documentation clarified in commit bd449f42ea5cc99cfd4c7d5aec582c4526bfd28d thanks for the bug report and the patch
#4
Automatically closed -- issue fixed for 2 weeks with no activity.