Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Now that we have an override free config context available, we should use this on views ui settings forms so that we only load and save 'pure' context, and no overrides bleed into the actual stored configuration files.
We can add this to our form base class so both inherit this behaviour.
Comment | File | Size | Author |
---|---|---|---|
#9 | 1932336-8.patch | 1.36 KB | damiankloip |
#6 | 1932336-6.patch | 3.34 KB | damiankloip |
d8.views-ui-config-context-settings.patch | 2.65 KB | damiankloip | |
Comments
Comment #1
dawehnerThat's pretty cool
So all other places in core activate the context on the form and on the submit function, why aren't we doing the same in the SystemConfigFormBase ?
Comment #2
dawehnerUps.
Comment #3
damiankloip CreditAttribution: damiankloip commentedWell I think most of the other forms load the config when building the form. We get the config in the constructor of the form then use it. So then the loaded confug will use that context.
Comment #4
damiankloip CreditAttribution: damiankloip commentedd8.views-ui-config-context-settings.patch queued for re-testing.
Comment #6
damiankloip CreditAttribution: damiankloip commentedrerolled
Comment #7
damiankloip CreditAttribution: damiankloip commentedForget that reroll.
Comment #9
damiankloip CreditAttribution: damiankloip commentedLet's go straight to source and do this on the base class, plus it makes the patch alot smaller!
I would have liked to add a quick test to Drupal\system\Tests\Form\SystemConfigFormTest but you can't override $conf in web tests. I have tested this by adding overrides in settings.php and it works nicely.
Comment #10
dawehnerOh nice! I'm wondering whether this should be tested? For example by just checking the value of the value on the object.
Comment #11
tim.plunkettThis is great. It really makes it easier for implementors.
Comment #12
webchickThis looks like useful information indeed for all settings forms to have.
Committed and pushed to 8.x. Thanks!
Comment #13
Gábor HojtsyWoot :) Retroactively tagging for config language.
Comment #14
sunYou've globally force-disabled any kind of context for any kind of configuration/settings form here.
This means that all code is unilaterally enforcing no context for all of these forms.
Even if you instantiate these forms for a specific context, the forms will reset the context to nothing.
Context-specific handlers are not able to skip or override that decision, since you applied it to the very base class for all configuration forms. PHP does not support mixins. Thus, the context can only be revert-reverted on a form-specific basis, by overriding the form class being used at appropriate layers, individually, for each specific form.
Is that really what you intended to do?
Comment #15
tim.plunkettYou're only locked into that context if you use the create() method that is provided for your convenience. You'll notice that the constructor only dictates that it needs *a* context, not *which* context.