To have to resort to a hack like this to get nav highlighting for a custom post type is ridiculous. Especially when it's a feature that's been requested for 3+ years (http://core.trac.wordpress.org/ticket/16382) and Google is chock full of "How the f*ck do I do this?" results: https://www.google.com/search?q=wp+current_page_parent+cpt&oq=wp+curr…

frustrating.php

<?php

add_filter('nav_menu_css_class', 'namespace_menu_classes', 10, 2);

function namespace_menu_classes($classes , $item)
{
    if (get_post_type() == 'company' || is_archive('company')) {
        $classes = str_replace('current_page_parent', '', $classes);

        if (strpos($item->url, 'portfolio') !== false) {
            array_push($classes, 'current-menu-parent');
        }
    }

    return $classes;
}

Edited to rename the script from obscene.php to frustrating.php. I was tired and angry, and "obscene" was more than a little bit of overkill.

Yeah, that's kind of a pain in the keister. This logic definitely belongs in Walker_Page somewhere, and with Word Camp Orlando coming up, I'm inclined to give it a go. Nothing like having the ears of the core committers to smooth out some janky legacy behavior.

So how would we tell Walker_Page that any given menu item is the parent for any given custom post type?

@al-the-x: I'm not sure what should be done about it. I know very, very little about WordPress internals, which is part of the reason this was so frustrating and why the proposed workaround made no sense to me. I still have no idea if the snippet above is the right way to solve this problem or if the code would be a good candidate for CSI: WordPress. Additionally, the proposed solution is 3+ years old, which translates to about 45 internet years. It seemed reasonable to assume that the comment was so out of date as to not be worth pursuing. Combined with what felt like RTFM responses, I really lost my cool.;

From an outsider's perspective, it seems like the fix would logically go in the custom post type definition.

• I expected 'capability_type' => 'page' to behave like a page rather than a post.
• I expected 'hierarchical' => true combined with page_attributes to allow setting a page parent for the CPT.
  • The behavior of 'hierarchical' => true combined with page_attributes really threw me for a loop
  • If page actually behaved like a page, this entire issue would be moot, since you could set a page as the CPT parent

. . . and with Word Camp Orlando coming up, I'm inclined to give it a go.

That makes me really happy to hear.

I don't know if those comments help or hurt, but that's my 2 cents from the perspective of someone who doesn't know WP core.

capability_type is purely for user/role capabilities — as in, current_user_can(). It specifically says "Yes, use edit_posts and similar," or "Use edit_pages and similar." Or, it can be paired with the capabilities and map_meta_cap flags for more power.

This isn't "a feature that's been requested for 3+ years". It was requested once 3 years ago, and the person who wrote the nav menu API said "nope, it works this other way". After there was no response, I closed out the ticket.

It is important for maintainers to change their minds when presented with good rationale, or generally just better information. If we were mistaken three years ago, then say so! My tweet wasn't a "RTFM", it was an honest "but there's a workaround, it doesn't work?" question. There's no need for passive-aggressive or angry tweets, gists, comments, and the like. We're not trying to make your life more difficult. But if you do, I'm really just not inclined to help at all. Help us help you.

@nacin This is probably just a case of @jeremykendall coming off as less of a nice guy than he actually is... Which is why I don't advocate (angry|tired|drunk) (tweet|cod|driv)ing.

FWIW, the approach you took is about as close to correct as you get. Using a filter hook to remove the unwanted class and inject the desired one isn't beginner Wordpress, so you nailed it. Based on your comments above, the hierarchical is really not what you're looking for unless your type is supposed to have explicit parents, like pages and sub-pages.

To your point, though, and regarding our Twitter discussion, there's definite room for improvement in the Codex and arguably in the convention employed by the Walker class. The decisions to lump custom post types under posts was a left-over from the early days of custom post types, IIRC. In WP, everything that isn't a page is really a post, and pages are just highly specialized posts at that. There really should be a way to tell a NavItem that it's a parent for a custom post type, but I'm not sure where.

For my own personal reference (when I come back to this in a couple of weeks for Word Camp ORL), try out the effect of show_in_nav_menus in the post type definition.