Opened 3 years ago
Last modified 2 years ago
#15324 assigned enhancement
There needs to be a page_base in rewrite.php
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | Rewrite Rules | Version: | 3.1 |
| Severity: | normal | Keywords: | has-patch, dev-feedback |
| Cc: |
Description
I'm not sure why this feature doesn't exist. It looks trivial and important. There are many reasons for putting pages at, say, /page/%pagename%. The attached patch makes it possible to write a plugin to allow this.
Attachments (1)
Change History (9)
Ideally, this should be transparent in regards to other hierarchical post types.
Replying to scribu:
Erm, what about pagination, i.e. /page/2 ?
I think that's more of a documentation problem. The page base could conflict with the pagination base, but that's something the plugin/theme developer should probably take care of.
Replying to scribu:
Ideally, this should be transparent in regards to other hierarchical post types.
With this patch pages can get permalinks more like custom post types. The CPTs still have the with_front parameter, and adding the front to the page permalink is not possible with this patch. I'm not sure if this should be made possible though.
comment:6
markjaquith — 2 years ago
- Milestone changed from Awaiting Review to Future Release
I'm not a fan of this. You'll probably want to actually leverage a CPT rather than pages in this case, as that's the only real difference. Especially since this patch doesn't take into account rewrite rule generation, as the catchall, or without regard to verbose rules either.
This should probably be done through register_post_type instead. Ideally we can begin to move pages and posts more in the direction of CPTs in terms of dogfood, very similar to what we did in 3.1 with categories and tags.
First patch