The various "X as plugins" efforts that are or will be started here and there will for a very large number need to handle the notion of 'settings'. Within core only, this applies to blocksTNG, field widgets, field formatters, field types, image styles, image toolkits, text filters, ... you name it.
Most plugin-like subsystems in core or contrib have their own formulation currently, with widely different or incomplete or similar-but-subtly-varying implementations. I see much value in trying to come up with some a 'standard' core way of handling this, especially given some aspects of it are not so trivial.
I pitched the idea to EclipseGc during his SCOTCH talk at DCMunich, the idea appealed to him.
I see a very common use case on top of the following pattern.
A Plugin (of a given plugin type) has :
- A set of properties that is common to all plugins of this type. They're what the given subsystem expects just to be able to work with a various and "unknown" collection of different implementations. Typically, they're the parameters that the factory used by the plugin type passes to instanciated plugin objects.
- A collection of 'settings', which are specific to each plugin implementation.
'image_crop' has 'width', 'length'; 'image_rotate' has 'rotation'; 'ilmage_grayscale' has none
Handling those 'settings' in a different namespace than the 'fixed properties' is important, because if you don't, you'll find your subsystem cannot add a new 'fixed property' and be sure it won't clash with a setting name used by a random 3rd party plugin implementation (and requiring implementations to prefix by module name is really cumbersome/ugly when it comes to settings names).
The collection of 'settings' is usually exposed in a 'settings' entry in the 'plugin definition format' (whether hook- or annotation-based) defined by the plugin type, and come with metadata :
- Machine name
- Default value
Providing default values lets you populate a 'create' form, and also ensures you can add more settings in a point release without littering your code with isset()s to handle existing definitions where the setting didn't exist yet. But filling in default values upfront on any instanciated object can be costly.
- Translatable flag
This will be needed for "CMI / i18n" - see
- ... ?