During an import secondary writes or deletes of configuration through hook implementations or event listeners are impossible to prevent. Raising an exception or silently failing both have completely unpredictable outcomes because the hook and event system make it impossible to completely lock down the config system in this way during an configuration import.
Our general approach is to let the secondary writes happen, then try to clean up afterwords in import-specific code. We will also try to complete the config import, rather than blowing up - we are guessing that this will lead to less broken sites than stopping half-way through an import.
List of scenarios and ways we will handle it below:
- create config that already exists: this will just blow up, and is a bug the module author needs to fix
- create config doesn't already exist, there are two scenarios
- the config that was created exists in the source tree, so we will do a delete/create so that the config object looks like source
- the config that was created doesn't exist in the source tree. we have two options, and are not decided yet. a) we clean up and delete the newly created object, so that the target tree looks like the source, or b) we don't do anything, so that the code that created the new entity doesn't break
- delete config that has already been deleted - in this case we should do nothing.
- delete config that exists in the source tree - we will try to fix this up by doing a create, so that the target tree looks like source. however, this is possibly already too late
will explore if there is anyway we can report these events to the user.
User interface changes
Original report by @username
In Prague, it was determined that the import (create/update/delete) of a config entity through the config import process should not trigger secondary config writes (e.g: auto-creation of body field on creation of a new node type). During config import, the set of imported config files should be the only source.
The issue linked above added an "isSyncing" flag on config entities to allow the entity CUD callstack (preSave/postSave, preDelete/postDelete, hook_entity_OP()) to determine whether secondary config changes can be triggered.
It was also agreed to have the config system enforce this behavior by raising an exception when some code tries to write to config while a config entity is being processed (like we prevent hook invocations in updates - otherwise, isSyncing is just too easy to overlook). However, doing so means fixing all the places in core that currently do that, so this was deferred to a followup.
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 67,683 pass(es). View
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 67,738 pass(es). View