- Issue created by @tstoeckler
- Status changed to Needs review
about 2 months ago 11:03pm 19 February 2025 - 🇨🇭Switzerland berdir Switzerland
A duplicate action would either go to the duplicated canonical or edit form of that entity, no?
- 🇩🇪Germany tstoeckler Essen, Germany
I mean I guess it's somewhat opinionated either way, so feel free to "closed (won't fix)" this if you disagree, no hard feelings. I personally just like the UX of having the collection/list be a hub to which you return after each administrative action (i.e. concretely entity operation) that you start from that page. And given that premise, the duplicate operation is an outlier. In particular, if you think it would be best to land on the canonical/edit-form of the duplicated entity wouldn't it make sense to do the same thing when editing an entity?
- 🇨🇭Switzerland berdir Switzerland
I'm not sure.
To be perfectly honest, I'm just looking a little bit after the entity module because nobody else does. And I just had a quick look through recent issues while preparing a new release. I'd rather remove/deprecate things than add more in general.
And duplicate features has like 7 competing contrib projects that are all very similar (we use replicate/replicate_ui)
We finally just managed to get hook_entity_duplicate() into core ( https://www.drupal.org/node/3268812 → ) and there's a core issue to add a duplicate operation directly into core as well.
Drupal CMS adopted a purely configuration based approach using ECA for duplicating features and just directly links to a pre-filled entity form. And with the alter hook in core, that is sufficient for many use cases.
- 🇩🇪Germany tstoeckler Essen, Germany
On the concrete issue, one last pitch:
While this is technically adding lines of code, this (in my mind) really is just bringing over #2767857: Add destination to edit, delete, enable, disable links in entity list builders → to the duplicate operation so it's just adjusting contrib Entity API to core code drift. If you want to remove the duplicate operation (from this module) that's fine as well, and I can see why then it doesn't make sense to adjust it if the intent is to remove it anyway, but it would be great in that case to make a concrete decision along those lines then. (Whether in terms of code it just gets deprecated first or wholesale removed directly is an implementation detail from my point of view, for me the valuable thing would be the explicit intent of removal so I know where things stand.)On the module maintenance:
Maybe that's best discussed elsewhere (and possibly through a more "synchronous" medium) but I'd be fine helping out or taking over the maintainership of the module, if and in whatever way that works for you. There's still a number of things I'd like to land here that I don't think would make it into core for various reasons so if you're looking to (soft-)"decomission" this module that would also of course be fine with me, then I'd just put my stuff in a different module namespace here on Drupal.org. Or we could put the 1.x here on life-support/soft code-freeze and I could put new stuff in a 2.x branch or whatever. Again, basically fine with whatever works best for you just wanted to put it out there if you are in fact looking for help. - 🇨🇭Switzerland berdir Switzerland
I'm absolutely open to having more active maintainers, want to create a separate issue to make it an official request? You're welcome to start a 2.x branch, there's quite a bit of cruft that did in fact make it into core, such as 🐛 uses of drupal_set_message() Needs review , would be a chance to clean that up.
That said, a separate project, or an approach with multiple modules within the project or something might make it easier to deprecate and remove functionality that does make it into core. Similar to ctools, I originally thought this would become some kind of sandbox/incubator project to test stuff before it goes into core but that's not really compatible with being a required dependency of projects like commerce/group/. Your call.
- 🇩🇪Germany tstoeckler Essen, Germany
OK, coolio, opened 📌 Offering to co-maintain the module Active . Yeah, I totally get that, that was where I was at a couple years ago, as well, unfortunately (?) that's not where I'm at anymore ;-), but, yeah, at the end of the day, just let me know how you want it.