WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#12873 closed defect (bug) (duplicate)

get_pages() may be run before init

Reported by: nacin Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords: dev-feedback
Focuses: Cc:

Description

A friend is using a theme that blew up in 3.0-beta. The theme called get_pages() deep in some options factory before post types were initialized, which causes get_pages() to return false as no (hierarchical) post types were registered.

The theme expected get_pages() to return an array. Our checks for a hierarchical post type and valid post status are both new, and they both would cause get_pages() to return false. Problem is, the results from get_pages() were immediately thrown into a foreach without casting it to an array (it always returned an array previously), which caused an E_WARNING and stopped redirection headers from being sent (i.e. login).

I wanted to ticket this because there's a lot going on here. Simple back compat fix would be to return array() instead of false in get_pages(), but that doesn't help actually return the pages that would have been returned in 2.9.

Change History (3)

comment:1 @nacin5 years ago

One option would be to change:

if ( !in_array( $post_type, $hierarchical_post_types ) )

to:
if ( 'page' != $post_type && !in_array( $post_type, $hierarchical_post_types ) )
}}}

Same with get_post_stati() and 'publish'. Then we can leave the return false and everything else.

Might be a few other places we need to update due to similar API changes, but I'm not sure.

comment:2 @filosofo5 years ago

Wouldn't it make sense to register post types late in "plugins_loaded"?

Then such a factory could do its thing at "setup_theme."

comment:3 @nacin5 years ago

  • Milestone 3.0 deleted
  • Resolution set to duplicate
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.