Fixing issue with node_modules not getting ignored while in sub-directory and adding new filter for permission capability for Export button. New filter "allowed_user_role_to_export_theme" added to add control over the permission callback of that Export Functionality.

Trac ticket: https://core.trac.wordpress.org/ticket/57379

I have fixed the issue where node_modules were not ignored in the subdirectories.

Also now, anyone can create a new user capability, and using the new filter "allowed_user_role_to_export_theme", use that to add restrictions over that Export Functionality. Something like this:

add_filter( 'allowed_user_role_to_export_theme', function( $role ){
        $role = 'my_custom_user_capability';
        return $role;
} );

In this way, instead of the default capability "edit_theme_options", the "my_custom_user_capability" will be used while checking for permissions.

Also, updated the title of the ticket to mention the change about node_modules. Slating for 6.7 release.

@rajinsharwar I think these should be seperate tickets, one to ignore the node modules and one to discuss the need for a new filter.

@peterwilsoncc Reverted the node_modules change, so that we can discuss about the new filter in thic ticket.

New ticket created for the Node Modules issue: #61575

Thanks @rajinsharwar.

WordPress includes an ​export capability that controls the ability of users to export the contents of a site. With the introduction of the Site Editor, this also includes the posts and images used for customizing a theme.

As exporting a theme includes exporting these post types and combining them with the existing theme, I am wondering if the appropriate change for the exporting of themes from the site editor is to also use the export capability.

@peterwilsoncc Yeah, maybe we can just change that to the default export cap. Pushed that!

Using the export capability makes sense; a user is exporting Site Editor content.

The client-side code should also be able to check if a user can perform an export action and show/hide menu items based on this.

This could be done by adding action to the theme responses.

Example from posts controller - ​https://github.com/WordPress/wordpress-develop/blob/74e03e3cbef2f2565028f446c76acb2dabf749bd/src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php#L2201-L2203

I think ideally this would end up getting exposed by the client doing an OPTIONS or HEAD request to the export endpoint.

I think a link would also be a good idea. But instead of an action link, we could link to the export endpoint using a rel like w:export-theme if the theme is a block theme, and include an appropriate targetHint.

@TimothyBlynJacobs, I suggest a link because export doesn't really fit into CRUD actions that API usually checks via OPTIONS or HEAD requests.