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.

[jorgefilipecosta]

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

Nothing is set in stone for now and everything can be discussed/reconsidered.
Introducing a duplicate_post capability is a long commitment the core would offer the ability to duplicate posts, which right now we don't know yet if it is something the core is ready to commit to, so at least initially the plan is not to introduce a new capability.

Again I'm referring to the first version, if the duplicate action is something we want for the long term and it makes it to the core we can reconsider the duplicate capability which in the long term may make sense. Thank you for your availability to contribute to it, if there is a decision to bring the action to the core and we decide to have the new capability on the first version I will keep you in the loop as a contribution there would be helpful.

Even on the first version, there are things that we consider a must from the extensibility point of view one is the ability to opt out of duplicate, and the other is the ability to do additional work when duplicate happens.
Duplicate is just an action so when we have the actions API things like that should be possible:

if( role === Z) { removeAction( duplicate) } or if( postType === Y ) { removeAction( duplicate )

Having the option to do something additional when an action is performed is also something the actions API should be able to offer (e.g.: copy additional data on the backend).

The API's referred to are generic for any action, while a new capability would be specific to duplicate which right now we are not sure if it will be part of the core.

[dlh01]

Again I'm referring to the first version, if the duplicate action is something we want for the long term and it makes it to the core we can reconsider the duplicate capability which in the long term may make sense. Thank you for your availability to contribute to it, if there is a decision to bring the action to the core and we decide to have the new capability on the first version I will keep you in the loop as a contribution there would be helpful.

Much appreciated!

I understand that there's iteration that needs to take place, and I understand that introducing a capability into core represents a commitment, but I hope it's justified by the examples I've given.

[annezazu]

Quick piece of feedback after talking to a medium sized publisher that a duplicate post functionality would be beneficial if/when more data could be duplicated at the same time, as noted above. Namely, thinking about a lot of data baked into metaboxes right now.

[jorgefilipecosta]

Quick piece of feedback after talking to a medium sized publisher that a duplicate post functionality would be beneficial if/when more data could be duplicated at the same time, as noted above. Namely, thinking about a lot of data baked into metaboxes right now.

Hi @annezazu,

Right now, metadata properties are already duplicated so in most cases it should already work 😊

[stevejburge]

Following up from @annezazu's comment ...

@jorgefilipecosta I'm not sure if I've missed changes since my original comment on April 25 (#61083 (comment)) but very little outside of the core features was supported back then. I retested #61083 and the same thing holds today. If something has changed, I'm happy to do some detailed testing again for the updated code.

[MadtownLems]

The ability to control/disable this feature feels essential before this lands in Core. We have existing Duplicate Post functionality (via plugin) that includes things like ACF Fields, Featured Image, and other customizations. Having another "Duplicate" show up that behaves differently would be a terrible user experience.

[jorgefilipecosta]

The ability to control/disable this feature feels essential before this lands in Core. We have existing Duplicate Post functionality (via plugin) that includes things like ACF Fields, Featured Image, and other customizations. Having another "Duplicate" show up that behaves differently would be a terrible user experience.

Hi @MadtownLems, Thank you for your insights. The ability to remove the default duplicate being offered is already implemented; it can be removed like any other action.

[jorgefilipecosta]

Quick piece of feedback after talking to a medium sized publisher that a duplicate post functionality would be beneficial if/when more data could be duplicated at the same time, as noted above. Namely, thinking about a lot of data baked into metaboxes right now.

Hi @annezazu the current implementation already copies all the metafieds, off course it is a simple copy of values, if the field for example represents an id, the referenced entity is not copied but that is something that would always require custom code.

[jorgefilipecosta]

Following up from @annezazu's comment ...

@jorgefilipecosta I'm not sure if I've missed changes since my original comment on April 25 (#61083 (comment)) but very little outside of the core features was supported back then. I retested #61083 and the same thing holds today. If something has changed, I'm happy to do some detailed testing again for the updated code.

Hi @stevejburge,

Currently, metadata and taxonomies are supported. However, we can only duplicate meta fields that the editor can read from and write to through the REST API.

For instance, the following field is correctly duplicated:

function register_test_duplicate_meta() {
    register_post_meta('page', 'test-duplicate', [
        'show_in_rest' => true,
        'single' => true,
        'type' => 'string',
    ]);
}
add_action('init', 'register_test_duplicate_meta');

If we set a field with the key 'test-duplicate', its value will be duplicated.

It's important to note that some plugins, such as ACF, have a default behavior of hiding fields from the REST API, which makes them unavailable to the editor. In such cases, these fields cannot be duplicated.

[MadtownLems]

The ability to remove the default duplicate being offered is already implemented; it can be removed like any other action.

While I understand this isn't a support forum, I have searched far and wide for exactly how to do this with no luck. Might you be able to point me in the right direction?

[jorgefilipecosta]

The ability to remove the default duplicate being offered is already implemented; it can be removed like any other action.

While I understand this isn't a support forum, I have searched far and wide for exactly how to do this with no luck. Might you be able to point me in the right direction?

Hi @MadtownLems,

The following JavaScript code can be used to remove the duplicate action from any post. It can be tested by pasting it into your browser's console:

wp.editor.unregisterEntityAction('postType', wp.data.select('core/editor').getCurrentPostType(), 'duplicate-post');

For a more reliable implementation, this line of code should be added as an action within core.registerPostTypeSchema, which registers the default core actions. It should look something like this:

wp.hooks.addAction('core.registerPostTypeSchema', 'my_callback', () => {
    wp.editor.unregisterEntityAction('postType', wp.data.select('core/editor').getCurrentPostType(), 'duplicate-post');
});