Coming from #2124535: Prevent secondary configuration creates and deletes from breaking the ConfigImporter, though I think this was actually introduced in another issue originally.
That patch added a lot of lines like this:
+++ b/core/modules/image/image.module
@@ -387,6 +387,10 @@ function image_entity_presave(EntityInterface $entity) {
+ if ($field->isSyncing()) {
+ return;
+ }
This requires module developers to a) know about this method, b) know they're supposed to check it, c) know exactly when/why to do so. This would be a lot easier to communicate if it were an argument in the hook itself, because then we could just document it.
Thoughts?
Comments
Comment #1
yched commentedFinding a way to make the existence & importance of the isSyncing() flag more obvious to folks interacting with config entity CRUD has been a concern for the past months, yes.
And yes, adding it as a param to the hook would be a great way,
BUT the hooks are shared with content entities for which this notion doesn't exist.
We could choose to simply omit the param for hook_[ENTITY_TYPE]_[CRUD]() implementation for content entities, but this still leaves a high chance of people copy/pasting the wrong ones and ovelooking the $is_syncing thing completely.
In short, yep, +[a lot] on the problem description, but I don't really have new insight on the solution :-/
Comment #2
sunA "synchronization" also exists for content entities, as soon as someone/anyone develops a working mechanism to stage/deploy content across sites.
What we're doing with config right now is merely a one-off "experiment of how staging could possibly work out." — Once the design works, it's going to be boilerplate.
Meanwhile, contrib will try to make the impossible possible. Contrib will need this parameter, in the same way as core needs it for config.
→ No reason to limit this to config entities. Let's forget about that concern.
It's not about config vs. content. It's about staging.
Comment #3
yched commented@sun: possibly, but note that the isSyncing() flag only has meaning because config sync is a "full sync" of the complete config tree - hence the need to avoid secondary writes reacting to an entity write, that will overwrite or get overwritten as the sync process progresses.
Even if content entities get some level of deployability some day, it's not sure the challenges and constraints will map.
Comment #4
sunCorrect. Any attempt to stage content entities is guaranteed to run into the exact same problem of secondary writes.
While being there, let's change the name, please... "isSyncing" is 100% ambiguous — Does it sync the save? Sync the database? Sync the original user input? Oh, does it explicitly sync secondary writes? :P What does it sync? ;-)
Comment #5
yched commentedYeah, it means the entity is being synced, actually.
Comment #6
xjmComment #20
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #21
berdirWe have \Drupal\Core\Entity\SynchronizableInterface since 2018 which is exactly this.