"Overlapping" Post Type and Taxonomy Slugs No Longer Work

If you absolutely must, the old settings are still available, as I created new saved options with the 1.0.x update instead of overwriting the original ones. So you could revert to 0.9.5 if needed.

So I’m understanding correctly, is the /people/type/ bit an archive url that has both the post type and the taxonomy in it?

Also if needed, would you be willing to send me your import/export values and permalink setting so I can see if I can recreate 404s.

Aggh this has happened to me to. Have flushed permalinks, resaved cpt and taxonomies.

If I turn off custom rewrite slug it works ok.

Thanks for the response, @tw2113. Don’t want to roll back if at all possible, just want to establish that this used to work.

To clarify a bit more:

• /people/ – People post type archive: Works
• /people/jim/ – Single person post type post: Works
• /people/type/staff/ – Staff Taxonomy Term archive: Broken

Here are export files for both the taxonomies and post types on the site.

A few other notes:

• The permalinks are just set to /%postname%/.
• I’ve tried both true and false for with_front on the taxonomy settings.
• With Rewrite Rules Inspector, I can see that the post type rule takes precedence over the taxonomy rule. I’m not sure if that’s relevant to this issue, but I thought I’d mention it.

I greatly appreciate your assistance. Thanks!

as you may have noticed around the forum here, 0.9.x to 1.0.x was a huge undertaking, and it didn’t go as smoothly as I would have preferred.

The withfront part wouldn’t be related to this, I don’t believe.

The rewrite rule inspector finding very well could be.

MRWweb, could you try a test for me, In the main custom-post-type-ui.php file, find the line

add_action( 'init', 'cptui_create_custom_taxonomies' );

around line 235, and change it to

add_action( 'init', 'cptui_create_custom_taxonomies', 9 );.

Essentially setting the priority to 9 instead of the default 10.

Flush your permalinks after that, and refresh your troublesome pages. Let me know if that helps.

Fixing line 235 works for me, but only when I’m logged into the site. When I log out of WordPress, the 404 page appears again.

@tw2113, that works like a charm. Can I safely make that change and assume it’ll be in the next version, or should I try to remove the action and re-add it from a plugin?

( @andrewd300 – that sounds like a caching issue.)

it’ll be in the next release, which may very well be 1.1.0, if I can get some things confirmed ready.

That’s great. I just want to make sure this doesn’t come back following the next update.

(I appreciate your help and the work it takes to work through all this stuff! It does not go unnoticed.)

Decided to make it a 1.0.8 release which I will aim to have out next week.

Thanks for the fix, I was worrying and wondering about what has gone wrong in my site…