Drupal Association members fund grants that make connections all over the world.
Entities tend to get serialized in various places : cache, forms...
ConfigEntities, being more business oriented, additionally tend to get more business specific helper methods, possibly relying on internal properties / derived data / external services, other than their raw data, and which you usually don't want to serialize.
Nice thing is, ConfigEntities have a pretty straightforward serialization format: the exported properties that end up in their CMI file...
We had to do this for Field / FieldInstance entities, that fall exactly in this case above, but the code is pretty agnostic and might make sense for all ConfigEntity types.
(since then, duplicated that same code in EntityFormDisplay - leaving the symmetrical EntityViewDisplay out).
Basically, serialize to the raw array returned by getExportProperties() (as if it was going to CMI), and unserialize by passing this array to __construct() (just as if it was read from config). Same format, different storage.
Patch once I get a node id.
|#72||1977206-config-entity-serialization-71.patch||22.34 KB||Cameron Tod|
|#70||1977206-config-entity-serialization-70.patch||25.35 KB||Cameron Tod|
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 97,779 pass(es), 106 fail(s), and 133 exception(s). View