[wp-trac] [WordPress Trac] #50976: WordPress stripping out "page" query parameter with 301 redirect

[WordPress Trac]

#50976: WordPress stripping out "page" query parameter with 301 redirect
-----------------------------+----------------------
 Reporter:  aleksihulkkonen  |       Owner:  (none)
     Type:  defect (bug)     |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Rewrite Rules    |     Version:
 Severity:  normal           |  Resolution:  wontfix
 Keywords:                   |     Focuses:
-----------------------------+----------------------

Comment (by silentz0r):

 Replying to [comment:27 Otto42]:
 > > WordPress could have used something like "_page", "wp_page" or even
 have a standard for reserved query parameters (e.g. all parameters
 starting with "wp_"). Reserving one, if not the, most common terms as a
 reserved parameter is bad.
 >
 > Sure, except that WordPress has used 'page' for this purpose for over 16
 years now. You can see where it was originally added here:
 >
 > https://core.trac.wordpress.org/changeset/2535
 >
 > As for what changed, well, 'page' was expected to be a numeric
 parameter. It has been reserved for such a purpose for a very long time
 now.
 >
 > Until 5.5, if it wasn't a valid page number, then it was essentially
 ignored and left as is. However, this resulted in page=1234 (where 1234 or
 anything else there was not a valid page number) being ignored and thus
 resulting in the page content of page 1 showing, just as if it wasn't
 there are all.
 >
 > However, this means that links like http://localhost/pagename/1234 (and
 anything else in place of 1234) would show the same content. For SEO
 purposes, this is obviously not a good thing to do.
 >
 > So, now it checks if the page number is an invalid one, and if so, it
 redirects to the correct URL for the page content. Thus avoiding duplicate
 content issues.


 Thanks for a detailed answer. Could you also provide the change in 5.5
 that ensures the numerical check?

 > If you were using the reserved 'page' keyword for another purpose, then
 you essentially got away with it because the invalid values you were
 sending it were ignored. They should not have been ignored, and now they
 are not. Sorry that this inconveniences you, however if having the keyword
 'page' be reserved and used in the query parameters for over 16 years
 isn't long enough, then I don't really know what a better answer would be.

 Yes, WordPress made (in my opinion) a bad call in reserving one of the
 most popular words and it has reserved it for over 15 years. But the
 reservation was buggy and it led into people using that word for those 15
 years in a plethora of plugins, and it was silently fixed in a minor
 Wordpress release and not mentioned in the changelog resulting into broken
 websites everywhere. Don't you think things like this should be mentioned
 in the patch notes?

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