Opened 8 years ago
Closed 13 months ago
#44270 closed enhancement (wontfix)
Non-public custom post types have rewrite rules enabled by default
| Reported by: | TheDeadMedic | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Posts, Post Types | Version: | |
| Severity: | trivial | Keywords: | has-patch |
| Cc: | Focuses: |
Description
Is there a reason for the pairing of public => false with rewrite => true for default custom post type arguments? If there isn't can we change the default rewrite to inherit public at runtime?
I often see a large rewrite rules array from plugin/theme private post types not declaring rewrite => false - if there's no need for them seems bit of a waste - a default WP install is 17 rules per post type, 17 possible unnecessary regex checks per-request. Usually it's two or three CPTs I see per site and they stack up quick.
Attachments (1)
Change History (3)
#1
@
8 years ago
- Keywords has-patch added
Just submitted a patch that would take care of this need. Changes the default of rewrite to be the value of publicly_queryable (which takes the default of public).
publicly_queryable made the most sense since rewrites determine the pretty URL for a post if you query it on the frontend.
#2
@
13 months ago
- Milestone Awaiting Review
- Resolution → wontfix
- Status new → closed
- Type defect (bug) → enhancement
This has been like this almost from the beginning.
But it's true that given how poor in performance rewrite rules are when it comes to CPT, I also believe that setting this to what is publicly default makes a lot of sense at first.
But then I think that some plugins could be using rewrite rules for non-public CPT. For example. Let's say I have some internal administrative content, like logs. I could potentially want to access friendly URLs while not having a front face in the admin.
If this plugin is live, it will be broken after this update, causing a massive BC if they have not explicitly set up their rewrites to true. Yes, it's a total pain having to think of these random use-cases and the possibility that any edge idea could be profiting from this, but it appears that BC takes priority.
Knowing that you can simply set your non-public CPT to rewrite to false, this bug feels more like an enhancement, and it's not an enhancement we can take without causing a break.
I'm going to close this for now, because this has been stalling for quite a long time, and no further ideas have come around the topic (so it doesn't seem to be a very popular problem that people is aware of, and still we have easy workarounds; after all setting a new CPT is not something that comes by default in WP core).
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Changes
rewriteparameter to the default ofpublicly_queryable