Extend is_page() to support child_of and decendent_of

This should probably be given consideration.

multiple functions: is_child_of_page, is_decendent_of_page. (backward compatible)

My favorit would be the extension of is_page. Please comment on the patches.

forgot: for 1277_is_page.diff is_page would be called like is_page('id=3') or is_page('descendent_of=3') or even is_page('id=3&descendent_of=3'), which would OR both queries.

is_page supports: id, child_of, descendent_of, parent_of, ancestor_of.

$results = $wpdb->get_results("SELECT ID, post_parent FROM $wpdb->posts WHERE post_type = 'page'");

I don't like the scalability implications of this.

Can you not switch the patch to do specific queries for the different request types so as to ensure that the SQL request is bounded small enough?

This may make decendent_of stuff harder to work out - can it use any of the walker classes that exist as well?

Either needs-patch or has-patch ;-)

Scalability: Ok, I changed it a bit, now you only get that query if you really need it (descendent_of, ancestor_of), and parent_of has its own query now. Anyhow, that query isn't expensive (at least for < 500 pages and espacally in contrast to the query for get_pages()), the other option would be to do n queries (n = depth) or do some very tricky SQL substatements (which would kill all MySQL 4 support). (Could it be better to use get_pages() since it is/could be cached?)

Walker Classes: Why? I don't really walk the tree, it's more like zipping through a list.

Unless I'm mistaken, this patch kills backwards compatibility for:

is_page(1)

is_page('about')

You should move that old code above your parse_str() call, so those still work.

Matching by name/slug of descendants or ancestors would be nice, but at least keep current capabilities implemented.

Now backward compatible

Ok, it is now backward compatible. Hope you like it now. :)

+1. But maybe a variable/argument to turn on/off returning true if it's a child/parent page?

I've got two methods to tackling this. (Well, 3, since one can be done in two ways...)

1. Seperate functions. You can call is_page() to know if that page is the current page, and then also call is_page_child() to find out whether the current page is a child of X page. Also, is_page_descendant(). So, example:

if (is_page(2) is_page_child(21)) would return true if the current page is either ID 2, or a child of page 21.

2. An argument to achieve the same as method 1. Either have a single is_page() argument that can be either what it is now (ID, page title, etc.), but can also be a query string so you can return true also if it's a child or descendant of another page. The other way of doing this is just having separate arguments.

I'm torn.

Bumping milestone for feature freeze.