Problem/Motivation

Two issues have come up which there seems to be general consensus that SynchronizableInterface is appropriate for:

Questions have been raised on the appropriateness of the interface, so there should be some better docs describing what it's for and what users can expect by using it.

Proposed resolution

Add docs to the interface.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
#2 3057483-2.patch1.49 KBSam152
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sam152 created an issue. See original summary.

Sam152’s picture

Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commented
Title: Better describe how SynchronizableInterface should be used for content entities » [PP-2] Better describe how SynchronizableInterface should be used for content entities
Issue summary: View changes
Status: Active » Needs review
FileSize
3057483-2.patch1.49 KB

I think it makes sense to block behind the other two issues, since they are used as examples here.

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented

Thanks for opening this, I think this is a great idea.

Some notes:

  1. +++ b/core/lib/Drupal/Core/Entity/SynchronizableInterface.php
@@ -40,6 +40,21 @@ public function setSyncing($status);
+   * as clicking save on an entity form. For example an entity may be marked as

    I think we should add something "... or a POST or PATCH request via JSON API." or something like that otherwise I think people could incorrectly put that example in the "synchronizing example, as well. 

  2. +++ b/core/lib/Drupal/Core/Entity/SynchronizableInterface.php
@@ -40,6 +40,21 @@ public function setSyncing($status);
+   *  - Content integrity issues are being resolved in previous revisions of an
+   *    entity.
+   *  - Content changes being made to an entity after a standard content update,
+   *    for example: syncing translations from an external system to a specific
+   *    content revision.

    I think those should be explained in further details, if we want to have them as examples. At the very least I don't really understand what the use-case or concrete example is there.

    Also what about the migration example? I think that actually fits quite well (as you yourself noted in that issue, as well).

Sam152’s picture

Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commented

Actually, I think a better real world example might be in core: media updating queued thumbnails: #2987911: Make media compatible with content moderation:

Content moderation should provide an API for skipping new-revision creation for subsystems that require updating metadata.

Sam152’s picture

Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commented
Status: Needs review » Needs work

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

kristiaanvandeneynde’s picture

kristiaanvandeneynde
Primary language Dutch
Location Antwerp, Belgium
CreditAttribution: kristiaanvandeneynde at Factorial GmbH commented

I am currently facing this issue in the Group module where I feel I have to reject a patch that sets content entities to syncing because the interface specifically points out this is mainly about data imports (config import, migrate, ...): #2872697: Node update hook is triggered upon group content create

They are correctly figuring out that workspaces will not create a new revision on syncing content and therefore set the flag to prevent that from happening. It would be cool if we kept this flag (isSyncing) for the intended purpose as documented on the interface, but also introduce a new flag that can only be checked for updates: isInternalUpdate.

When this flag is set you could also choose not to create a revision, but at least you'd have the choice to differentiate between imported content and content that was (updated with internal data only. Either way, I think it's dangerous to repurpose an existing interface as you cannot know what contrib has already done with it.

So maybe leave SynchronizableInterface as is, but come up with a new interface for internal data changes such as metadata, certain flags, adding something to a group, updating nested set values (left and right), ...

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.