Implement ThirdPartySettingsInterface in ImageStyle

Yes, the base implementation of getExportProperties() only picks up public properties, and all of the overridden implementations call that and then loop through a specific set of protected properties.

FilterFormat and ImageStyle are unique in that they call actual methods in there, to get their plugin configuration.

Assuming this is a behavior we want to continue supporting, this is a bug.

I can see 2 solutions:

1. Invoking an alter hook from getExportProperties() and pass the entity (so that hook implementations will know the source) and properties list to be altered
2. More straight (not necessary more elegant) . Adding a public property in ConfigEntityBase (as 'status' is now), acting like storage and initialized to an empty array. Modules can read/write/delete data from that storage. Being public will always be saved and restored.

So how do we make this work with the config schema's then ?

This feels like a won't fix to me, and personally I've always felt that using hook_schema_alter() was tantamount to hacking core. We have made the explicit decision not to implement alters anywhere in the configuration chain. I'm not a fan of creating a dumping ground for random configuration either. There is a solution now, it is solid architecturally. This seems like a won't fix.

I only partially agree with @heyrocker, on hook_schema_alter(), but I disagree on "won't fix". Configurables should allow contrib modules to add new properties without extending the class. If 2 modules will need to add new properties to the same configurable, extending the class is not a solution.

As #1497374: Switch from Field-based storage to Entity-based storage is now in, we can take into consideration next approach:

• Allow configurables to be fieldable as there are also entities.
• Wait! I'm not referring to Field UI or providing UI fields like field_*.
• New fields should be provided by modules, in code (typed data, schema, so on...).
• The entity storage controller to use the same storage for fields as the main configurable (YAML, etc.)

After #2256679: Use config schema to determine which config entity properties to export regardless of whether they are public or protected went in, the schema wins out here.

I've already had needs for extending the schema from contrib in page_manager, that could be the way forward.

Looks good. One comment.

+++ b/core/modules/image/src/Entity/ImageStyle.php
@@ -48,7 +50,9 @@
-class ImageStyle extends ConfigEntityBase implements ImageStyleInterface, EntityWithPluginBagsInterface {
+class ImageStyle extends ConfigEntityBase implements ImageStyleInterface, EntityWithPluginBagsInterface, ThirdPartySettingsInterface {
+
+  use ThirdPartySettingsTrait;
 

Let's make ImageStyleInterface extend ThirdPartySettingsIntefrace instead extending it directly.

RTBC if green.

Do we need some more tests that this actually works? We can see that it shows up in the schema, so that's good. We're almost only just re-using standard functionality now, so I'm not sure.

Maybe just add or extend a kernel test that creates an image style with the API, adds a third party setting, saves and loads it again?

In #2324121: NodeType's settings array was meant to be able to store information from mutliple modules, we have an actual use case for this that I was able to convert.

Looks good to me.

Committed 73b0592 and pushed to 8.0.x. Thanks!