Minor addition to _page_level_out

[anselm1109]

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.

[markjaquith]

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

[anselm1109]

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 {

display:none;

}

li.current_page_item ul, li.parent_page_item ul {

display:block

}

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.

[janX]

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

[anselm1109]

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.

[FireMotion]

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:
1)

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

[FireMotion]

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

Conditions:

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

[chmac]

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

[chmac]

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

[chmac]

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.

[pishmishy]

Bumping milestone for feature freeze.

[Denis-de-Bernardy]

in trunk, the parents have current_page_ancestor and current_page_parent