Opened 20 years ago
Closed 14 years ago
#1277 closed enhancement (worksforme)
Extend is_page() to support child_of and decendent_of
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.1 |
Component: | Template | Keywords: | dev-feedback |
Focuses: | Cc: |
Description
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)
Change History (27)
#3
@
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
@
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
@
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?
#7
@
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.
#8
@
18 years ago
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.
#11
@
18 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?
#14
@
18 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...)
- 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:
is_page_child(21)) would return true if the current page is either ID 2, or a child of page 21. |
- 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.
#21
@
16 years ago
- Keywords needs-patch added; dev-feedback 2nd-opinion removed
- Milestone changed from 2.9 to Future Release
This should probably be given consideration.