Allow register_post_type's rewrite to remove CPT slug

[BenRacicot]

Not sure if there are reasons (outside of naming conflicts) why register_post_type's rewrite does not allow an empty value as an argument to remove the post type slug from its future post URL's.

After a lot of research and some code from @JanBeck at my wordpress.stackexchange question: ​http://wordpress.stackexchange.com/questions/203951/remove-slug-from-custom-post-type-post-urls its clear that naming conflicts between a CPT and Page type URL's are being avoided.

I propose:

'rewrite' => array( 'slug' => '', 'with_front' => false ),
'has_archive' => 'something',  // will now default to false to avoid possible conflict

then proper rewrite rules should be added to allow for the removal of this CPT slug and disallow the CPT to create conflicting URLs in the future. eg publishing ones that match page URL's the same as native posts append a '-1' to a conflicting URL.

This will solve a large problem where users are trying to hack around this by creating their own rewrite rules, hacking post.php, and pre_get_posts solutions.

[moeloubani1]

An easy way to do this would be to set a flag when registering the post type and if it is set then just add another rewrite rule that looks for the pagename and also checks it against that post type so that instead of 404 erroring after it checks to see if the page exists it checks one more time to see if it exists with post_type=nameofposttype and nameofposttype=url/that/was/requested

[michael.ecklund]

@BenRacicot Could you include a reason or reasons why this would be beneficial to the community?

[drzraf]

Use-case: we have restaurants and had to tweak the rewrite (cf OP) in order to have provide URL like:

/<city>/<slug>

rather than the much more cumbersome:

/restaurant/<city>/<slug>

That best represents the main goal of the website which has no value being artificially namespaced.

We also have a couple of other CPT of less significance (and none of them is named after a city) so that conflict are not going to be an issue (or at least a minor issue in comparison to having clean URL)

Having an officially-supported way to omit the CPT URL's segment would be appreciated.

[michael.ecklund]

I guess I don't understand why you wouldn't just use the built-in hierarchical Post Type (page) for that.

Replying to drzraf:

Use-case: we have restaurants and had to tweak the rewrite (cf OP) in order to have provide URL like:

/<city>/<slug>

rather than the much more cumbersome:

/restaurant/<city>/<slug>

That best represents the main goal of the website which has no value being artificially namespaced.

We also have a couple of other CPT of less significance (and none of them is named after a city) so that conflict are not going to be an issue (or at least a minor issue in comparison to having clean URL)

Having an officially-supported way to omit the CPT URL's segment would be appreciated.

[BenRacicot]

Hey @michael.ecklund,

Anytime you create a CPT for use as a method of public facing content creation in web page format where the use is meant to be browsable by URL. SEO, prett(ier) URLs etc...

The current functionality of CPTs should have the option to drop the CPT name from the URL path built in. Right now it's similar to as if native posts worked like this:

your.com/post/post-name

or if pages worked like:

your.com/page/page-name

But WP does not work this way because adding the CPT as a root path interferes with many SEO, promotional and content strategies. Please take a look at the [wordpress.stackexchange.com] question that has got a lot of attention. This functionality is desired by many.

​https://wordpress.stackexchange.com/questions/203951/remove-slug-from-custom-post-type-post-urls?noredirect=1#comment397952_203951

Let me know if I should expound...

[moeloubani1]

Well as an example if I'm working on a learning website that has courses I'd rather have /course-title/chapter-name/class-name than /course/course-title/chapter-name/class-name and you're right, I could just put them into pages but imagine I have 300 classes and 10 pages, want to assign pages to some categories and courses to others etc. Now my category list is huge and the queries that happen for the workshop include the pages as well and you'd have to add some sort of other logic to differentiate between the two.

What adding a new post type does is gives you the organization to be able to show things in two areas, keeps things that aren't the same separate and helps when you're trying to query those things later, lets you add post type specific taxonomies, archives, etc etc. Sometimes you want all those benefits and you want the URLs to be a certain way and I think that CPTs should have the flexibility to support that.

Replying to michael.ecklund:

I guess I don't understand why you wouldn't just use the built-in hierarchical Post Type (page) for that.

Replying to drzraf:

Use-case: we have restaurants and had to tweak the rewrite (cf OP) in order to have provide URL like:

/<city>/<slug>

rather than the much more cumbersome:

/restaurant/<city>/<slug>

That best represents the main goal of the website which has no value being artificially namespaced.

We also have a couple of other CPT of less significance (and none of them is named after a city) so that conflict are not going to be an issue (or at least a minor issue in comparison to having clean URL)

Having an officially-supported way to omit the CPT URL's segment would be appreciated.

[BenRacicot]

What if you're using pages as they are meant to be used? As the standard web page layout... and your CPT's are being used as a custom web page layout or content as I described:

Anytime you create a CPT for use as a method of public facing content creation in web page format where the use is meant to be browsable by URL. SEO, prett(ier) URLs etc...

Replying to moeloubani1:

Well as an example if I'm working on a learning website that has courses I'd rather have /course-title/chapter-name/class-name than /course/course-title/chapter-name/class-name and you're right, I could just put them into pages but imagine I have 300 classes and 10 pages, want to assign pages to some categories and courses to others etc. Now my category list is huge and the queries that happen for the workshop include the pages as well and you'd have to add some sort of other logic to differentiate between the two.

What adding a new post type does is gives you the organization to be able to show things in two areas, keeps things that aren't the same separate and helps when you're trying to query those things later, lets you add post type specific taxonomies, archives, etc etc. Sometimes you want all those benefits and you want the URLs to be a certain way and I think that CPTs should have the flexibility to support that.

Replying to michael.ecklund:

I guess I don't understand why you wouldn't just use the built-in hierarchical Post Type (page) for that.

Replying to drzraf:

Use-case: we have restaurants and had to tweak the rewrite (cf OP) in order to have provide URL like:

/<city>/<slug>

rather than the much more cumbersome:

/restaurant/<city>/<slug>

That best represents the main goal of the website which has no value being artificially namespaced.

We also have a couple of other CPT of less significance (and none of them is named after a city) so that conflict are not going to be an issue (or at least a minor issue in comparison to having clean URL)

Having an officially-supported way to omit the CPT URL's segment would be appreciated.

[BenRacicot]

The stack question keeps getting votes. Is there anyone who knows how to bump an admin who works on the core trac? Perhaps @GaryPendergast ?

[freshyjon]

I agree that this needs to be implemented, as a way to remove the Custom Post Type slug from the permalink. It helps for organization where post types are used for different "types" of content/layouts/templates... while still allowing for the ability to have a clean URL, which also checks against existing Page slugs (to ensure no duplicates).

[kwalsh.ucnj@…]

Replying to michael.ecklund:

@BenRacicot Could you include a reason or reasons why this would be beneficial to the community?

What about advertisement "vanity URLs"? For example -- oursite.com/instagrammer or oursite.com/youtuber or oursite.com/podcaster. I think this kind of a set-up/URL scheme is fairly standard these days with podcast and YouTube advertising.

These forms of advertisement are areas where an extremely short, memorable URL is beneficial. For example, podcasts -- when a URL is read out loud, it needs to be dead simple. Otherwise people will not remember it. For another example, YouTube/Instagram posts -- adding the URL into the image/video. Again, needs to be dead simple. Otherwise people will not re-type it correctly.

In my typical implementation of the "Vanity URL" WordPress CPT, there's usually a URL input so the site editor can add a third-party input URL. There's some template_redirect logic to redirect from the dead simple URL to the input URL. This third-party input URL either detects mobile OS and redirects the user to the App/Play store, or has some kind of analytics for install attribution. Without custom, unique vanity URLs for each outreach area -- there's no way to measure how much traffic is coming from these sources. And nobody likes advertising without knowing about the return. It is also different behavior from pages -- there's not even a front end template, as the URL is just a redirect.

In these cases, an extra directory in the URL kills the idea of URL simplicity. Even the "best case" solution now, having /v/ ahead of the unique part of the URL... I would bet money there are people who do not remember to type the /v/ portion of the URL. So we currently are prevented from adding vanity URLs via a WordPress custom post type, because we cannot completely remove the custom post type slug from the URL.

In addition -- in our case, we are currently working with at least 10 different ad sources that "require" (work best with) different short, memorable vanity URLs. It may work for some sites to mix vanity URLs in with pages... but when you get past the point of a couple vanity URLs and a couple pages, I think it quickly becomes difficult to manage in the back end.

I hope this is OK to respond. Never done this before. Just trying to put out what I think is a solid use case for no-CPT slug CPTs. Thanks for your time.

[garconis]

This really hasn't been looked into further, yet? Would really like this functionality, for numerous websites :(

[otherjohn]

I have another case in which the old website had staff as domain.com/john-doe and each staff page had tons of custom data that would be beneficial as a custom post type with custom fields and the ability to use the wordpress rest api. But with a large amount of "staff" pages, to move them to a CPT with a slug means you have to do a large amount of redirects (301) which is not ideal. Plus those individuals have it all on their business cards, etc...

[zackpyle]

Agreed! 100% - I would use this all the time.

@otherjohn gives a very simple and common use case for this request

[bward]

Wordpress team,

CPTs are extremely useful. However, the issue of replacing the slug shouldn't be difficult next to impossible to accomplish properly. We have tried many methods and they all have some flaws.

Consider this. The standard post type displays a url of: domain.com/example while a custom post type displays a url of: domain.com/cpt/example

Notice, the standard post type is not domain.com/post/example. Neither is a standard page domain.com/page/example

So why not extend that same functionality to so many of us who need it?

Thank you.

[yamenshahin]

This will be very useful.