WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

#19148 closed defect (bug) (worksforme)

get_post_types returning more than desired, custom post type objects contain taxonomies

Reported by: Ov3rfly Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.2.1
Component: Posts, Post Types Keywords:
Focuses: Cc:

Description

In addition to the desired custom post types with a certain taxonomy, other custom post types are being returned with this get_post_types example:

		$args = array(
			'public'   => true,
			'_builtin' => false,
			'taxonomies' => array('post_tag')
		);
		$post_types = get_post_types($args, 'objects'); 
		print_r($post_types);

Expected results: All public custom post types with (at least) taxonomy 'post_tag'.

Actual results: All public custom post types, also if they do not have 'post_tag' set as taxonomy.

Result of above print_r() http://pastebin.com/4dL7i0DU

Note the empty taxonomies at post type slider:

    ...
    [slider] => stdClass Object
        (
            ...
            [taxonomies] => Array
                (
                )
            ...

http://codex.wordpress.org/Function_Reference/get_post_types lists 'taxonomies' as valid argument.

Related older thread, but no discussion there: http://wordpress.org/support/topic/get_post_types-returns-more-than-expected

New ticket as similar http://core.trac.wordpress.org/ticket/12966 was closed on a completed milestone.

Attachments (1)

taxonomy.php.patch (1.4 KB) - added by MZAWeb 2 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 MZAWeb2 years ago

  • Cc MZAWeb added
 global $wp_post_types;
 print_r($wp_post_types);

taxonomies is empty for all standard post types in 3.2.1

Last edited 2 years ago by MZAWeb (previous) (diff)

MZAWeb2 years ago

comment:2 MZAWeb2 years ago

Patch fixes the $wp_post_types content.

But get_post_types uses wp_list_filter that doesn't yet work fine with nested arrays. See #16137

comment:3 follow-up: nacin2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Depending on what you're trying to do, you'll want is_object_in_taxonomy(), or get_object_taxonomies(), or get_taxonomies() and pull a taxonomy's object_type argument.

The post type's taxonomies flag is an argument that wraps register_taxonomy_for_object_type(). It is not something that then ends up in the post type object. This data ia stored in only one place (in the taxonomy object) for a reason.

comment:5 in reply to: ↑ 3 ; follow-up: Ov3rfly2 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Summary changed from get_post_types returning more than desired results, taxonomies arg not respected to get_post_types returning more than desired, custom post type objects contain taxonomies

Replying to MZAWeb:

taxonomies is empty for all standard post types in 3.2.1

It is not for custom post types.

Replying to nacin:

The post type's taxonomies ... It is not something that then ends up in the post type object.

With custom post types the taxonomies end up in the post type object, quote from above pastebin:

    [location] => stdClass Object
        (
            ...
            [taxonomies] => Array
                (
                    [0] => category
                    [1] => post_tag
                )
         ...
    [organisation] => stdClass Object
        (
            ...
            [taxonomies] => Array
                (
                    [0] => category
                    [1] => post_tag
                )

It seems that builtin post types do not contain taxonomies in the post type objects returned by get_post_types(), but custom post types do. This is not consistent.

I still consider this as a bug, though it's not one about the arg 'taxonomies' but about the content of the returned objects.

The results of get_post_types() are returning more as expected.

comment:6 SergeyBiryukov2 years ago

  • Milestone set to Awaiting Review

comment:7 in reply to: ↑ 5 ; follow-up: MZAWeb2 years ago

Replying to nacin:

This data ia stored in only one place (in the taxonomy object) for a reason.

Why would that reason be? (just asking, really)

Replying to Ov3rfly:

It seems that builtin post types do not contain taxonomies in the post type objects returned by get_post_types(), but custom post types do. This is not consistent.

I'm seeing the same behavior. My patch fixes that.

Version 0, edited 2 years ago by MZAWeb (next)

comment:8 in reply to: ↑ 7 nacin2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from reopened to closed

Replying to MZAWeb:

Replying to nacin:

This data ia stored in only one place (in the taxonomy object) for a reason.

What would that reason be? (just asking, really)

You don't want to store data in two places. This means you then need to sync the data.

Replying to Ov3rfly:

It seems that builtin post types do not contain taxonomies in the post type objects returned by get_post_types(), but custom post types do. This is not consistent.

I'm seeing the same behavior. My patch fixes that.

The correct fix would be to unset($args->taxonomies) before shoving the data into $wp_post_types. It's probably too late at this point as some plugin will likely break, but the point is, this isn't the right place to look for this data. It was purely a registration argument.

Note: See TracTickets for help on using tickets.