As is often the case, the answer lies in the documentation. In the documentation for register_post_type() you’ll see:
- ‘capability_type’
(string) The string to use to build the read, edit, and delete capabilities. May be passed as an array to allow for alternative
plurals when using this argument as a base to construct the
capabilities, e.g. array(‘story’, ‘stories’). Default ‘post’.- ‘capabilities’
(array) Array of capabilities for this post type. $capability_type is used as a base to construct capabilities by default. See
get_post_type_capabilities().
So capability_type uses the singular and plural strings provided to fill the capabilities argument, and if we follow that link to the documentation for get_post_type_capabilities() we can see the full list of capabilities (emphasis mine):
By default, seven keys are accepted as part of the capabilities array:
- edit_post, read_post, and delete_post are meta capabilities, which are
then generally mapped to corresponding primitive capabilities
depending on the context, which would be the post being
edited/read/deleted and the user or role being checked. Thus these
capabilities would generally not be granted directly to users or
roles.- edit_posts – Controls whether objects of this post type can be edited.
- edit_others_posts – Controls whether objects of this type owned by
other users can be edited. If the post type does not support an
author, then this will behave like edit_posts.- publish_posts – Controls publishing objects of this post type.
- read_private_posts – Controls whether private objects can be read.
These four primitive capabilities are checked in core in various
locations. There are also seven other primitive capabilities which are
not referenced directly in core, except in map_meta_cap(), which takes
the three aforementioned meta capabilities and translates them into
one or more primitive capabilities that must then be checked against
the user or role, depending on the context.
- read – Controls whether objects of this post type can be read.
- delete_posts – Controls whether objects of this post type can be
deleted.- delete_private_posts – Controls whether private objects can
be deleted.- delete_published_posts – Controls whether published
objects can be deleted.- delete_others_posts – Controls whether objects
owned by other users can be can be deleted. If the post type does not
support an author, then this will behave like delete_posts.- edit_private_posts – Controls whether private objects can be edited.
- edit_published_posts – Controls whether published objects can be
edited.
So by passing ['event','events'] all those capabilities with post will created but with event (eg. edit_event), and all the capabilities with posts will be created but with events (eg. edit_events). However, note that just passing 'event' to capability_type will have the exact same result. This is because if only a single value is passed WordPress will automatically add s for the plural. The only reason you’d need to pass the singular and plural versions separately is if the plural version is not just the same plus “s”, such as story vs stories (if you only passed 'story' then the plural capabilities would be like edit_storys).