CPT UI Category URL

It seems like I finally got it working:

https://omkb.de/company/
https://omkb.de/company/category/testcompanys/
https://omkb.de/company/sendinblue/

There is one thing I noticed at the very beginning of working with CPTUI and which you should maybe consider:

As we already had previous CPT working (with out custom code) which only included “category” as slug/prefix for the categories and I THOUGHT I will not be able to alter/customize the slug I chose at the very top of both the CPT and the taxonomy, I felt a little helpless because the field said “There is already an existing page/page type with this slug”.

That made me play around with the slug field, saving and altering until I had the same slug for the CPT AND the taxonomie (which I wanted, because I wanted both to be called /events/, otherwise I would have got two different directories like /events/ and /event_category/).

In the and, when I reflect, THAT working around (and the fact that this was even possible) let to the entire rest of the struggle.

So, to prevent other users from wasting almost one work week on this (maybe I am the only idiot out here :D), you might reject a slug (at the very top, not the custom one) and making it unable to save, if it is exactly the same as another slug. You might also add the hint, that the user can change the slug in the settings.

I guess, if this workaround had not been possible, I had reached my destination way earlier, but hey, that is how things go! ??

Edit: One last note! If there is no taxonomie created yet and you would like to create one by clicking on the “Categories” link of the CPT (not of the plugin but of the CPT), you get an error message. The page is only available if you created a category/tag by typing it out in an entry of the CPT before. Hope you understand what I mean^^

• This reply was modified 2 years, 7 months ago by thesongoku.

Going to break different topics to reply to into different replies. This one focuses on rewrites and permalinks.

I am seeing that things are somehow working for you at this moment.

Part of this all depends on understanding how WordPress parses permalinks.

From you:
If I wanted “cat” instead of “category” in the slug, why would someone write something else in?^^ As far as I can see, filling the additional field is useful if you want to add additional things because you can not use / in the first slug field.
This is simply the nature of how the rewrite slug option works. If my post type and/or taxonomy slug registered is “movie_genre”, but I want the URLs to just use “genre”, then the rewrite slug is where you go to do that.

Where it gets hacky is when people add in say “movie/” as part of the rewrites slug, making that field save as “movie/genre”.

This is important information to know because WordPress parses out the URL based on / as a separator. Take a permalink of https://mysite.com/movie/titanic/

WordPress knows that the first part, “/movie” is the post type, and “/titanic” is the post name. So it’s able to efficiently find the post named “titanic” of the “movie” post type. In cases where people want to remove the post type slug from permalinks, it actually loses information to query off of, and WordPress has to check EVERY entry in the posts table, until it finds “titanic” instead of just movie posts. Sometimes you may see people using just / as a rewrite value for a post type, in order to try to achieve similar things.

In our case here, we’re actually adding extra information to the permalink, and extra “portion” that would be potentially getting used to try and figure out what is being requested.

Hopefully it’s not actually the case, but a permalink like this:
https://omkb.de/company/category/testcompanys/

Could end up being parsed out as “ok, we’re looking for a post named ‘category’, with a child post named ‘testcompanys’, all in the ‘company’ post type’. It’d be looking for a post to show, instead of “ok, we’re looking for the ‘testcompanys’ archive in the ‘category’ taxonomy.”

By magic or fault, it doesn’t have a matching enough rewrite rule that thinks to search for the post type in this case, or the taxonomy archive rule is found and used first.

When registering either a post type or a taxonomy, both screens get the ability to associate with the other because both register processes do.

I’d call it visually bi-directional, but there’s no actual tying of the two together at the code level. They are isolated collected arguments meant to use in one place, whether it be for register_post_type() or register_taxonomy().

It is only necessary to check the association in one place.

Personally, I’d recommend registering a taxonomy and making the post type association there. This is because post types can be registered alone, with no taxonomies associated. However, taxonomies can’t be registered alone. They need to be associated with at least one post type.

I don’t believe there would be any harm in adding that newly registered taxonomy when editing the post type settings, but it’s not required.