Follow up questions on the duplicate post and page feature

[carolinan]

Description

Hi @jorgefilipecosta

Regarding the duplicate post and page feature #60637
I was not sure where to post this, and I hope that some of this will be addressed in the core blog post for the next Gutenberg release, but I have some questions.

• What user roles has access to duplicating posts and pages?
• How can I limit which user roles has this access?
• Can I turn it off completely?
• How do I extend the support to other post types?
• How do I limit it per post type?
• Are taxonomies including custom taxonomies, featured images and post meta included in the duplicated post/page?
• For example what happens with footnotes and bindings when you duplicate the post.
• Will this be added to the "quick edit" interface in the "old" post and page lists in the WordPress Admin?

There is also a question already posted on the pull request:

Hi everyone, creator of Yoast Duplicate Post here :)
Are there hooks in place where plugins can add functionality or replace the action with a custom one?

Step-by-step reproduction instructions

Screenshots, screen recording, code snippet

Environment info

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[stevejburge]

Thanks for the work on this. I think this is a great idea, but there may be some hurdles that I haven't seen discussed yet.

I'm speaking from experience as someone involved with another duplicate post plugin: https://wordpress.org/plugins/revisionary/. I think @enricobattocchi may have some useful feedback on this too.

Here's the issue: it's relatively simple to copy WordPress core data, but problems quickly emerge with plugins and all their many and strange ways of storing data.

For example, I tested this PR with ACF fields and the data in the fields was not carried over to the duplicate post. I suspect the same will be true of most plugins.

At the moment, it doesn't look like post meta is being copied with this PR. I also tested custom taxonomies and they weren't copied.

[courtneyr-dev]

Wanting to note as well that the duplicate post topic came up in this issue: #38554

[carolinan]

It is understandable that the DataViews are not as extendable yet. But this duplicate option is not only added to the Site Editor screens that uses the DataViews. It is also in the block editor for classic themes, where these new data views right now are irrelevant to both extenders and users.
In that context, it is a new major feature that is added, and it needs to be considered as such.

[jorgefilipecosta]

Hi @carolinan, thank you for raising very important questions. I will answer them below. The answers represent what I have in mind for the feature some are already implemented some may still be in progress. And for all of them, we can discuss alternative paths. This feature like all the other actions is still under active development.

• What user roles has access to duplicating posts and pages?

The plan is for any user role that has the capability to edit posts to be able to duplicate them. A user with edit-posts capability could just duplicate a post by copy-paste. The duplicate action is like a shortcut to that.

• How can I limit which user roles has this access?

I don't think we should introduce a capability like "duplicate_post". What controls the ability to duplicate could be the edit_posts capability. If the edit_posts capability is removed from a user in that case that user cannot edit posts and should also not be able to duplicate them.

• Can I turn it off completely?

Not yet, but the plan is for it to be possible. Actions API's are part of the dataviews and their extensibility will be discussed at #61084.

• How do I extend the support to other post types?

All post types provided they support the editor, are supported by default. As the idea is for duplicate to be a shortcut for what could copied manually with the editor anyway.

• How do I limit it per post type?

As soon as we have the APIs to register and unregister the actions, one could conditionally unregister the duplicate action depending on the post type.

• Are taxonomies including custom taxonomies, featured images and post meta included in the duplicated post/page?

The taxonomies that are duplicated for now are categories and tags. I think we should also duplicate custom taxonomies for which the user currently duplicating the post has assign capabilities. I will work on a PR for that.
Featured images and post meta are also duplicated. Here is the full list of properties that are duplicated: author, comment_status, content, excerpt, meta, parent, password, template, format, featured_media, menu_order, ping_status, categories, tags.

• For example what happens with footnotes and bindings when you duplicate the post.

They should be duplicated as well I just made a test and the footnotes seem to work as expected.

• Will this be added to the "quick edit" interface in the "old" post and page lists in the WordPress Admin?

There are no plans for it.

[jorgefilipecosta]

Hi @stevejburge, thank you for reaching out and sharing some insights 😊

Here's the issue: it's relatively simple to copy WordPress core data, but problems quickly emerge with plugins and all their many and strange ways of storing data.

Yes, it is easy to get into issues with plugins. I don't think Core should provide the expectation of its duplicate working well in every case it should only be seen as a shortcut to what the user could have copied manually on the editor anyway. With the APIs offered in the future, it should be very easy to remove the action if it is not working well for certain scenarios.

For example, I tested this PR with ACF fields and the data in the fields was not carried over to the duplicate post. I suspect the same will be true of most plugins.

At the moment, it doesn't look like post meta is being copied with this PR. I also tested custom taxonomies and they weren't copied.

Custom taxonomies are not copied yet, but they should be in the future. Regarding meta, I expect that it is already being copied. For example, footnotes are stored in meta and they are correctly duplicated. We will need to do some debugging to see why ACF fields are not being duplicated.

All the points being raised are important. The feature for now is only available in the plugin so before making it available in core we can polish things and then decide if it is ready for core or not.

[dlh01]

The plan is for any user role that has the capability to edit posts to be able to duplicate them. A user with edit-posts capability could just duplicate a post by copy-paste. The duplicate action is like a shortcut to that.

Please keep in mind that it's possible for a user to be able to edit posts in a post type without being able to create posts in that post type. For example:

// Allow only administrators to create pages by default.
add_filter(
	'register_page_post_type_args',
	function ( $args ) {
		$args['capabilities']['create_posts'] = 'manage_options';

		return $args;
	},
);

Regardless of whether cloning ends up with its own capability, it should at least require that the user can both edit the post being cloned and create posts in the post type, I would think.

[jorgefilipecosta]

The plan is for any user role that has the capability to edit posts to be able to duplicate them. A user with edit-posts capability could just duplicate a post by copy-paste. The duplicate action is like a shortcut to that.

Please keep in mind that it's possible for a user to be able to edit posts in a post type without being able to create posts in that post type. For example:

// Allow only administrators to create pages by default.
add_filter(
	'register_page_post_type_args',
	function ( $args ) {
		$args['capabilities']['create_posts'] = 'manage_options';

		return $args;
	},
);

Regardless of whether cloning ends up with its own capability, it should at least require that the user can both edit the post being cloned and create posts in the post type, I would think.

Good point, yes we should also check for create_posts capability. On the documentation for roles and capabilities https://wordpress.org/documentation/article/roles-and-capabilities/, create_posts is never mentioned only edit_posts is referred. I guess that is something that should be corrected in the documentation.

[dlh01]

I'd also like to say that I hope that decision against using a duplicate_post capability is reconsidered.

There are maintenance costs to introducing capabilities into core, and I don't want to disregard those. In this case, I think the flexibility afforded to agencies maintaining WordPress sites for clients outweigh the costs.

A user with edit-posts capability could just duplicate a post by copy-paste. The duplicate action is like a shortcut to that.

it should only be seen as a shortcut to what the user could have copied manually on the editor anyway.

I get how this comparison is accurate in some cases. In the agency work that I do, there are lots of cases where it isn't accurate. For example, some parts of a block's editing interface might not be shown to users with certain roles. Some post meta might be set programmatically and not have a UI at all. In these cases, duplicating does more than a user could do by copying and pasting.

So that's one concern. But either way, I'm reasonably confident that our clients are going to come to us with a request to control who has access to duplicating posts and when.

Maybe I'd be proven wrong in the end, but here are some scenarios I can think of:

• A news organization wants to allow its staff to duplicate posts most of the time, but they don't want to allow duplicating posts that were syndicated from a news agency like Reuters.
• A organization with a large staff already has a plugin for duplicating posts and custom infrastructure built around it, and they aren't ready yet to migrate their functionality to core's implementation and provide training about how to use it.

The capabilities API, particularly meta capabilities, is designed exactly to meet nuanced cases like these.

From a technical perspective, I think it would be straightforward to make current_user_can( 'duplicate_post', $post_id ) have the same outcome by default as current_user_can( 'edit_post', $post_id ). Doing so would allow developers to use the map_meta_cap or user_has_cap filters to control the duplicate_post meta capability to meet their needs. I'd be happy to help contribute that code.