Ran into an issue with sites that have the Domain Access module installed. Domain Access has an entity reference field that targets the domain config entity. When you clone a node you get the choice to automatically clone the target config entity (in this case domain records) for the Domain Access field. This seems to be the kind of thing you would only want do with very careful consideration.

Given that the Entity Clone settings form purposefully excludes Config Entities, seems like a bad idea to allow a user to clone the target config entities.

Patch attached here. This patch will skip over Entity Reference field that are targeting Config Entities when the clone tab is visited on an entity.

CommentFileSizeAuthor
#9 entity_clone-clone_config_entity-3037470-9.patch2.92 KBvpeltot
#6 entity_clone-clone_config_entity-3037470-6.patch1.58 KBpdenooijer
#4 entity_clone-clone_config_entity-3037470-4.patch1.43 KBmcgettrs
clone-config-entity-2694133.patch1.13 KBbigjim

Comments

bigjim created an issue. See original summary.

pdenooijer’s picture

pdenooijer commented
Status: Active » Reviewed & tested by the community

Works like a charm!

Status: Reviewed & tested by the community » Needs work

The last submitted patch, clone-config-entity-2694133.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

mcgettrs’s picture

mcgettrs commented
StatusFileSize
new entity_clone-clone_config_entity-3037470-4.patch1.43 KB

The current patch appears to break entity clone for nodes with nested entities like paragraphs. With this patch 1 installed the paragraph entities were not getting cloned at all. The original and cloned node then have references to the same paragraphs.

The patch appears to be missing a use statement.
use Drupal\Core\Entity\ContentEntityTypeInterface;
This is causing entity clone to hit the 'continue' on every iteration of the for loop. I have attached a patch that includes this use statement and it appears to fix the non cloning issue for me

pdenooijer’s picture

pdenooijer commented
Status: Needs work » Reviewed & tested by the community

Argh that I missed the use statement. Tested this patch with xdebug and it works like it should. Does not blow up on config entities and does clone nested content entities.

pdenooijer’s picture

pdenooijer commented
Status: Reviewed & tested by the community » Needs review
StatusFileSize
new entity_clone-clone_config_entity-3037470-6.patch1.58 KB

Found an even better solution, this will filter out all unknown types. Bonus of this patch is that it will make sure very big entities will not run out of memory if you only deep clone a limited set of entity types. Had to update the default EntityCloneSettingsManager::getHiddenValue() to TRUE to make sure unknown types don't blow up the form.

Please have a look at the patch.

laravz’s picture

laravz commented 
+++ b/src/EntityCloneSettingsManager.php
@@ -143,7 +143,7 @@ class EntityCloneSettingsManager {
+    return TRUE;

You could replace this with "return $form_settings[$entity_type_id]['hidden'] ?? TRUE" since php 7 has to be used now

Though it looks fine to me in general and the patch has been working successfully in our setup.

laravz’s picture

laravz commented
Status: Needs review » Reviewed & tested by the community
vpeltot’s picture

vpeltot commented
StatusFileSize
new entity_clone-clone_config_entity-3037470-9.patch2.92 KB

I prefer the patch #4 approach.

Rather than using the clone settings to know if we can clone a reference or not (here ConfigEntity), IMHO it is necessary to be more basic and not authorize the recursive clone of the config entity referenced in a content entity.

@pdenooijer
To avoid memory limit when cloning a big entity containing a lot of child entities, this issue #3010626: Sub-entity cloning has unnecessary recursion for form causing memory issues cover this bug.

  • vpeltot committed 6f53782 on 8.x-1.x 
    Issue #3037470 by bigjim, mcgettrs, vpeltot: Clone form attempts to...
vpeltot’s picture

vpeltot commented
Status: Reviewed & tested by the community » Fixed

Commited !
Thanks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.