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;
}

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