We currently store all the settings for all processors, even the disabled ones, and because of the "Fields to run on" option and its current storage, this can become rather lengthy, making the YAML file more or less unreadable. So, a few suggestions:

  • Almost definitely: Fix the FieldsProcessorPluginBase class to only store the enabled fields, not also [KEY] => 0 mappings for the disabled ones. Also, just storing a numeric array for the enabled fields and transforming that to an associative array upon processor construction should be sufficient and would also make this look a lot nicer.
  • Then, do we need the settings of disabled processors? In 90% of the time, they will just be the defaults, and in most other cases it won't matter much if we just discard the changes. If we do think that we should keep user changes here, maybe just comparing the submitted values to the defaults and only saving those values that got changed would make sense? (This could even be also done for the enabled processors, if we are fairly sure the defaults won't change normally.)

Comments

drunken monkey’s picture

Just a note that the first part was fixed in the sandbox.
Also, since I think core's plugin bags work the same, I think we definitely should also implement the second, i.e., only store the settings for enabled processors.

Nick_vh’s picture

"Almost definitely: Fix the FieldsProcessorPluginBase class to only store the enabled fields, not also [KEY] => 0 mappings for the disabled ones. Also, just storing a numeric array for the enabled fields and transforming that to an associative array upon processor construction should be sufficient and would also make this look a lot nicer."

This would also fix the silly config schema bug where 0 is recognized as integer and the checkboxes that are set are recognized as strings so you have to put type "ignore" to validate it. So yes, only saving what is actually important is already a good step forward. Thanks for fixing that already.

I don't think we need the settings of disabled processors. In line with Drupal 8, there is no such thing as disabled modules so I think it's fair to say that if you disable a processor you lose the settings. That also avoids issues where a field would be removed but it's still available in the disabled setting and causing all kind of weird edge cases

drunken monkey’s picture

OK, it seems I was mistaken, a quick look shows that the first part wasn't implemented yet, we still have a very ugly export of the fields settings. What I fixed was the same thing in "Aggregated fields".
However, this can easily be fixed in two steps, or even two separate issues.

drunken monkey’s picture

Status: Active » Closed (duplicate)