I first noticed this because any
DisplayInterface-implementing subclass of
ConfigEntityBase wasn't saving correctly. We were running into this over in .
The problem is that they use a mix of public and protected properties, and
ConfigStorageController::getProperties() assumes that only public properties are of interest.
My initial approach was to:
- Introduce a
DisplayInterface::export()that each Display class could use to determine which of its own properties to export.
- Introduce a
DisplayStorageControllerclass that would interact with the above method.
Then, I realized this should be entirely generally applicable - we just shift the logic from
ConfigEntityBase::export(), and we're good to go. This should be completely transparent to other config entities.
Marking this major and a bug report because, without this fix, Displays CANNOT save properly. It's maybe better scoped as a task to do it at the generic level, but if it doesn't mess with any other config entities (as I'm hoping), then we can just evaluate it in the context of Displays.
User interface changes
ConfigEntityBase children could use this if they wanted to, but the change SHOULD be entirely transparent to them. Testbot will tell.
PASSED: [[SimpleTest]]: [MySQL] 49,245 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] 48,578 pass(es), 455 fail(s), and 174 exception(s). View
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. View