Adding directory to permalink for custom taxonomy posts

get_term_link() would normally include parent terms in the returned URL. There must be other code on your site that is filtering term permalinks which is preventing parents from appearing. Finding it can be difficult. Reduce the scope of code to be searched by switching to a default twenty* theme and deactivating all plugins. Implement your taxonomy and menu code as a stand alone plugin or by temporarily adding it to the twenty* theme you are using.

Revisit the permalinks settings screen to regenerate rewrite rules. Check the child term links now. If the parent still does not appear, there’s something in your remaining code doing it. If it does appear, restore your theme and plugins one at a time, checking term links after each. Revisit the permalinks screen for good measure each time as well. When the parent disappears again, the last activated module is the cause.

n.b. The posts permastruct wouldn’t affect term permalinks, however there are additional taxonomy permastructs stored in the global $wp_rewrite object. In any case, you’ll find that the one %tax-slug% tag is normally replaced by the full /ancestors/term string by get_term_link(). Your issue is not in the permastructs.

thanks @bcworkz,

Unfortunately that didn’t help. My theme is built from the ground up. Does this help? I’ll include the function that includes the custom taxonomy. In this case the i_am is the taxonomy name.

function add_iam_taxonomies() {
	// Add new taxonomy, make it hierarchical (like categories)
	$labels = array(
		'name'              => _x( 'I Ams', 'taxonomy general name', 'textdomain' ),
		'singular_name'     => _x( 'I Am', 'taxonomy singular name', 'textdomain' ),
		'search_items'      => __( 'Search I Ams', 'textdomain' ),
		'all_items'         => __( 'All I Ams', 'textdomain' ),
		'parent_item'       => __( 'Parent I Am', 'textdomain' ),
		'parent_item_colon' => __( 'Parent I Am:', 'textdomain' ),
		'edit_item'         => __( 'Edit I Am', 'textdomain' ),
		'update_item'       => __( 'Update I Am', 'textdomain' ),
		'add_new_item'      => __( 'Add New I Am', 'textdomain' ),
		'new_item_name'     => __( 'New I Am Name', 'textdomain' ),
		'menu_name'         => __( 'Immigration I Ams', 'textdomain' ),
	);
  

	$args = array(
		'hierarchical'      => true,
		'labels'            => $labels,
		'show_ui'           => true,
		'show_admin_column' => true,
		'query_var'         => true,
		'rewrite'           => array( 'slug' => 'i-am' ),
		'show_in_rest'      => true, // need to show this in order for option to display under the 'Document' panel in a post
	);

	register_taxonomy( 'i_am', array( 'post', 'i_am' ), $args );
}

That appears to be in order. Something is overriding the default behavior. I suppose you could override the override by hooking “term_link” filter with a large priority argument so your callback runs last. Use string functions to insert ancestor terms between taxonomy base and the term slug.

For reference, the part of get_term_link() code that builds the ancestor/slug for replacement of the permastruct "%$taxonomy%" tag is at https://core.trac.www.ads-software.com/browser/tags/5.3/src/wp-includes/taxonomy.php?marks=4227-4234#L4224

Thanks. But I have no idea what that means.

would it be better to do a custom post type or custom taxonomy here?

I’m sorry my last reply was not understandable. I’ll try to clarify. I’m guessing that a plugin or theme, whether intentionally or unwittingly, is altering the default behavior for custom taxonomy permalinks. The correct way to do so is to filter the permalink output through filter hooks WP provides for that purpose. If that’s the case, you can add your own filter hook that also alters the permalink output, undoing the plugin’s change and putting it back to the way it is supposed to be.

Not really the best solution, but it will work assuming the cause is a filter from your theme or a plugin. And maybe even if it is not the root cause since a late acting filter hook has the final say in the permalink output no matter what has happened prior. The best solution is to find the root cause and correct it, but that requires greater expertise and potentially a lot of digging into unfamiliar source code.

I cannot answer whether a post type or taxonomy is the best solution for you because I don’t know your needs. Post types are best for unique data that is not replicated over and over. Taxonomies are best for qualifying posts because its terms can be reused over and over again. Or we could say posts are for discrete data and taxonomies are for organizing that data. But then post types to a limited extent can be used for organizing and taxonomy terms can contain discrete data, so there is room for fringe needs that do not fit neatly into one type or the other.

Thank you for the explanation, so here’s what I’ve got:

I have a site that will have traditional blog posts and pages. I also am using a plugin that (I am assuming) is creating a custom post type for downloadable documents.

Further, I will also be creating static content similar to posts that will have different features (i.e. no comments, different headers etc.). This content would need to not be mixed up with typical blog posts. Also, I’ll have a section of repeatable items that would just be a thumbnail, a title and a link for external links. An example of this would be located here: https://wp19.knowgreaterpartnership.com/resources/

In order to easily separate the content from blog posts and pages, would this be a better usage of custom post types, rather than making custom taxonomies for “resources”, “ext-links”, “definitions” etc.?

Sorry for the wordy response, I just can’t spend more time on something like this, when it could be done better another way.

Thanks

You could really go either way. It depends on how you would prefer to administer the data. Though I would be reluctant to define a lot of custom post types only because they involve a certain amount of overhead. But if you think it would be important for “Resources” etc. to appear as separate items in the admin sidebar, then post types could make sense. But if assigning taxonomy terms on a post edit screen will work for you, then it’s probably better to use taxonomies. You could take a hybrid approach, for example all the various objects could fall into a “more data” post type to keep it separate from posts, pages and documents. But within that post type a taxonomy (or a few) could further distinguish various sorts of objects.

You can also use custom fields as an organizational device, though this is best used for data that is unique to each post object of whatever type which typically would not be repeated for other similar posts. Yet another organizational possibility are post formats. Formats are typically established by themes, but for your own site you can add them from a plugin or child theme, where ever your other custom code resides. For example, the default twenty* themes have a “Link” post format that is intended to be just like your example of thumb, title, and link.

While the default post listing would not include any CPTs, it’s pretty simple to modify the query to include or exclude other post types.