WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 4 weeks ago

#39089 new enhancement

Setting the Object Relationship Between Post Type Objects and Taxonomy Objects

Reported by: michael.ecklund Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 2.9
Component: Posts, Post Types Keywords: needs-patch needs-unit-tests early
Focuses: Cc:

Description

Does it matter which is object is created first when setting the object relationship between Post Type Objects and Taxonomy Objects?


Are you supposed to register Post Types FIRST, and Taxonomies required by that Post Type SECOND?

OR

Are you supposed to register the Taxonomies FIRST, and the Post Types which use those Taxonomies SECOND?


The way I look at it is:

Taxonomy Objects should be created first before the Post Type Objects, since they're ultimately the bond between Post Objects and Post Type Objects; Taxonomies can be used across multiple Post Types objects.

The reason I ask this is: because the WordPress Codex seems to outline it as register the Post Types FIRSTLY, and then register the Taxonomies SECONDLY.

I get this vibe by looking at two functions in the WordPress Codex:

  1. [register_post_type();](https://codex.wordpress.org/Function_Reference/register_post_type#Arguments) - If you look at the arguments section, there's an argument for Taxonomies (Notice: This is plural).
  2. [register_taxonomy();](https://codex.wordpress.org/Function_Reference/register_taxonomy#Parameters) - If you look at the parameters section, there's an parameter for specifying a single Object Type or Multiple Object Types. However, the actual parameter is called $object_type. (Notice: this is singular).

Now, where I'm confused is: PHP loads things in a procedural order. So there for one event needs to happen before the next. Both of the above functions have the capability of specifying multiple object types as a relationship.

So to conclude my final question. What makes the most sense? Register Post Types first and Taxonomies second, or visa-versa?

I also ask this because when you are dealing with the Post Type Objects and Taxonomy Objects in a programmatic way. Each object has a property which contains an array of related objects.

Look at [get_post_type_object();](https://codex.wordpress.org/Function_Reference/get_post_type_object#Examples) and [get_taxonomy();](https://codex.wordpress.org/Function_Reference/get_taxonomy#Examples)

It's kind of misleading having one object say there's no relationship. Then have the other object say there definitely is a relationship.

So for my own sanity and keeping things consistent, I've been creating my Taxonomies first and Post Types second.

I set the parameter ($object_type) to null in register_taxonomy(); and then I specify the desired Taxonomies in the Taxonomies argument when using register_post_type();.

I then follow up with my consistency of using: [register_taxonomy_for_object_type( $taxonomy, $object_type );](https://codex.wordpress.org/Function_Reference/register_taxonomy_for_object_type)

That way, the relationship is clear when dealing with either object.

Could this happen automatically? So that no matter which object you're dealing with, upon inspection, the relationship is clear.

Change History (2)

This ticket was mentioned in Slack in #core by peterwilsoncc. View the logs.


4 weeks ago

#2 @peterwilsoncc
4 weeks ago

  • Keywords needs-patch needs-unit-tests early added
  • Version changed from 4.6.1 to 2.9

Hi @michaelecklund

I'm sorry for the delay replying to your ticket, it was discussed in a triage session a short time ago.

I'm not sure there is a best answer for whether registering taxonomies or post types is best done first.

If I understand correctly, this is the core of your enhancement request:

Could [post and taxonomy relationships] happen automatically? So that no matter which object you’re dealing with, upon inspection, the relationship is clear.

... and that this would happen no matter how the relationship was registered (via post types, or via taxonomies).

I think this makes sense but would need to have some robust unit tests as it seems like something that could lead to infinite loops if it contained any bugs.

I've set the version to 2.9 as that's when CPTs were introduced.

Note: See TracTickets for help on using tickets.