Download the PHP package alleyinteractive/wp-caper without Composer
On this page you can find all versions of the php package alleyinteractive/wp-caper. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download alleyinteractive/wp-caper
More information about alleyinteractive/wp-caper
Files in alleyinteractive/wp-caper
Package wp-caper
Short Description Fluently distribute capabilities to roles in WordPress.
License GPL-2.0-or-later
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package wp-caper
Caper
Caper provides a fluent interface for distributing post type, taxonomy, or generic primitive capabilities to roles in WordPress.
Installation
Install the latest version with:
Basic usage
An invocation of Caper takes the form of "<grant to|deny to> <these roles> <these capabilities>."
Caper can distribute primitive capabilities directly:
Caper can also distribute the primitive capabilities associated with a post type or taxonomy. For example:
which grants users with the author role all capabilities for the page post type, and it denies users with the editor role all capabilities for the category taxonomy. (Be sure to read the section on ensuring unique post type and taxonomy capability types to avoid unintentionally modifying capabilities for other object types.)
When granting capabilities to a post type or taxonomy, a subset of those capabilities can be denied, or vice versa. For example:
which grants users with the author role all capabilities for the page post type except for the page capability corresponding to delete_posts, and it denies users with the editor role all capabilities for the category taxonomy except for the category capability corresponding to assign_terms.
Alternatively, an exclusive set of post type or taxonomy capabilities can be granted or denied:
which denies author users all capabilities for the page post type except for the capability corresponding to delete_posts, and it grants editor users role all capabilities for the category taxonomy except for the capability corresponding to assign_terms.
Multiple post types or taxonomies can be passed to caps_for(). Capabilities will be granted or denied identically for all passed object types, including exceptions or exclusives:
Capabilities also can be granted or denied to all roles in one shot:
The grant_to_all() and deny_to_all() methods can be combined with the then_grant_to() and then_deny_to() methods to "reset" capabilities across roles before systematically redistributing them. For example:
Internally, the then_grant_to() and then_deny_to() methods create new Caper instances that combine the newly supplied roles and previously supplied primitives or object types.
Because each Caper instance modifies user capabilities by adding a filter to user_has_cap, the second of two created instances will apply its distribution of capabilities after the first instance.
The priority of the user_has_cap filter for any Caper instance can be modified with the at_priority method:
Ensuring unique capability types
Caper does not attempt to determine whether the post type or taxonomy capabilities it distributes are unique to that object type.
For example:
will also deny editors capabilities for the post post type. Registering post types with distinct capability_type arguments and taxonomies with capability argument arrays is recommended:
