[Plugin: Breadcrumb NavXT] Custom post type support

It is in the SVN Trunk right now, will be released as part of 3.7.0 on Monday, November 29th.

Let’s say you have a post type named “Run”, and you have a custom taxonomy named “Route”. Now, WordPress usually thinks, for a ‘normal’ blog that your hiearchy is as so:

Blog > Route instance(s) > Run instance

When you may actually want these to sit under a page named “Runs”:

Blog > Runs > Route instance(s) > Run instance

The “Runs Root Page” Breadcrumb NavXT lets you do this, if it is set to the page “Runs” for this example. That is in essence what the post_type Root Page setting does.

Thanks for the plugin!
I changed some lines to match my own needs – i don’t need custom post root feature as it’s implemented. My custom post type root is a custom rewrite rule, not existent page. So I changed

line 748:

/*$breadcrumb = $this->add(new bcn_breadcrumb(get_the_title($posts_id), $this->opt['post_page_prefix'],
					$this->opt['post_page_suffix']));*/
				$breadcrumb = $this->add(new bcn_breadcrumb( $wp_post_types[$type->post_type]->labels->name, $this->opt['post_page_prefix'],
					$this->opt['post_page_suffix']));

and line 758:

//$breadcrumb->set_anchor($this->opt['blog_anchor'], get_permalink($posts_id));
					$breadcrumb->set_anchor($this->opt['blog_anchor'], get_option('home') . '/' . $wp_post_types[$type->post_type]->rewrite['slug'] . '/');

Well it’s a dirty hack, you have to set some page as a root.

I have a little hack/workaround that seems to be working for displaying breadcrumbs with Custom Post Type Archive pages (3.1+).

I want to get my breadcrumb looking like this:
Home > Custom Post Type Archive > Custom Post Type Single

However, natively the plugin only generates this:
Home > Custom Post Type Single

The caveat is that you’re allowed to manually select a page as a “root”. This is where you can trick the plugin into displaying your custom post archive page as part of the breadcrumb.

Say for instance my custom post archive URL is https://www.site.com/albums/. To get this archive to show up in the breadcrumbs, I just created a page to “mimic” this URL called “albums”, and set its permalink to the exact same thing. That way, I’m allowed to select that page as a breadcrumb root — yet when the page is actually rendered, it generates the Custom Post Type Archive that lives at the same URL, not the dummy page.

Not saying this is a good idea, but it works for me!

Hi,

In order to replace post-type id by post-type name :

Replace in breadcrumb_navxt_class.php, line 645

$term->name = apply_filters('get_' . $term->taxonomy, $term->name);

By

if ($term->name == '<<< YOUR POST TYPE HERE >>>') {
	$term->name = apply_filters('get_' . $term->taxonomy, $term->labels->name);
} else {
	$term->name = apply_filters('get_' . $term->taxonomy, $term->name);
}

Cool feature to add :

• Select display name of custom post type (with labels or free input)
• Auto generate root link (with slug name or free input)

Regards

What version of Breadcrumb NavXT are you using? Line 645 of breadcrumb_navxt_class.php on the latest release is:

if(is_paged() && $this->opt['paged_display'])

Which is within the do_archive_by_term_flat function. Where is the provided code actually supposed to go?

Assuming it is supposed to go on like 640, then I believe you may be misunderstanding what is available in the $term variable. This is a dump from a custom taxonomy term:

object(stdClass)#274 (9) {
  ["term_id"]=>
  string(2) "18"
  ["name"]=>
  string(9) "Somewhere"
  ["slug"]=>
  string(9) "somewhere"
  ["term_group"]=>
  string(1) "0"
  ["term_taxonomy_id"]=>
  string(2) "18"
  ["taxonomy"]=>
  string(5) "route"
  ["description"]=>
  string(0) ""
  ["parent"]=>
  string(1) "0"
  ["count"]=>
  string(1) "1"
}

I have also checked this for the built in WordPress taxonomies, with similar results. From this, I can conclude that $term->labels->name does not exist for terms (in fact it is a taxonomy property, not a term property).

Auto generate root link (with slug name or free input

This is in the works for the next feature adding release (either 3.9 or 4.0).

Select display name of custom post type (with labels or free input)

Will consider this, but the custom post type name should already be valid for the type (if not, then it really should be redefined).

Hi, thanks you for your answer.

Something strange is that it’s not a term or taxonomy but a custom post type :

register_post_type('bpiw',
		array(
			'labels' => array(
				'name' => __('Liste des bons plans'),
				'singular_name' => __('Bon plan'),
				'add_new_item' => __('Ajouter un bon plan'),
				'add_new' => __('Ajouter un bon plan'),
				'new_item' => __('Bon plan'),
				'edit_item' => __('Modifier un bon plan'),
				'view_item' => __('Voir un bon plan'),
                'search_items' => __('Rechercher des bons plan'),
                'not_found' => __('Aucun bon plan'),
                'not_found_in_trash' => __('Aucun bon plan dans la corbeille'),
				'parent_item_colon' => __('')
			),
			'show_ui' => true,
			'public' => true,
			'query_var' => true,
			'_builtin' => false,
			'hierarchical' => false,
			'rewrite' => array('slug' => 'bons-plans'),
			'supports' => array('title', 'editor'),
			'has_archive' => 'bons-plans'
		)
	);

Maybe i’m doing something wrong… I’m using version 3.8.1, i guess this is the latest one ?

Ok… in trunk, this is on line 640. Here is the var_dump of $terms :

object(stdClass)#4831 (25) {
  ["labels"]=>
  object(stdClass)#4833 (12) {
    ["name"]=>
    string(20) "Liste des bons plans"
    ["singular_name"]=>
    string(8) "Bon plan"
    ["add_new"]=>
    string(19) "Ajouter un bon plan"
    ["add_new_item"]=>
    string(19) "Ajouter un bon plan"
    ["edit_item"]=>
    string(20) "Modifier un bon plan"
    ["new_item"]=>
    string(8) "Bon plan"
    ["view_item"]=>
    string(16) "Voir un bon plan"
    ["search_items"]=>
    string(24) "Rechercher des bons plan"
    ["not_found"]=>
    string(14) "Aucun bon plan"
    ["not_found_in_trash"]=>
    string(32) "Aucun bon plan dans la corbeille"
    ["parent_item_colon"]=>
    string(0) ""
    ["menu_name"]=>
    string(20) "Liste des bons plans"
  }
  ["description"]=>
  string(0) ""
  ["publicly_queryable"]=>
  bool(true)
  ["exclude_from_search"]=>
  bool(false)
  ["capability_type"]=>
  string(4) "post"
  ["map_meta_cap"]=>
  bool(true)
  ["_builtin"]=>
  bool(false)
  ["_edit_link"]=>
  string(16) "post.php?post=%d"
  ["hierarchical"]=>
  bool(false)
  ["public"]=>
  bool(true)
  ["rewrite"]=>
  array(4) {
    ["slug"]=>
    string(10) "bons-plans"
    ["with_front"]=>
    bool(true)
    ["pages"]=>
    bool(true)
    ["feeds"]=>
    bool(true)
  }
  ["has_archive"]=>
  string(10) "bons-plans"
  ["query_var"]=>
  string(4) "bpiw"
  ["register_meta_box_cb"]=>
  NULL
  ["taxonomies"]=>
  array(0) {
  }
  ["show_ui"]=>
  bool(true)
  ["menu_position"]=>
  NULL
  ["menu_icon"]=>
  NULL
  ["permalink_epmask"]=>
  int(1)
  ["can_export"]=>
  bool(true)
  ["show_in_nav_menus"]=>
  bool(true)
  ["show_in_menu"]=>
  bool(true)
  ["name"]=>
  string(4) "bpiw"
  ["cap"]=>
  object(stdClass)#4832 (14) {
    ["edit_post"]=>
    string(9) "edit_post"
    ["read_post"]=>
    string(9) "read_post"
    ["delete_post"]=>
    string(11) "delete_post"
    ["edit_posts"]=>
    string(10) "edit_posts"
    ["edit_others_posts"]=>
    string(17) "edit_others_posts"
    ["publish_posts"]=>
    string(13) "publish_posts"
    ["read_private_posts"]=>
    string(18) "read_private_posts"
    ["read"]=>
    string(4) "read"
    ["delete_posts"]=>
    string(12) "delete_posts"
    ["delete_private_posts"]=>
    string(20) "delete_private_posts"
    ["delete_published_posts"]=>
    string(22) "delete_published_posts"
    ["delete_others_posts"]=>
    string(19) "delete_others_posts"
    ["edit_private_posts"]=>
    string(18) "edit_private_posts"
    ["edit_published_posts"]=>
    string(20) "edit_published_posts"
  }
  ["label"]=>
  string(20) "Liste des bons plans"
}

I hope this will help.

Regards

Yes, 3.8.1 is the latest version. What is odd here is your queried object is a custom post type post, when it should be a taxonomy term in this function. I take it as the output of the breadcrumb trail doesn’t look correct either (this function is called on a flat taxonomy archive, such as a tag archive page), correct?

I was having problems with the name showing up incorrectly for custom post types. It might be nice to have this fallback on line 639.

//Run through a filter for good measure
if ($term->taxonomy == null || $term->taxonomy == "") {
	$term->name = apply_filters('get_' . $term->name, $term->labels->name);
} else {
	$term->name = apply_filters('get_' . $term->taxonomy, $term->name);
}

Yes mtekk, this is correct.

The problem is that there is no function that handle custom post archive list (at least, it seems).

I think post type should be checked there (line 900) :

//For archives
		else if(is_archive())
		{
			//For date based archives
			if(is_date())
			{
				$this->do_archive_by_date();
			}
			//For taxonomy based archives, aka everything else
			else
			{
				//For hierarchical taxonomy based archives
				if(is_taxonomy_hierarchical($queried_object->taxonomy))
				{
					$this->do_archive_by_term_hierarchical();
				}
				//For flat taxonomy based archives
				else
				{
					$this->do_archive_by_term_flat();
				}
			}
		}

Like… if post_type != post, then run another function than do_archive_by_term_flat(); and will show label as name.

Regards

Yeah that is on my todo list. No official ETA except it will be in the next version adding release.