Fatal Error in taxonomy.php

[miqrogroove]

Call me behind the times, but I'm just starting to work on a 2.9 to 3.0 upgrade. To that end, I needed to confirm that the hierarchical rewrite system was working. I created a one-line plugin to call register_taxonomy(), activated it, and WordPress exploded.

This is now the actual output of any hit to any page on that website:

Fatal error: Call to a member function add_rewrite_tag() on a non-object in wp-includes/taxonomy.php on line 289

/epicfail

Site returned to normal after I purged the plugin file. No other plugins were running. Fresh install of 3.0.1 using Twenty Ten 1.1. I will attach the plugin to this ticket and continue to debug.

[miqrogroove]

This file causes WordPress 3.0.1 to explode :o

[nacin]

Taxonomies and post types need to be registered on init. This is especially true if you need rewriting, as is the case here, because $wp_rewrite isn't set up until then.

#13957

[miqrogroove]

WP needs to check the value of $wp_rewrite instead of crashing?

[hakre]

It's not only that this would be $wp_rewrite. There are some other globals that are used unchecked in functions. In those funcs, on invoke before those vars set, this just gives you fatal errors for those used as objects with function calls.

I tend to say this is by design (no that I like that).

Probably the functions using the global variable should be defined after the variable is set. But this won't change much for your report, you would get a fatal error then on the register_taxonomy function call.

The only Idea I can share to deal with this is to use a mock-object that get's instantiated as the problematic global variables at the very beginning. Per magic methods, they catch all calls and are giving E_USER warnings for logging purposes. The globals are overwritten later, and for some you need to hack core to have this properly working.

Sure, this is nothing for stable, I use it - if at all - for debugging and development purposes.

Similar issues btw. can happen on shutdown of the application, but not that easy to cure.

[miqrogroove]

Another possibility is to set a global init flag so that the functions can assert that prerequisite.

[garyc40]

Why did you reopen the ticket?

It's quite obvious that registering taxonomy and post types should be done on init (i.e. add_action( 'init', 'myplugin_register_stuff' ); , and it's stated else where many times as well.

[miqrogroove]

Replying to garyc40:

Why did you reopen the ticket?

I reopened the ticket because there is a fatal error in WordPress caused by calling register_taxonomy(). Despite the inexplicable reponses posted above, there is no documentation that says this function must be called a certain way. This are the exact instructions, which caused the error in the first place:

Function Reference/register taxonomy

Description
This function adds or overwrites a taxonomy. It takes in a name, an object name that it affects, and an array of parameters. It does not return anything.

Care should be used in selecting a taxonomy name so that it does not conflict with other taxonomies, post types, and reserved WordPress public and private query variables. A complete list of those is described in the Reserved Terms section.

Usage

 <?php register_taxonomy($taxonomy, $object_type, $args); ?> 

[SergeyBiryukov]

Similar: #14024

Perhaps better docs are needed in this case too? I've added a note in Codex for register_taxonomy() about this.

[dd32]

Simple, Don't do it!