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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

That's pretty cool

+++ b/core/modules/views/views_ui/lib/Drupal/views_ui/Form/SettingsFormBase.phpundefined
@@ -29,10 +29,20 @@
+    config_context_enter('config.context.free');

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 ?

dawehner’s picture

Status: Reviewed & tested by the community » Needs review

Ups.

damiankloip’s picture

Well 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.

damiankloip’s picture

Issue tags: -VDC

Status: Needs review » Needs work
Issue tags: +VDC

The last submitted patch, d8.views-ui-config-context-settings.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
FileSize
3.34 KB

rerolled

damiankloip’s picture

Forget that reroll.

Status: Needs review » Needs work

The last submitted patch, 1932336-6.patch, failed testing.

damiankloip’s picture

Title: Use override free configuration context for views_ui settings forms » Use override free configuration context for SystemConfigFormBase
Status: Needs work » Needs review
FileSize
1.36 KB

Let'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.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Oh nice! I'm wondering whether this should be tested? For example by just checking the value of the value on the object.

tim.plunkett’s picture

This is great. It really makes it easier for implementors.

webchick’s picture

Component: views_ui.module » system.module
Status: Reviewed & tested by the community » Fixed
Issue tags: +Configuration system

This looks like useful information indeed for all settings forms to have.

Committed and pushed to 8.x. Thanks!

Gábor Hojtsy’s picture

Issue tags: +D8MI, +language-config

Woot :) Retroactively tagging for config language.

sun’s picture

Issue tags: -D8MI, -language-config

You'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?

tim.plunkett’s picture

You'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.

Automatically closed -- issue fixed for 2 weeks with no activity.