Make WordPress Core

Opened 13 years ago

Closed 12 years ago

#15568 closed defect (bug) (invalid)

Fatal Error in taxonomy.php

Reported by: miqrogroove's profile miqrogroove Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0.1
Component: Taxonomy Keywords:
Focuses: Cc:


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


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.

Attachments (1)

taxonomy-test-plugin.php (677 bytes) - added by miqrogroove 13 years ago.
This file causes WordPress 3.0.1 to explode :o

Download all attachments as: .zip

Change History (10)

13 years ago

This file causes WordPress 3.0.1 to explode :o

#1 @nacin
13 years ago

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

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.


#2 @nacin
13 years ago

  • Severity changed from blocker to normal

#3 @miqrogroove
13 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

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

#4 @hakre
13 years ago

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.

#5 @miqrogroove
13 years ago

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

#6 follow-up: @garyc40
12 years ago

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.

#7 in reply to: ↑ 6 @miqrogroove
12 years ago

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

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.


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

#8 @SergeyBiryukov
12 years ago

Similar: #14024

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

#9 @dd32
12 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

Simple, Don't do it!

Note: See TracTickets for help on using tickets.