Closed jmichaelward closed 5 years ago
I created #6, which is a blocker for this issue. Ideally, the ContentType
class will be developed with both PostType
and Taxonomy
in mind, and once we're ready for the eventual 1.0.0
release, PostType
will be updated to extend it.
In terms of the Taxonomy
class itself, it should support a sensible set of defaults required to register a taxonomy (e.g., a slug, an array of post types, labels), as well as a mechanism for defining the overrides, but little more. The abstract class should be opinionated enough to provide a consistent structure for registering post types easily, but not so specific that it gets in the way of registration. I have an implementation in a client project that I can bring into a branch here so we can give them a look for comparison and discuss what else is needed.
Looking at
register_taxonomy( $taxonomy, $object_type, $args );
The abstract class should define the following:
Property:
$taxonomy
The string taxonomy name.Property:
$object_type
The string object type (post, page, etc)Method:
__construct( $taxonomy, $object_type )
Sets the above-mentioned properties.Property:
$labels
Associative array of labels.Method:
set_label( $label_key, $label_value );
Should set a member of$this->labels
based on$label_key
. The key should be validated against the available keys in$this->labels
.Method:
get_label( $label_key )
Return the given label value. (Not sure if we need a label getter)Method:
set_labels( array $labels )
- Accepts an array oflabel_key => label_value
pairs that is parsed against$this->labels
usingwp_parse_args
. Should also ensure that passed label keys are valid, as withset_label()
.Additional properties (from the
$args
parameter):public
(boolean)publicly_queryable
(boolean)show_ui
(boolean)show_in_menu
(boolean)show_in_nav_menus
(boolean)show_in_rest
(boolean)rest_base
(string)rest_controller_class
(string)show_tagcloud
(boolean)show_in_quick_edit
(boolean)meta_box_cb
(callable)show_admin_column
(boolean)description
(string)hierarchical
(boolean)update_count_callback
(callable)query_var
(boolean|string)rewrite
(boolean|array)capabilities
(array)sort
(boolean)Boolean properties should have getters/setters as:
set_<property>( bool $isset )
- Set the property to the value of$isset
get_<property>() : bool
return the value of the property.String properties should have getters/setters as:
set_<property>( string $value )
- Set the property to the value of$value
get_<property>() : string
- Return the property's string value. (Should these accept a default return as an argument?)Callable properties should have a setter method:
set_<property>( mixed $callback )
- Callbacks should not be type-hinted, as various types may be "callable" in WordPress.Array array properties should be filtered to match accepted values, when applicable - for instance, the
rewrite
array accepts a predefined set of array keys.Is it worth adding the following defined "built-in" object types as class constants?
e.g.
Taxonomy::TYPE_POST
("post") ?Thoughts
I'm thinking that this should implement an interface with the public setters/getters. I'm not sure if that's overkill if those will be defined in the abstract already, but the point of interfaces is to create a common API so maybe it's fine? I also don't know that the abstract needs to actually define any
abstract
methods.Also, should the abstract define a method such as
register
that can be hooked (or just have it implementHookable
and/orRunnable
, or something similar?