Add abstract data structure for taxonomy registration

[phatsk]

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 of label_key => label_value pairs that is parsed against $this->labels using wp_parse_args. Should also ensure that passed label keys are valid, as with set_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.
  • I don't think we would need a getter for this, but maybe?

• 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?

• post
• page
• attachment
• revision
• nav_menu_item
• custom_css
• customize_changeset

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 implement Hookable and/or Runnable, or something similar?

[jmichaelward]

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.

[jmichaelward]

8 has been merged into develop, as has this work. Closing.