Clone form is not respecting 'cloneable_entities' config resulting in memory limit on recursive in ContentEntityCloneFormBase for a custom Entity.

Attached patch

The last submitted patch, 2: 3397218_2.patch, failed testing. View results →

Your if statement seems to be inverted.
Seems more sensible to skip if cloneable entities are empty or if target entity is not present in the array.

Let's wait for pipeline to run, once green will merge and release.

In its current form this will return false if the target_type is in the cloneable_entities config. This is the opposite of what you would want in a isClonable function.

Kobe Wright → made their first commit to this issue’s fork.

I believe Willempje2 is right, updated the MR to correct the condition in the isClonable() function.
Also attaching a patch here.

I've tried patch #12, but the clone link still appears under /admin/content and when editing a node or content type. So, I've updated the patch to hide the clone link for entities disabled in the cloneable_entities config. Thanks!

Issue 💬 Add action module as dev dependency. Active needs to be merged for failing action tests. Applied the changes from #13 patch so it's all in a MR. Leaving status to needs review.

@deaom started merge train for 💬 Add action module as dev dependency. Active .

Test are now passing, but this really needs to be checked and tested. The issue with tests not passing was with the referenced entities specifically in this test case paragraphs, as even if they were marked as not allowed to clone, they were getting cloned. With the code changes, they are no longer getting cloned, but rather referenced as it was before (or still is in the 2.x without this change). I'm not sure the logic is correct and if it breaks anything as I'm not sure tests are covering everything, so it would be good to test manually and also check the solution is suitable.

Can we add test coverage this to make sure this is working.