Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I'm creating a theme with a custom post type for team members, I've also got the following page structure:

about  <-- this is a page
about/team-members  <-- this is a page, lists all the team members
about/team-members/joe-bloggs  <-- this is a custom post type (team member) entry

The third structure here uses the about and team member pages, but goes on to use the custom post type slug to make it look like it's parents are team member and about. I've achieved this by setting the following options on the custom post type:

...
'rewrite' => array( 'slug' => 'about/team-members', 'with_front' => false)
...

This works great, however when I get down to the team member post level I no longer get the current-page, current-ancestor classes on the parent pages. I know why this is, because we're not technically on a pagea parent of those pages, however is there a way I can trick/fix/bodge so the pages DO apear as parents?

I had achieved this nicely by using pages for team members, however a custom post type was chosen instead for easy of use for the administrator.

Thanks guys + girls!

share|improve this question

This question had a bounty worth +150 reputation from ndm that ended 16 hours ago. Grace period ends in 7 hours

The question is widely applicable to a large audience. A detailed canonical answer is required to address all the concerns.

While assigning a parent of a different type is rather simple and explained in the answer of @Bainternet, the following problem is unsolved: The parent page hierachy is not being reflected in the navigation menu, instead it will always mark the default posts page as active (and only that one single page, not its parents - this is identical to the behavior with post post types).

    
you need to set team-members page id as your custom post type post_parent. –  Bainternet Mar 28 '11 at 18:41
    
I don't see that option in the register_post_type documentation, can you assist? –  Ben Everard Mar 28 '11 at 19:00

6 Answers 6

When Working with pages you can select a parent page and that value is saved as the parent page id number in the child page's post_parent field in the database.

in your case you are using a custom post type so you would need to create your own metabox for the parent page , something like:

/* Define the custom box */
add_action('add_meta_boxes', 'child_cpt_add_custom_box');

/* Adds a box to the main column on the custom post type edit screens */
function child_cpt_add_custom_box() {
    add_meta_box('child_cpt', __( 'My child_cpt parent'),'team_member_inner_custom_box','team_member');
}

/* Prints the box content */
function team_member_inner_custom_box() {
    global $post;
    // Use nonce for verification
    wp_nonce_field( plugin_basename(__FILE__), 'team_member_inner_custom_box' );
    echo 'Select the parent page';
    $mypages = get_pages();
    echo '<select name="cpt_parent">';
    foreach($mypages as $page){     
        echo '<option value="'.$page->ID.'"';
        if ($page->ID == $post->post_parent) {echo ' selected';}
        echo '>"'.$page->post_title.'</option>';
    }
    echo '</select>';
}
/* Do something with the data entered */
add_action('wp_insert_post_data', 'myplugin_save_postdata');

/* When the post is saved, saves our custom data */
function myplugin_save_postdata( $data, $postarr ) {
    global $post;
      // verify this came from the our screen and with proper authorization,
      // because save_post can be triggered at other times

      if ( !wp_verify_nonce( $_POST['team_member_inner_custom_box'], plugin_basename(__FILE__) ) )
          return $data;

      // verify if this is an auto save routine. 
      // If it is our form has not been submitted, so we dont want to do anything
      if ( defined('DOING_AUTOSAVE') && DOING_AUTOSAVE ) 
          return $data;
      // OK, we're authenticated: we need to find and save the data

      if ($post->post_type == "team_member")
          $data['post_parent'] = $_POST['cpt_parent'];

     return $data;
}

it has nothing to do with register_post_type you are "tricking WordPress to thing that this is a child page of another post type (page). let me know if this helps.

share|improve this answer
1  
Righto, so I can see how this "fools" WordPress to think a specific page is it's parent, however it's not adding the page parent class to the parent page when I wp_list_pages. –  Ben Everard Mar 28 '11 at 21:11
1  
I've noticed this also messes with my slug / permalink structure... :S –  Ben Everard Mar 29 '11 at 19:52
2  
i'm trying to achieve the same thing as Ben but i use wp_nav_menu - the post_parent is about/team-members but the navigation highlights the parent item of my "normal" blog posts ... any other idea how i could fix this? –  pkyeck Oct 10 '11 at 14:05
    
@BenEverard: Did you find a solution for the permalink structure mess? –  abaumg Nov 15 '11 at 22:05

I went with a custom walker to achieve something similar... avoids needs for custom fields, but all posts of a type have to sit below the same point in the page tree.

class Walker_Page_CustomPostTypeHack extends Walker_Page {
    function walk($elements, $max_depth) {
        $called_with = func_get_args();
        // current page is arg 3... see walk_page_tree for why
        $current_page = $called_with[3];

        // if there's no parent - see if we can find one.
        // some ACF options would be an easy way to make this configurable instad of constants
        if ($current_page === 0) {
            global $wp_query;
            $current_post = $wp_query->get_queried_object();
            switch ($current_post->post_type) {
                case 'course':
                    $current_page = POST_COURSES;
                    break;
                case 'project':
                    $current_page = POST_PROJECTS;
                    break;
                case 'story':
                    $current_page = POST_STORIES;
                    break;
            }
        }

        // now pass on into parent
        $called_with[3] = $current_page;
        return call_user_func_array(array('parent', 'walk'), $called_with);
    }

}
share|improve this answer

Disclaimer: After giving it a try this seems a not longer existing problem to me, because - at least for me - it just works on my WP 3.9.2 installation. Couldn't find a according bug tracker though.


I have out together a little plugin to test this, which might help someone. But like I said in above disclaimer, I couldn't reproduce the problem in a current wordpress installation. I've separated the plugin into four files, they are going together into one directory inside the plugin directory.

plugin-cpt_menu_hierarchy.php:

<?php
defined( 'ABSPATH' ) OR exit;
/**
 * Plugin Name: CPT Menu Hierarchy Fix?
 * Description: CPT Menu Hierarchy Fix?
 * Author:      ialocin
 * Author URL:  http://wordpress.stackexchange.com/users/22534/ialocin
 * Plugin URL:  http://wordpress.stackexchange.com/q/13308/22534
 */

// registering nonsense post type
include 'include-register_post_type.php';

// adding meta box to nosense custom post type
include 'include-cpt_parent_meta_box.php';

// menu highlighting fix
include 'include-menu_highlighting.php';

include-register_post_type.php:

<?php
defined( 'ABSPATH' ) OR exit;

// See: http://codex.wordpress.org/Function_Reference/register_post_type
add_action( 'init', 'wpse13308_basic_reigister_post_type');
function wpse13308_basic_reigister_post_type() {
    $args = array(
        'public' => true,
        'label'  => 'Nonsense'
    );
    register_post_type( 'nonsense', $args );
}

include-cpt_parent_meta_box.php:

<?php
defined( 'ABSPATH' ) OR exit;

// pretty much like @bainternet's answer

// Add Meta Box
add_action( 'add_meta_boxes', 'nonsense_add_meta_box' );
function nonsense_add_meta_box() {
    add_meta_box(
        'nonsense',
        __( 'Nonsense parent' ),
        'nonsense_inner_meta_box',
        'nonsense'
    );
}

// Meta Box Content
function nonsense_inner_meta_box() {
    global $post;

    wp_nonce_field(
        plugin_basename( __FILE__ ),
        'nonsense_inner_meta_box'
    );
    echo 'Parent Page:&nbsp;&nbsp;';
    $mypages = get_pages();
    echo '<select name="cpt_parent">';
    foreach($mypages as $page){     
        echo '<option value="'.$page->ID.'"';
        if ($page->ID == $post->post_parent) {echo ' selected';}
        echo '>'.$page->post_title.'</option>';
    }
    echo '</select>';
}

// Save Data From Meta Box
add_action( 'wp_insert_post_data', 'nonsense_save_meta_box_data' );
function nonsense_save_meta_box_data( $data, $postarr ) {
    global $post;

    if (
        ! wp_verify_nonce(
            $_POST['nonsense_inner_meta_box'],
            plugin_basename( __FILE__ )
        )
    ) {
        return $data;
    }

    if (
        defined('DOING_AUTOSAVE')
        && DOING_AUTOSAVE
    ) {
        return $data;
    }

    if ( $post->post_type == 'nonsense' ) {
        $data['post_parent'] = $_POST['cpt_parent'];
    }
    return $data;
}

include-menu_highlighting.php:

<?php
defined( 'ABSPATH' ) OR exit;

// altering WordPress' nav menu classes via »nav_menu_css_class« filter
add_filter( 'nav_menu_css_class', 'wpse13308_fix_nav_menu_highlighting', 10, 2 );
function wpse13308_fix_nav_menu_highlighting( $classes, $item ) {
    // data of the current post
    global $post;

    // setting up some data from the current post
    $current_post_post_type = $post->post_type;
    $current_post_parent_id = $post->post_parent;
    // id of the post the current menu item represents
    $current_menu_item_id   = $item->object_id;

    // do this for a certain post type
    if( $current_post_post_type == 'nonsense' ) {
        // remove unwanted highlighting class via array_filter and callback
        // http://php.net/manual/de/function.array-filter.php
        $classes = array_filter(
            $classes,
            'wpse13308_remove_highlighting_classes'
        );
        // when the parents id equals the menu items id, we want to
        // highlight the parent menu item, so we check for:
        if( $current_post_parent_id == $current_menu_item_id ) {
            // use the css class used for highlighting
            $classes[] = 'replace-with-css-class';
        }
    }
    return $classes;
}

// callback to remove highlighting classes
function wpse13308_remove_highlighting_classes( $class ) {
    return
        (
            // use the class(es) you need, overview over nav menu item css classes:
            // http://codex.wordpress.org/Function_Reference/wp_nav_menu#Menu_Item_CSS_Classes
            $class == 'highlight-class'
            // uncomment next line if you want to check for more then one class
            // repeat the line if you want to check for a third, fourth and so on
            // || $class == 'replace-with-css-class'
        ) 
        ? false
        : true
    ;
}



  • This is a somewhat generalized code example.
  • It has to be fitted to the actual use case.
share|improve this answer

A possible solution is whenever the custom post type is saved, you can set its' parent to be about/team-members prgrammatically.

Here are the steps:

  1. You can use the save_post hook to 'catch' whenever someone tries to save a post.
  2. If that post is the custom post type you are after, then proceed.
  3. Make sure to set the custom post's parent to the page you want (you can hard-code the page ID as long as you do not delete it). You can use wp_update_post to save the parent (I haven't tried this myself, but I don't see why it shouldn't work).
share|improve this answer

I had some more time to dig into this myself (sorry if I wasted anyone's time), and I figured that for me, the best way to solve the highlighting problem would be to kinda re-do what _wp_menu_item_classes_by_context() is doing, that is iterate over all parents and ancestors of the menu item that acts as the parent of my custom post type, and add classes appropriately.

Since I also wanted to have the parent page for my custom post type fixed, and easily changeable without having to update all posts once the parent changes, I've decided to use an option instead of populating the post_parent field of my custom post type posts. I've used ACF for that since I'm using it in my theme anyways, but using the default WordPress option functionality would of course do it too.

For my needs I could make use of the wp_nav_menu_objects filter. Additionally I had to filter the page_for_posts option so that it returns a falsely/empty value, this avoids the default posts page to be highlighted too.

Note that I didn't go all the way, the filter only adds the current-menu-ancestor and current-menu-parent classes, as this was enough for my needs!

/**
 * Filters the `page_for_posts` option on specific custom post types in
 * order to avoid the wrong menu item being marked as
 * `current-page-parent`.
 *
 * @see _wp_menu_item_classes_by_context()
 */
function wpse13308_pre_option_page_for_posts_filter()
{
    $types = array
    (
        'my_custom_post_type_x',
        'my_custom_post_type_y',
        'my_custom_post_type_z'
    );
    if(in_array(get_post_type(), $types))
    {
        return 0;
    }
    return false;
}
add_filter('pre_option_page_for_posts', 'wpse13308_pre_option_page_for_posts_filter');


/**
 * Returns the current posts parent page ID
 *
 * @return int
 */
function wpse13308_get_parent_page_id()
{
    $postType = get_post_type();
    $parentPageId = null;
    switch($postType)
    {
        case 'my_custom_post_type_x':
        case 'my_custom_post_type_y':
        case 'my_custom_post_type_z':
            $parentPageId = (int)get_field('page_for_' . $postType, 'options')->ID;
            break;

        case 'post':
            $parentPageId = (int)get_option('page_for_posts');
            break;
    }
    return $parentPageId;
}

/**
 * Adds proper context based classes so that the parent menu items are
 * being highlighted properly for custom post types and regular posts.
 *
 * @param array $menuItems
 * @return array
 *
 * @see _wp_menu_item_classes_by_context()
 */
function wpse13308_wp_nav_menu_objects_filter(array $menuItems)
{
    $parentPageId = wpse13308_get_parent_page_id();

    if($parentPageId !== null)
    {
        $activeAncestorItemIds = array();
        $activeParentItemIds = array();
        foreach($menuItems as $menuItem)
        {
            if((int)$parentPageId === (int)$menuItem->object_id)
            {
                $ancestorId = (int)$menuItem->db_id;

                while
                (
                    ($ancestorId = (int)get_post_meta($ancestorId, '_menu_item_menu_item_parent', true)) &&
                    !in_array($ancestorId, $activeAncestorItemIds)
                )
                {
                    $activeAncestorItemIds[] = $ancestorId;
                }
                $activeParentItemIds[] = (int)$menuItem->db_id;
            }
        }
        $activeAncestorItemIds = array_filter(array_unique($activeAncestorItemIds));
        $activeParentItemIds = array_filter(array_unique($activeParentItemIds));

        foreach($menuItems as $key => $menuItem)
        {
            $classes = $menuItems[$key]->classes;
            if(in_array(intval($menuItem->db_id), $activeAncestorItemIds))
            {
                $classes[] = 'current-menu-ancestor';
                $menuItems[$key]->current_item_ancestor = true;
            }

            if(in_array($menuItem->db_id, $activeParentItemIds))
            {
                $classes[] = 'current-menu-parent';
                $menuItems[$key]->current_item_parent = true;
            }

            $menuItems[$key]->classes = array_unique($classes);
        }
    }

    return $menuItems;
}
add_filter('wp_nav_menu_objects', 'wpse13308_wp_nav_menu_objects_filter');

For the sake of completeness, when populating post_parent (see @Bainternet's answer) instead of using options, then retrieving the parent ID could look something like this:

/**
 * Returns the current posts parent page ID
 *
 * @return int
 */
function wpse13308_get_parent_page_id()
{
    $parentPageId = null;
    $post = get_post();
    switch($post->post_type)
    {
        case 'my_custom_post_type_x':
        case 'my_custom_post_type_y':
        case 'my_custom_post_type_z':
            $parentPageId = (int)$post->post_parent;
            break;

        case 'post':
            $parentPageId = (int)get_option('page_for_posts');
            break;
    }
    return $parentPageId;
}
share|improve this answer
    
You haven't wasted my time :) Another thing, are sure this is still a problem? Because on my WP 3.9.2 installation I couldn't reproduce it. Highlighting the correct menu item worked just out of the box. –  ialocin Aug 26 at 16:36
    
Yep, it's definitely still a problem @ialocin. Could it be that you are testing this with a 0 level menu and the default post type? –  ndm Aug 26 at 17:22
    
No, tried it with the code posted in my answer. So with a custom post type and as 1st and 2nd level menu item to a page from the according post type. I used the wordpress core bundled themes to test it. –  ialocin Aug 26 at 17:30
    
@ialocin Not sure if I understand you correctly, because "tried with the code posted" and "out of the box" are kinda mutually exclusive? ;) Are you only referring to the custom post type, not the highlighting fix? –  ndm Aug 26 at 17:36
    
Right :) Ok, to be precise, for the scenario a CPT is needed, so of course I registered it. Highlighting works without the use of the meta box and the highlighting fix. For example with a menu structure: grandparent (page) > parent (page) > something (post) > another-thing (cpt) > one-more-thing (cpt) - every element get the correct css class(es); theme used here twenty thirteen. –  ialocin Aug 26 at 17:50
<?php
the_post();

// $postType holds all the information of the post type of the current post you are viewing
$postType = get_post_type_object(get_post_type());

// $postSlug is the slug you defined in the rewrite column: about/team-members
$postSlug = $postType->rewrite['slug'];

// $datas = { [0] => 'about', [1] => 'team-members' }
$datas = explode('/', $postSlug);

// $pageSlug = 'about'
$pageSlug = $datas[0];

// all the page information you require.
$page = get_page_by_path($pageSlug, OBJECT, 'page');
?>

http://codex.wordpress.org/Function_Reference/get_post_type_object http://codex.wordpress.org/Function_Reference/get_page_by_path

share|improve this answer
2  
This doesn't seem to be related to the question in any way. –  ndm Aug 26 at 17:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.