Support exporting/importing revisions

The attached patch adds a single_content_sync_revisions submodule, which adds this feature.

Reviewed patch #2 and works fine with version 1.4. Please refer screenshot
Step:
Created a node with multiple revisions.
Exported the node.
Result: All revisions are exported now.

Hi Boobaa,

Thank you for your effort!
A few thoughts here.

1) We definitely don't want to have accessCheck(FALSE). The current user may not have permissions to view all revisions; this code will give them read access. This is a security/data disclosure issue.

2) The core version requirement should be core_version_requirement: ^9.3 || ^10, same as in root info.yml.

3) The following line will produce a warning if there are no revisions in YML file:
if ($content['revisions']) {

4) The revision creation time should be import/exported the same way we do for created/changed timestamps.

5) We'd likely need a test for this; also, please create the merge request to run automated tests.

Thanks!

Hi,
I have tried to using this patch it is getting exported with revision but as I a paragraph field when i am import it i am getting as
Call to undefined method Drupal\paragraphs\Entity\Paragraph::setRevisionCreationTime() in Drupal\single_content_sync_revisions\ImportSubscriber->onImportEvent() (line 52 )... please look to this issue as well

1) We definitely don't want to have accessCheck(FALSE).

Fixed.

2) The core version requirement should be core_version_requirement: ^9.3 || ^10, same as in root info.yml.

Fixed.

3) The following line will produce a warning if there are no revisions in YML file:
if ($content['revisions']) {

Fixed.

4) The revision creation time should be import/exported the same way we do for created/changed timestamps.

The revision creation time is imported the same way it is done for the created/changed timestamps: although the exported zip only contain the created data, the current timestamp is used during the import. Changed timestamps are completely ignored, even during export. Please refer to ContentImporter::doImport().

5) We'd likely need a test for this; also, please create the merge request to run automated tests.

Tests to be written in a later phase.

I have tried to using this patch it is getting exported with revision but as I a paragraph field when i am import it i am getting as
Call to undefined method Drupal\paragraphs\Entity\Paragraph::setRevisionCreationTime() in Drupal\single_content_sync_revisions\ImportSubscriber->onImportEvent() (line 52 )...

Thank you for reporting this; turns out Paragraph entities do not have proper revisioning support: as Paragraph items are referenced not only by their entity ID, but also their revision ID, and revisions do not have UUIDs, there is no way to properly import references to Paragraphs' revisions. Because of that, even exporting Paragraph revisions is useless.

Note this also means that the parent entity (eg. node) might have its revisions exported, but ALL those revisions would have the same content in the paragraph fields' revisions: the one belonging to the latest revision. Other, non-paragraph fields of the parent have proper revisioned content.

Therefore the MR just skips Paragraph revisions, even during export.

(It looks like UUID vs revisioning supported is tracked under this Drupal core issue: ✨ Add UUID support for entity revisions Needs work . Bumped that with a quote from comment 9.)

Tests to be written in a later phase.

But still in this issue, am I right?

All concerns from @mxr576 have been addressed and the MR got updated accordingly.

I have a content type with 150+ custom fields and some nodes that have dozens of revisions.
When loading revisions when exporting, this causes memory issues and also a long time to export.

Changing this (in modules/single_content_sync_revisions/src/ExportSubscriber.php):

      // Second step is exporting those revisions.
      /** @var \Drupal\Core\Entity\ContentEntityInterface $revision */
      foreach ($storage->loadMultipleRevisions($revision_ids) as $revision) {

to:

      // Second step is exporting those revisions.
      foreach ($revision_ids as $revision_id) {
        /** @var \Drupal\Core\Entity\ContentEntityInterface $revision */
        $revision = $storage->loadRevision($revision_id);

solves the memory issues and makes the process much faster.

Good catch and regular issue, although the fix leads to the infamous N+1 problem of ORMs

I would rather recommend implementing something like I did in an other module, load multiple with a maximum amount:

https://git.drupalcode.org/project/view_usernames_node_author/-/blob/1.0...

(tricks like this is necessary until a stable solution lands in Core for #2577417)