wpgaijin

See, I’ve had issues with it just not clearing the any of the cache, on multiple sites. I’ve had to stop using all together, because I couldn’t make any modifications to the sites.

It’s real shame, W3 Total Cache was great and the only caching plugin I would use. I’m still looking for an alternative.

Well, the w3edge and Frederick Townes’s twitter account is active, so he’s OK. I tweeted the w3edge earlier today about the W3 Total Cache and still haven’t received a reply.

I really just think he abandoned it. This could be the end of W3 Total cache.

It’s not a page template, it a plugin options page in the admin.

Well, there are plenty of plugins and frameworks that use repeatable fields for settings. I don’t see why I couldn’t save nested serialized data via the Settings API.

You should really fix this for now. It causes all types of issues like causing the media library to not to load.

All you have to do is in wp_shopping_cart.php line: 582 change

parent::WP_Widget('wp_paypal_shopping_cart_widgets', 'WP Paypal Shopping Cart', array('description' => 'WP Paypal Shopping Cart Widget'));

to this

parent::__construct('wp_paypal_shopping_cart_widgets', 'WP Paypal Shopping Cart', array('description' => 'WP Paypal Shopping Cart Widget'));

I changed it and it fixxed all the issues it was causing.

See the codex here

Yeah, these error have been there for years. Are these ever going to be fixed?

Arg, yes. This is also reeking havoc on my WP manager ISync. It’s still shows that the plugin needs updated.

I hope he can get this fixed. It’s a great plugin.

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.

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.

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.

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.