Add Custom Post type to wp_post_types global variable

What action are you using to register the new post type? (in your add_action() function)

init. I actually tested all of them with various priorities.

It’s definitely a bug somewhere in core. If you r_print the $wp_post_types variable in the actual register_post_type() function in wp-includes/post.php. It does list all registered post types.

Somewhere in core all none _builtin post types are being removed from the $wp_post_types global variable.

I’ve tried that on a site of mine, and I don’t get the same results.

That site has 4 custom post types registered, and when I dump the global $wp_post_types variable in a template file (way after any sort of processing should affect this) I get a list of all of the post types, including my custom ones. These are all registered using the standard register_post_type() function using the init action.

Where in your code are you trying to use this value? Maybe you’re trying to use it before the custom post types are registered.

It a clean current install, and tested on an older install that’s up to date. Using _s theme (because debugging on twentyfifteen sucks due to that damn sidebar). No plugins.

At the bottom of the functions.php file using this code.The custom post type code is from the codex.

// codex example
function codex_custom_init() {
    $args = array(
      'public' => true,
      'label'  => 'Books'
    );
    register_post_type( 'book', $args );
}
add_action( 'init', 'codex_custom_init' );

global $wp_post_types;
if( !is_admin() ) { // keep it out of the admin
	echo '<pre>'; print_r( $wp_post_types ); echo '</pre>';
}

Now, I can manually add the post type into the global, but I shouldn’t have to because it’s already being added in the core register_post_type() function, like I said in my previous post.

Somewhere in between the wp-includes/post.php and the output the custom post types are being removed from the variable.

global $wp_post_types; should be one of the first lines in the file, not down near the bottom. Try it up at the top of the file, and I believe that it should work.

The reason for that is that you’re calling it as a global variable after it’s being added to, and I’m not sure if that’s going ot give the expected results.

It doesn’t need to be at the top of the file. You just need to declare is before you use it.

Either way, I figured it out.

The codex_custom_init() is being run after the code in the functions.php file, because it’s executing with the add_action. I need to add the print_r code in a function using an action.

// codex example
function codex_custom_init() {
    $args = array(
      'public' => true,
      'label'  => 'Books'
    );
    register_post_type( 'book', $args );
}
add_action( 'init', 'codex_custom_init' );

// doing it right :)
function check() {
 	global $wp_post_types;
 	if( !is_admin() ) {
		echo '<pre>'; print_r( $wp_post_types ); echo '</pre>';
	}

}
add_action( 'init', 'check' );

That’s what I get for coding all day without any real breaks.

Thanks for helping me work this out.

You’re right! I should have seen that too… I’m glad that you got it sorted out, and hopefully this will help someone else out as well.

The worse part is I probably spent two hours debugging core trying to fix it.

All I was trying to do was to make sure that a working custom post type had the correct arguments. Which I already knew it had.

Being anal just doesn’t pay sometimes.