Complete user roles implementation

[carlomanf]

v1.2.0, specifically the work for #11, introduced funnel types that support full site editing.

When a funnel type is registered, three new user roles are automatically created for that funnel type:

• {$funnel_type}_contributor (can create funnels)
• {$funnel_type}_author (can publish funnels)
• {$funnel_type}_editor (can edit other people's funnels)

These user roles can then be assigned to users, using a plugin such as Members.

However, registering funnel types can only be done by an Administrator user role because it is gated behind the edit_theme_options capability. This will change with https://core.trac.wordpress.org/ticket/54516, allowing the plugin to support user roles for the registration of funnel types as well.

This could also be done through a similar three-tier model:

• contribute_funnels (can create funnel types)
• author_funnels (can publish funnel types)
• edit_funnels (can edit other people's funnel types)

Assigning these user roles could then allow non-Administrator users to create new funnel types without getting access to the general theme options.

Granting the permissions to users who have these roles could be done through the map_meta_cap or user_has_cap filters. The part that is currently uncertain is whether it will involve the edit_post or edit_template meta capability, and this will depend on the implementation of the core patch.

[carlomanf]

The part that is currently uncertain is whether it will involve the edit_post or edit_template meta capability, and this will depend on the implementation of the core patch.

The comment here, particularly the quoted part below, suggests to me that edit_post is the way to go.

At the moment the WordPress capabilities use edit_post, read_post and delete_post for the meta capabilities for all post types (see WP#50128) so it would be best to maintain this practice if at all possible.

Because edit_post is post type agnostic, it will still work with a post type other than wp_template. This is useful, because the wp_template post type has long been causing a pain point with the persistence of funnel types beyond theme switches. Several previous attempts were made to overcome it:

• The first attempt was 7cf7442, which allowed the default behaviour of wp_template posts to belong to one theme only
• The second attempt was 6312b4b, which ran a database upgrade routine on every theme switch
• The third attempt was fd34007, which allowed wp_template posts to exist with no theme at all

None of these approaches was particularly sound. Thanks to some new hooks that were added in core version 5.9, particularly get_block_templates and pre_get_block_template, these workarounds are no longer required and a more solid solution is possible using a new post type.

It should be noted that the use of these hooks, plus another feature that is being used in the database upgrade, means that the plugin's minimum core version needs to be lifted to 5.9 on the next release.