Condition plugins: two on the same form? I'm working on porting the CAS module to Drupal 8. On the main configuration form, users can list paths that will activate a feature of the module.

I read about using the new condition API recently, which has a condition for matching request paths, and decided to try and incorporate it into the module settings since it seems perfect for what I'm doing.

On the form submit handler, I have code like:

$this-&gt;myPathCondition-&gt;submitConfigurationForm($form, $form_state);


And the actual submitConfigurationForm code from the RequestPath class looks like this:

public function submitConfigurationForm(array &amp;$form, array &amp;$form_state) {
  $this-&gt;configuration['pages'] = $form_state['values']['pages'];
  parent::submitConfigurationForm($form, $form_state);
}


Couple problems though:


I have two instances of the condition plugin, so they would trip over each other in the form submission
For that reason, I would typically "namespace" each to a section, like: $form_state['values']['forced_login']['paths']


But since the condition plugin looks at a specific array structure for the value, this won't work. This appears to be a limitation of the plugin, but perhaps there's a reason for this, or a method around it? 

I understand D8 isn't even in beta yet, but I didn't want to comment on the closed issue where this was implemented: https://www.drupal.org/node/1921544
You are responsible for only passing a sub-key of the form to each plugin configuration method.

Have a look at BlockBase::buildConfigurationForm() and the corresponding validate and submit methods. Note that this itself is already a partial form of BlockForm::form().

For a more flexible approach, have a look at https://drupal.org/project/page_manager, which has an UI that allows to add conditions and configure them in separate forms, but those forms also pass only a part of the form to those methods.

The main advantage of the page_manager approach is that BlockBase only works in a useful way with condition plugins that have a no-op mode, meaning, that you can configure them so they don't do anything (and that is the default configuration) because all condition configurations are saved and all plugins are invoked.

Yes, this is sometimes limiting and inconsistent, but that's how it works and I don't really have an idea to improve it...