Opened 14 years ago
Last modified 7 years ago
#18701 accepted defect (bug)
"hierarchical" argument for get_pages() does nothing
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | 3.0 |
| Component: | Posts, Post Types | Keywords: | |
| Focuses: | Cc: |
Description (last modified by )
The hierarchical argument for get_pages() is never actually used. It is in an if statement, but one that requires child_of to also be set:
if ( $child_of || $hierarchical ) $pages = & get_page_children($child_of, $pages);
Props Vynce Montgomery for pointing this out to me.
Change History (8)
#5
@
10 years ago
Took a look at this the other night.
The truly special part about the current state of get_pages() is that because $hierarchical is true and $child_of is 0|false by default, we actually end up with non-hierarchical results by default because $child_of translates to parent = 0 in get_page_children(). To maintain backward-compatibility, we would have to retain that default behavior
Running two rudimentary tests of current behavior, I got surprising results:
$hierarchical = get_pages( array( 'number' => 10 ) ); $hierarchical = wp_list_pluck( $hierarchical, 'post_parent' ); // 5 pages, all with parent 0 $non_hierarchical = get_pages( array( 'hierarchical' => false, 'number' => 10 ) ); $non_hierarchical = wp_list_pluck( $non_hierarchical, 'post_parent' ); // 10 pages, mixed parents
If we wanted to truly implement hierarchical results, there are a couple of things to consider:
- Like
get_terms(), we should probably only set theLIMITclause if$hierarchical,$child_ofand$parentare falsey and$numberis not empty. Currently it's always set if$numberis not empty (default is empty) - It should be documented what exactly "hierarchical" means in terms of returned results
I think the best starting place is to write tests for the current behavior and work outward.
Somewhat related, I've found afew times that it would be helpful for get_pages() to not enforce hierarchical-ness.