A Way to Disable Export Theme

[unsalkorkmaz]

related Github issue;
​https://github.com/WordPress/gutenberg/issues/46661

## What problem does this address?
This button tries to zip my whole theme which as node_modules with 500MB content:

Here is the video:
​https://www.youtube.com/watch?v=9F1LtmMrjsY
You can see CPU spike in right macos m1 menu..

And lets say I want to show a demo for my premium theme.. Why would I want a download button?

## What is your proposed solution?
I need a way to disable this.

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

[rajinsharwar]

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.

[peterwilsoncc]

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

[rajinsharwar]

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

[rajinsharwar]

New ticket created for the Node Modules issue: #61575

[peterwilsoncc]

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.

[rajinsharwar]

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

[Mamaduka]

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

[TimothyBlynJacobs]

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.

[Mamaduka]

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

[peterwilsoncc]

I've reopened this as the ticket is focusing on changing the permissions for allowing export, which needs implementation in both the UI and the API endpoint.

As there hasn't been any progress for a while, I've moved this off the 6.7 milestone.

I committed the change proposed by Peter.

[desrosj]

+1 from me to use export capability.

@Mamaduka what is required on the editor side to properly support this change. Is it too late to include in 6.8?

If so, let's punt this now and get the required changes ready for 6.9.

[Mamaduka]

Definitely doable for 6.8. Here's a draft PR for the client code changes - ​https://github.com/WordPress/gutenberg/pull/69107.

PR implements permission check via OPTIONS request and canUser selector.

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, do you have an example of this? I don't think I've seen a similar pattern before. If my proposed canUser resolve changes aren't viable, we could use it as an alternative.

[audrasjb]

Self assigning for final review and commit.

[audrasjb]

In 59924:

Editor: Use the export cap to determine whether users can export themes.

This changeset replaces edit_theme_options with the export capability to determine whether the current user can export themes. That condition determines whether to show the Export Theme button in the Site Editor. Using export capability makes it more consistent with general export capabilities across the administration.

Props unsalkorkmaz, rajinsharwar, audrasjb, peterwilsoncc, desrosj, Mamaduka, TimothyBlynJacobs.
Fixes #57379.

Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/69971
Trac ticket: https://core.trac.wordpress.org/ticket/57379

@audrasjb, since you're the owner of the original ticket, would you prefer to reopen it, or should I create a new one?

I plan to add some basic unit tests and then commit this.

[wildworks]

@audrasjb @Mamaduka As I understand it, ​PR #8770 is a backport from Gutenberg and should be committed in the 6.9 cycle, so I'd like to update the milestone.

[Mamaduka]

Re-opening for the remaining REST API change.

The same code has been tested inside the Gutenberg plugin for months now without any issue. I think it's okay to merge this.

cc @ellatrix, @t-hamano

[Mamaduka]

In 60984:

REST API: Add export rel link for active theme response.

The targetHints.allow value is used by the Site Editor to enable/disable the theme export feature.

Props mamaduka, wildworks.
Fixes #57379.