[wp-trac] [WordPress Trac] #59766: Custom post type archive URLs are being resolved in an unexpected way if a page with the same slug exists and the URL's casing doesn't exactly match the custom post type's rewrite slug

[WordPress Trac]

#59766: Custom post type archive URLs are being resolved in an unexpected way if a
page with the same slug exists and the URL's casing doesn't exactly match
the custom post type's rewrite slug
-------------------------------+------------------------------
 Reporter:  nonverbla          |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  6.3.2
 Severity:  normal             |  Resolution:
 Keywords:  has-patch          |     Focuses:
-------------------------------+------------------------------

Comment (by nonverbla):

 Thank you @jrf for your explanation. It's amazing how thoughtful the
 WordPress maintainers are about introducing a breaking change.

 If I understand correctly, the concern is that with the current behavior,
 some users might have registered for example two post types, one with an
 archive slug of `books` and the other with a slug of `Books` and are
 relying on WordPress' behavior to treat these two as separate resources?

 This would break as soon as they would install a static caching plugin,
 for example WP Super Cache in expert mode. There, the rewrite rules for
 static files looks like this:


 {{{
 RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1
 /index-https.html.gz -f
 RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-
 https.html.gz" [L]
 }}}


 In my tests with Super Cache, both `/Books` as well as `/books` or even
 `/bOoKs` always matches the same file:

 {{{
 /wp-content/cache/supercache/%{SERVER_NAME}/books/index-https.html.gz
 }}}

 So with the current behavior, the first page being hit with a cache miss
 would be cached, and subsequent requests would be served with that cached
 response, no matter the casing in the URL. We have created a response
 randomizing machine ;)

 Should this not be considered broken behavior? Looking forward to what you
 think.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59766#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform