Evaluate cloning modules

pameeela → closed merge request !88

pameeela → reopened merge request !88

I tried to look into available cloning modules and created a sheet. Attached are the screenshot of comparison and link to sheet.

Link to sheet: https://docs.google.com/spreadsheets/d/1l8V3mwqbn_CzyhGNEMpMDnyE_FZskNZh2QiiBeqzqTc/edit?usp=sharing

Leaving a note that cloning may be done with ECA in 📌 Create recipe to clone entities with ECA Active

@narendrar thank you so much for this thoughtful comparison! I am revisiting this since we are leaning away from using ECA for it.

Everytime a new field is created, it needs to be added manually for cloning.

Oh my gosh, I did not even think about this! I don't think that Content entity clone is a viable option based on this.

But then I am leaning toward keeping Quick node clone because it is simple and provides the right UX. I know that it only applies to nodes, but that is the overwhelming use case, and if site owners want to be able to clone other entity types they can switch to another approach without any issues really.

Cloning differs from other features where extendability is important because switching to a new module has basically zero downside, there is no data model or migration path, or even conflicts -- you can use them all at the same time if you want, as shown here!

Happy for others to share opinions on this before we make the final call though.

The only concern I have about Quick Node Clone is issues like: https://www.drupal.org/project/quick_node_clone/issues/3100117 🐛 Inline blocks from layout builder not cloned properly Needs review and https://www.drupal.org/project/quick_node_clone/issues/3405765 🐛 Non-reusable blocks must set an access dependency for access control Active

We won't ship with layout builder enabled for per node customisations, so you could make the argument that sites using Drupal CMS that end up opting for that would be able to make their own call on cloning. On the other hand, if it doesn't fully work for LB it probably won't work for XB.

I won't die on this hill but I do feel strongly that this is the UX that folks expect and the Entity clone and Replicate UI flows are not. And I also recognise that their flows may have been designed that way for a reason so I don't expect that they should necessarily change them. Replicate even specifies that it was created for a very complex workflow. Not only that but Entity Clone has 65 open bugs so is that going to be any better? I don't know, so I don't mean to call that out, just saying that all contrib has trade offs.

If those two issues are the main concern, we could try to get them fixed, one seems to have a working MR so it just needs a review, and the other sounds like an edge case.

I have needed cloning of non-node entities on several different sites. Groups is the most recent one but I could see people wanting it for media and webforms too, both of which will be shipped with Drupal CMS.

While the UX of entity clone is not ideal, having to uninstall quick node clone and then install entity clone, as well as finding out that this is what you need to do, is worse IMO. There might be improvements that can be made to entity clone like making it default to the entity edit form after creation etc.

Webform includes a 'Duplicate' function so it's not needed for that. But yes there are tradeoffs to both approaches. I have never had a client ask for cloning of anything other than nodes, but that's just me!

Under the hood, entity_clone is not great. It needs a lot of refactoring, which isn't happening. However, at least part of the cause is that this is a really complex problem space, especially when you consider entities referenced by the entity being cloned - should they be cloned too?

We have decided to go with ECA for this, see 📌 Evaluate cloning modules Active for details.

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

The crucial bit that replicate brings to the table is events that other modules can integrate with. Paragraphs for example implements that and all kind of content building that uses other entity types (also for example layout builder with block_content) requires something like that. That's for example also why commerce has its own clone features. We also further extend that in client projects to add further customization to the process, including some projects that extend the confirm form to add some extra options (for example into which group the content should be replicated.

We're also working on a generic functionality to skip translations when cloning/replicating, a frequently used feature by our editors.

The best way forward would IMHO be to get the following core issue committed: ✨ Introduce a "duplicate" entity operation Needs work , then replicate_ui could for example become just a UI and the replicate project could be deprecated.

Also the UX feedback here would be great to post into issues in the replicated modules, happy to change the redirect to the edit form instead of view for example, should be an easy change.

Maybe this could be reopened to discuss/track that?

@berdir thank you for this info. It's too late to change our approach for v1, but happy to revisit this for future releases.

Part of what is nice about the ECA approach is it requires zero config. I am inclined to think that any use case that requires a confirmation screen where additional options are offered is beyond the scope of Drupal CMS, which is just providing a base with some useful features. If someone is building a site that requires a more complex behaviour such as selecting which group the content should be replicated into, then I'd suggest they should use Replicate.

But, we are also able to change the approach to this relatively easily, since there isn't any upgrade path to worry about. If in future there is a better way to do this, we can change it Drupal CMS, and existing sites that want the new approach may be able to switch via a recipe.