Huge pagination values break things

[jonoaldersonwp]

E.g., take a look at the behaviour of ​https://wordpress.org/support/view/support-forum-yes/page/9999999999999999999999999999999999/.

This, and other extremely high values redirect to a maxint pagination value (e.g., ​https://wordpress.org/support/view/support-forum-yes/page/9223372036854775807/).

This, and other pagination states in the same order of magnitude (e.g., ​https://wordpress.org/support/view/support-forum-yes/page/9223372036854775802/) come with some headaches, where they return the 'page 1' state but with incorrect meta values.

Therefore...

All invalid range values should return 404 behaviour, as per low range invalid values do at present (e.g., ​https://wordpress.org/support/view/support-forum-yes/page/100/). Related, #4166.

[dd32]

9223372036854775807 is PHP_INT_MAX on a 64bit system, so that's where the redirect is coming from (bbPress is probably using absint() or intval())

​https://bbpress.trac.wordpress.org/ticket/3018#comment:1 is kinda related I think.

While this is also a bbPress problem, it's probably one we can workaround on dotorg without too much issues.

[dd32]

In 8224:

WordPress.org: Force a 404 for any logged out paged requests above MAX_PAGES, this is done to avoid bbPress overriding it later.

See #4167.

[dd32]

[8224] covers this for logged out users, is that enough for SEO purposes?

[jonoaldersonwp]

Yeah that's super, thanks!

[dd32]

Cool :) I'm going to close this as fixed then, It's still janky for logged in users, but hopefully if Search engines never index pages like that, users will never end up on a page like that!