Sounds like something that's either a partial split for that specific configuration for each of your three sites/splits, or a task via config_ignore → .
All concerns from @mxr576 have been addressed and the MR got updated accordingly.
Fixed the test failure on the MR.
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.
The MR is the same as the patch in #3, and works well with 1.4.6.
Checked the report from @rprager in #6 but I could not reproduce it (using the latest 1.4.x branch, which corresponds to the 1.4.6 version as of now): I have created a node and used CKEditor to upload an image to its body, then exported the node. The only log entry I got was about node creation, and the resulting zip did contain the image I have uploaded via CKEditor.
So I have converted the patch in #2 into a merge request as-is.
Okay, I think I (also) missed the fact I was using the patch from #2868252-32: Consider adding a hook to Paragraphs::getSummary → . If I upgrade the module to 1.17 and the patch to #2868252-46: Consider adding a hook to Paragraphs::getSummary → , my errors are gone.
So, is this possible that this issue could be closed as a duplicate of that other one? Because the 1.17 codebase doesn't even have event dispatching in it at all…
The problem is also present with 8.x-1.16.
Sorry, but this only affects SQL-based entity types. I think entity queries for remote entities (like the ones in the Apigee Edge module → ) should also be supported (and the entity.api.php changes also suggest this).
In cases of drupal/core:10.1.8 with drupal/config_split:1.9.0, drupal/config_filter:1.12.0 was used, because that's the latest version of it anyway, and drupal/config_split:1.9.0 depends on drupal/config_filter:^1.
Update MR helps getting rid of error messages. However, this does not make config_split_ignore working with config_ignore:3.2. ATM, I think the reason is that \Drupal\config_split_ignore\Plugin\ConfigFilter\ConfigSplitIgnoreFilter::create() is not even called with config_ignore:3.2 – and this might be exactly the same reason that was mentioned in
#3413717-6: Error: Class "Drupal\config_ignore\Plugin\ConfigFilter\IgnoreFilter" not found →
.
Boobaa → made their first commit to this issue’s fork.
The attached patch adds a single_content_sync_revisions submodule, which adds this feature.
@mxr576: While your comment is asking a proper question, it does not belong to this particular patch/issue. The race condition you mentioned is also present without this patch, as this user-specific but shared storage is also used elsewhere already during the export process. Because of that, I think a different issue should handle that problem – if at all, because I also think that this is quite a corner case: I just cannot really imagine myself executing another export while the first one also started by myself is still running. IOW, this is theoretically possible for sure, but practically? I'm not that sure.
Attached is a patch that solves the problem of importing images into the private FS; pretty much the same approach, but also contains tests.
Attached patch provides this feature, based on already-existing examples.
Boobaa → made their first commit to this issue’s fork.
The idea of dropping the need of the way-too-generic view all revisions permission for having access to those files is a good direction. However, the patch in #150 still mentions this permission (tho only in the tests, so they might have became irrelevant/outdated by now), meaning this definitely Needs work.
Regarding FileAccessControlHandler::checkAccess(), I'm not sure the "view" operation is the one that should be used. Can we please consider the "view revision" operation instead, at least for the $referencing_entity->access() for revisionable entities? There might be cases when one does have "view" access to the entity, but does NOT have "view revision" access to the revision that has the file attached.
Thank you, added you as a maintainer.