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.
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.