Make WordPress Core

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)

44270.1.patch​ (1.9 KB ) - added by ryanshoover 8 years ago.
Changes rewrite parameter to the default of publicly_queryable

Download all attachments as: .zip

Change History (3)

@ryanshoover
8 years ago

Changes rewrite parameter to the default of publicly_queryable

#1 @ryanshoover
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 @SirLouen
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).

Note: See TracTickets for help on using tickets.