Skip to content

Proposal: robust permissions system for FSE theme templates #27597

@carlomanf

Description

@carlomanf

Is your feature request related to a problem? Please describe.
The usual post type capabilities (edit_posts, publish_posts etc) will not work for FSE theme templates. If you grant someone the permission to edit and publish their own posts, they can not affect anyone else's posts. If you do the same with templates, they would be able to publish a single template where a singular already exists, and cause drastic changes to much of the site.

However, it still makes sense that you might want to let someone control the templates for a particular post or a particular post type, without being able to affect the rest of the site.

Describe the solution you'd like
The idea is the system would recognise capabilities such as edit_single_templates or delete_others_archive_templates etc, with keys from the template hierarchy inserted into the usual post type capability patterns.

For example, if a user has the capability edit_page-$id_templates, they can submit their own template for a particular page, but it will need to be approved by an admin unless they also have the publish capability. If a user has the capabilities edit_single-$posttype_templates, edit_published_single-$posttype_templates and publish_single-$posttype_templates, they will have full and independent control over the templates for that post type (including single-$posttype-$slug) but not any other post types.

Note that they would be automatically granted permission for more specific templates than the one specified in the capability. This means edit_index_templates is effectively the same as edit_templates, delete_others_index_templates is the same as delete_others_templates etc.

By default, the only capabilities granted would be the general ones to admin roles. The more specific capabilities would just be available for optional use.

Describe alternatives you've considered
I've already written some exploratory code to test out this approach, and it looks viable to me as long as there is agreement that it's the best approach. I'm open to hearing alternative approaches.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions