menu selected page class problem

[Angeloverona]

When we set static pages, front page and blog page , and after that we click on blog page, menu will not generate li class "current-menu-item" for blog page so that seems that blog page isn't active(in menu view).

[nacin]

Are you using the latest nightly? (i.e. downloaded in the last 30 minutes)

[Angeloverona]

yes, latest dev (3.0-beta2-14896) blog page i mean as "posts page" of course

[nacin]

Okay, I don't think we added support for static pages. I imagine we should, did wp_page_menu support them?

[Angeloverona]

sry for delay i must tried that and yes, wp_page_menu support them, but wp_nav_menu not.

[nacin]

(In [14923]) Handle current menu item classes for post pages. props filosofo, fixes #13543.

[kpdesign]

Rather than open a new ticket, I've reopened this one, since it is related to this issue.

The patch fixes the OP's issue, but there is still some existing functionality from wp_page_menu() missing.

wp_nav_menu() does not add current_page_parent to the blog link when viewing a single post, a category page, a dated archive page or the search results page.

All of those conditions have current_page_parent added to the blog page link when using wp_page_menu now.

I've tested this patch on 2 different 3.0 dev installs using both 2010 and a theme that I developed, and I am seeing the same behavior (current_page_parent class not being added) in both.

[filosofo]

Replying to kpdesign:

The patch fixes the OP's issue, but there is still some existing functionality from wp_page_menu() missing.

wp_nav_menu() does not add current_page_parent to the blog link when viewing a single post, a category page, a dated archive page or the search results page.

Basically if there's a static home page and the current query is not for another page, wp_page_menu() gives the static home page page the current_page_parent class.

I think that's questionable behavior, but in the interests of backwards compatibility, current_page_parent-back-compat.13543.diff does the same.

[ryan]

(In [14942]) More menu class back compat. Props filosofo. fixes #13543

[Stargater59]

There seems to be some strange behavior with this when combining custom post types and menus.

I'm currently working on two sites under 3.0. On one site I have a "Work" page which uses a custom post type to display "my work", however when viewing a single post under the my work custom post type, the "Work" navbar item doesn't get any "current page" classes.

Note that the above site doesn't have any navbar item for a "blog".

On another site I have 2 custom post types, both of which are not sub-pages of blog, yet when viewing a single post of either of the post types the blog navbar item gets highlighted.

An additional issue is that the second custom post type (Tutorials) is a sub-page of "Resources" and when viewing a single post under the tutorials post type, again the blog menu item gets highlighted, but the Resources does not.

[nacin]

It sounds like your "Work" page is simply a template that uses query_posts or query var manipulation or the like to display the custom posts? In that case, the nav menu walker won't realize that the "Work" page and the my_work custom post type are related in that sort of hierarchy.

We can probably add a filter if we haven't already to the $classes array for each item that passes through.

Again in the second issue you have an issue where the static posts page thinks that it is the parent of the custom post types. I'm not sure if that's a flaw in our logic, I imagine we should only be looking for 'post'.

Third issue is a combination of the first two issues.

[Stargater59]

Yes, in each of the cases above I have in my functions.php file a function which uses wp_query to grab the content out of the custom post type and display it on a custom template.

"single.php" displays single blog posts. "single-work.php" would normally be used by a blog post called "work", but in my case its being used by the "work" post type single posts. But, if I'm understanding correctly, WordPress has no way of distinguishing the difference from normal single-posts and custom single-posts, so "single-work.php" has no way of referencing to where the actual "original source" of the post type is, which in this case is on page-work.php?

If that's the case, then I'm unsure if there's an alternative/better way of handling this?

[nacin]

WordPress doesn't really have a way of knowing what your templates are doing, at least not much more than what we're already detecting.

Of note, single-work.php is not for the blog post called "work," it is specifically for the post type called "work." The template hierarchy only has single-$posttype.php and single.php for single templates currently. Pages and attachments both have more; we'll likely revisit in 3.1.

There's a nav_menu_css_class filter, so closing as fixed.

[nacin]

It occurred to me that we didn't mention the special property of a custom link menu item. WordPress does a URL comparison and marks them as current-menu-item if they match.

This doesn't work for hierarchy (no parent etc. classes) but in some cases can provide you what you need or can lead you in a direction for the hook.