Make WordPress Core

Opened 10 years ago

Closed 6 years ago

Last modified 6 years ago

#2395 closed enhancement (fixed)

Minor addition to _page_level_out

Reported by: anselm1109 Owned by: markjaquith
Milestone: 2.8 Priority: normal
Severity: trivial Version: 2.0
Component: Template Keywords: has-patch
Focuses: Cc:


By inserting the included code on line 416 in template-functions-post.php, we can increase the styling capability of the wp_list_pages() template tag. This adds a class for parent li's which makes more advanced navigation styles possible.

if ( $page_id == $queried_obj->post_parent )

$css_class .= ' parent_page_item';

I would love it if someone can make help to expand this so that it can recognize more than one level of sub pages.

Attachments (2)

classes.php.diff.nolevel (3.0 KB) - added by chmac 8 years ago.
Patch to add class = parent to all parents recursively without adding the new parent level class
classes.php.diff (3.2 KB) - added by chmac 8 years ago.
Patch to add class = parent to all parents recursively AND add the new parent level class

Download all attachments as: .zip

Change History (16)

comment:1 @markjaquith10 years ago

  • Owner changed from anonymous to markjaquith
  • Status changed from new to assigned

Can't you do ul li {} ul li li {} ul li li li {} etc?

comment:2 @anselm110910 years ago

Yes you can, however adding the class definition allows for advanced css formatting. The site I'm working isn't live so I can't give you a link to see it, but here is the basic idea.

I've got child pages and only want to show them when their parent page, or they themselves, are the currently active page. I don't want to create a specific template for each of these pages since this defeats ease of adding pages.

So my style sheet defines the following

li.page_item ul {



li.current_page_item ul, li.parent_page_item ul {



This way the child ul only shows when the currently active page is the parent page or one of the child pages themseleves. It effectively makes a drop down list.

By making it recursive so that each parent page would be labeled, (parent_page_item, parent_page_item1 or something) This would support multiple levels of child pages.

I'm sure there would be other uses for this as well.

comment:3 @janX10 years ago

I just found this ticket. There is as a similar solution that I have proposed today which covers categories as well: http://trac.wordpress.org/ticket/2437

comment:4 @anselm110910 years ago

Jan X

Thanks I hadn't gotten as far as needing to do this with categories, but it makes sense. I like your choice of CSS classes better than mine too. Hopefully we can get this into the main WP distribution.

comment:5 @FireMotion9 years ago

  • Milestone set to 2.1
  • Severity changed from normal to trivial

Currently in Internet Explorer (6.0), if you define: ul li {} then any following ul li li {} or ul li li li {} doesn't work, it gets whatever is defined under ul li {} (because IE processes this as: any li that is contained within ul, even if nested within other tags).

In other good browsers you can use ul>li {} then ul>li>ul>li to get the correct results (this is processed as: the li that is contained within ul but not enclosed within other tags).

Back to the problem
#2437 seems like a solution, but it only covers current items: it adds a class for the parent whenever a child is active. A combination of these two tickets would be better indeed:

* page_item page_item_top
  * page_item
  * page_item
* page_item page_item_top current_page_item_top
  * page_item current_page_item
  * page_item
  * page_item
* page_item page_item_top
* page_item page_item_top

I called them top because these are the top items/parents. This, however, poses a problem. If there are sub-sub-items, what whould happen:

* page_item page_item_top
  * page_item page_item_parent
    * page_item page_item_parent
      * page_item

or 2)

* page_item page_item_top
  * page_item page_item_top
    * page_item page_item_top
      * page_item

or 3) (preferred)

* page_item page_item_top
  * page_item
    * page_item
      * page_item

Furthermore, if the function is called, and asked only to get child nodes of a parent, should the top node get the page_item_top class (it's not the real top item, but it's the sub-item of the node that is asked for)?

Customization through parameters seems preferred (through wp_list_pages): page_item_top= or page_item_parent= and current_item_top= or current_page_item_parent=.

In addition, fixing this ticket would obsolete #2364.

comment:6 @matt9 years ago

  • Milestone changed from 2.1 to 2.2

comment:7 @foolswisdom9 years ago

  • Milestone changed from 2.2 to 2.3

comment:8 @FireMotion8 years ago

See also ticket #3253, which fixes this (using current_page and current_page_parent) except for the following case:


  • The page in question is excluded from the menu
  • The page in question IS a child of one of its (visible/not-excluded) parent menu items/pages

The parent class current_page_parent is not shown in this case.

comment:9 @foolswisdom8 years ago

  • Milestone changed from 2.3 to 2.5 (future)

@chmac8 years ago

Patch to add class = parent to all parents recursively without adding the new parent level class

@chmac8 years ago

Patch to add class = parent to all parents recursively AND add the new parent level class

comment:10 @chmac8 years ago

  • Cc chmac added

I've added two patches (against source:trunk/wp-includes/classes.php@6021). The first one adds a recursive function and adds class="current_page_parent" and class="current-cat-parent" to all parents (including grandparents, great-grandparents etc) of the current page or category.

The second patch includes the first one, but also adds a new class="current_page_parent_lN" and class="current-cat-parent-lN" where N is the number of levels above the current page, from 0 upwards. For example, current_page_parent_l0 means the current page, current-cat-parent-l1 means the current category's parent, current_page_parent_l2 means the current page's grandparent, and so on.

I also propose to change the milestone to 2.4 now that a patch is available. I'll discuss this on the wp-hackers mailing list.

comment:11 @Nazgul8 years ago

  • Keywords has-patch added
  • Milestone changed from 2.5 (future) to 2.4 (next)

comment:12 @pishmishy8 years ago

  • Milestone changed from 2.5 to 2.6

Bumping milestone for feature freeze.

comment:13 @Denis-de-Bernardy6 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

in trunk, the parents have current_page_ancestor and current_page_parent

comment:14 @mtekk6 years ago

  • Milestone changed from 2.9 to 2.8
Note: See TracTickets for help on using tickets.