Problem/Motivation
The baloney.spam condition plugin provides no configuration schema, and its name should not contain a dot.
Proposed resolution
- Rename the plugin ID to
plugin_baloney. - Provide a configuration schema for the plugin.
- Provide a fallback schema for condition plugins that have no configuration.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Data model changes
None.
Beta phase evaluation
| Issue category | Bug, because its a missing config schema on tests, so some tests cannot be written. |
|---|---|
| Issue priority | Normal, because it doesn't affect anything on runtime. |
| Disruption | No disruption, just test changes. |
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | drupal_2547581_18.patch | 2.82 KB | xano |
| #18 | interdiff.txt | 400 bytes | xano |
Comments
Comment #2
xanoThese bugs were discovered due to test failures in #2537732: PluginFormInterface must have access to the complete $form_state (introduce SubFormState for embedded forms). I'm not sure why this hasn't failed before, or how this should be tested.
Comment #3
berdirremove this again?
Comment #4
xanoWhy? It's a bit silly to require plugins without configuration to provide a schema.
Comment #5
berdirit's pretty common practice, because it forces them to think about it.
If anything, then make it type: mapping, so they need to do it if they have config. But ignore ignores everything.
Comment #6
xanoComment #8
xanoThat was the first patch, for which I cancelled testing.
Comment #10
xanoComment #11
xanoBumping this to critical, since #2528178: Provide an upgrade path for blocks context IDs #2354889 (context manager) was a critical and this issue adds what that one should have added.
Comment #12
dawehnerThis is a test, I can't see on earth why this is critical, sorry.
Comment #13
xanoExactly. It's a test. If we can't trust those, then how do we know if the other issue was successfully fixed?
Anyway, I trust you can judge this better than I can. See you in the sprint room for coffee? ;-)
Comment #14
dawehnerI think the patch itself is alright.
This seems to be a little bit out of scope to just fix the issue, but having it, can't be bad.
Comment #15
alexpottThis already exists...
Comment #16
alexpottAnd this is not even using the
condition.plugin.*added by the patch. So I guess thecondition.plugin.*definition was left in by mistake.Comment #17
xanocondition.plugin.*was added as an intended fallback for plugins not providing their own config schemas. Was I wrong in assumingcondition.plugincannot be used as a fallback because it contains no asterisk?What does
condition.plugineven describe? It's not defined as a config entity schema, but it contains a UUID and other schemas for configuration that does not show up inConditionPluginBase.Comment #18
xanoSeveral reviewers found the fallback schema redundant, so I removed it.
condition.pluginis a mess anyway (unnecessarily merged plugin ID and plugin configuration, schemas for non-existing properties), so let's clean that up in a follow-up.Comment #20
dawehnerThank you for keeping the patch in scope!
Comment #21
webchickCommitted and pushed to 8.0.x. Thanks!