Make WordPress Core

Opened 19 years ago

Closed 13 years ago

#1277 closed enhancement (worksforme)

Extend is_page() to support child_of and decendent_of

Reported by: astorm's profile astorm Owned by: westi's profile westi
Milestone: Priority: normal
Severity: normal Version: 2.1
Component: Template Keywords: dev-feedback
Focuses: Cc:


To be able to identify whether a page is child_of another page or a decendent_of another page.

Let's say I have a bunch of pages that has "Articles" page (id=3) as the parent. I use is_page('child_of=3') in my menu/navigation system to highlight that section.

Attachments (3)

1277_seperate_functions.diff (1.6 KB) - added by leflo 18 years ago.
multiple functions: is_child_of_page, is_decendent_of_page. (backward compatible)
1277_is_page.diff (2.2 KB) - added by leflo 18 years ago.
1277_is_page.2.diff (2.5 KB) - added by leflo 18 years ago.
Now backward compatible

Download all attachments as: .zip

Change History (27)

#1 @astorm
19 years ago

  • Patch set to No

#2 @markjaquith
19 years ago

  • Keywords bg|needs-patch added

This should probably be given consideration.

18 years ago

multiple functions: is_child_of_page, is_decendent_of_page. (backward compatible)

#3 @leflo
18 years ago

  • Keywords has-patch added
  • Milestone set to 2.1

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

#4 @leflo
18 years ago

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.

#5 @westi
18 years ago

$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?

#6 @foolswisdom
18 years ago

  • Keywords bg|needs-patch removed

Either needs-patch or has-patch ;-)

#7 @leflo
18 years ago

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.

18 years ago

#8 @markjaquith
18 years ago

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



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.

18 years ago

Now backward compatible

#9 @leflo
18 years ago

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

#10 @matt
18 years ago

  • Milestone changed from 2.1 to 2.2

#11 @rob1n
17 years ago

  • Keywords dev-feedback added
  • Owner changed from anonymous to rob1n
  • Status changed from new to assigned
  • Version changed from 1.5.1 to 2.1

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

#12 @rob1n
17 years ago

  • Owner rob1n deleted
  • Status changed from assigned to new

#13 @rob1n
17 years ago

  • Owner set to rob1n
  • Status changed from new to assigned

#14 @rob1n
17 years ago

  • Keywords 2nd-opinion added; has-patch removed

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.
  1. 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.

#15 @rob1n
17 years ago

  • Owner rob1n deleted
  • Status changed from assigned to new

#16 @foolswisdom
17 years ago

  • Milestone changed from 2.2 to 2.3

#17 @foolswisdom
17 years ago

  • Milestone changed from 2.3 to 2.4 (next)

#18 @santosj
17 years ago

  • Component changed from General to Template

#19 @westi
17 years ago

  • Owner set to westi
  • Status changed from new to assigned

#20 @pishmishy
16 years ago

  • Milestone changed from 2.5 to 2.6

Bumping milestone for feature freeze.

#21 @Denis-de-Bernardy
15 years ago

  • Keywords needs-patch added; dev-feedback 2nd-opinion removed
  • Milestone changed from 2.9 to Future Release

#22 @bryan868
15 years ago

Should this also include an is_subpage tag?

#23 @solarissmoke
13 years ago

  • Keywords dev-feedback added; needs-patch removed

Four years later... anyone still wants to see this happen? We now have get_ancestors() which I think lets you do what the original report was asking for.

#24 @SergeyBiryukov
13 years ago

  • Milestone Future Release deleted
  • Resolution set to worksforme
  • Status changed from accepted to closed

As solarissmoke pointed out, it's now possible to use get_ancestors().

Note: See TracTickets for help on using tickets.