Block Remains Visible on Homepage When Associated 'Context (All)' Is Disabled

@willemviljoen, fix the issue and created Patch. please kindly review patch file

Claude Code says:

The Change

In the required contexts loop of ContextAll::evaluate():

- Original: if (!evaluate() && !disabled()) → fail
- Patched: if (!evaluate() || disabled()) → fail

Behavioral Difference

Let me walk through the truth table:

  ┌─────────────────┬───────────┬───────────────┬──────────────┐
  │ Conditions met? │ Disabled? │ Original (&&) │ Patched (||) │
  ├─────────────────┼───────────┼───────────────┼──────────────┤
  │ Yes             │ No        │ pass          │ pass         │
  ├─────────────────┼───────────┼───────────────┼──────────────┤
  │ Yes             │ Yes       │ pass          │ FAIL         │
  ├─────────────────┼───────────┼───────────────┼──────────────┤
  │ No              │ No        │ fail          │ fail         │
  ├─────────────────┼───────────┼───────────────┼──────────────┤
  │ No              │ Yes       │ pass          │ FAIL         │
  └─────────────────┴───────────┴───────────────┴──────────────┘

The key change: disabled contexts now cause "all" to fail, whereas before they were silently skipped (treated as "don't care").

Concerns

1. Changes the meaning of "disabled"

The original logic across the entire plugin treats disabled as "invisible" — a disabled context is excluded from evaluation entirely. This is consistent across all three context types in this method:

- Negated (line 150): evaluate() && !disabled() — a disabled negated context can't trigger a negation
- Wildcard (line 173): !evaluate() && !disabled() — a disabled wildcard context can't cause failure
- Required (line 164, original): !evaluate() && !disabled() — a disabled required context can't cause failure

The patch breaks this consistency — negated and wildcard contexts still skip disabled contexts, but required contexts now fail on them.

2. Inconsistent with ContextAny

In ContextAny::evaluate(), the required contexts logic is:

  if ($this->contextManager->evaluateContextConditions($required_context) && !$required_context->disabled()) {
      return TRUE;
  }

A disabled context can't satisfy "any." But it also can't prevent "any" from being satisfied — it's just skipped. The patch would make ContextAll treat disabled contexts as actively failing, while ContextAny treats them as passively skipped. That's an asymmetry that would be confusing.

3. Cascading breakage from disabling a context

With the original code, an admin can temporarily disable a context without worrying about breaking other contexts that reference it in an "all" condition. The patch means disabling context B would silently break any "Context (all)" condition that lists B — with no UI feedback explaining why.

Summary

I'd recommend not merging this patch. While it's arguable that "a disabled context isn't active, so 'all' can't be satisfied" is logically correct in isolation, it breaks consistency with how disabled contexts are handled everywhere else in both ContextAll and ContextAny (as invisible/skipped), and introduces a cascading side effect from disabling contexts. If the intent is to change the semantics of "disabled," it should be done uniformly across all three context types in both plugins, with clear documentation of the new behavior.