Limit pagination for comments

[devrekli]

you can look? please ​https://wordpress.org/support/topic/wordpress-infinite-link-problem/

Hello. WordPress has endless link problems for many years. Note: This problem happens when we paged comment example:

Others:

​https://perishablepress.com/wordpress-infinite-duplicate-content/comment-page-2/
​https://perishablepress.com/wordpress-infinite-duplicate-content/comment-page-2754/

others

​https://www.wpbeginner.com/beginners-guide/how-to-properly-ask-for-wordpress-support-and-get-it/comment-page-2754/
​https://www.wpbeginner.com/beginners-guide/how-to-properly-ask-for-wordpress-support-and-get-it/comment-page-5754/

others

​https://www.isitwp.com/best-wordpress-404-error-plugins/comment-page-3754/
​https://www.isitwp.com/best-wordpress-404-error-plugins/comment-page-5754/

Attention! There are no comments on these pages. But the links are entering the article. This is the problem for google search console.

If there is no comment, that link should not work. How can I fix this?

Paged comments from your admin panel. And you try too

If we do not paginate, this is no problem.

This problem happens in paginations..

If the setting is like this. screen shot: ​https://prnt.sc/smhi90

[carike]

How can I fix this?

:wave:
Hallo :)
As I indicated on the support forums, for a timely solution, you may want to consider hiring a developer to create a custom plugin, if this is important to you.

In terms of this Trac ticket:

The issue:
Paginated pages with no entries display the original post.
Here is an example: ​https://wordpress.org/support/topic/wordpress-infinite-link-problem/page/12345/

The proposed solution:
When a permalink is evaluated for a paginated URL, it should check if the particular page "exists" (contains entries), not just whether the post exists.
If there are no entries on the paginated URL, the visitor should be redirected to the original post's URL.

[SergeyBiryukov]

Replying to carike:

The issue:
Paginated pages with no entries display the original post.
Here is an example: ​https://wordpress.org/support/topic/wordpress-infinite-link-problem/page/12345/

Just noting that particular issue is being tracked in #28081.

This ticket is a reporting a similar, but distinct issue for paginated comments, which was previously noted in comment:6:ticket:11694, but never addressed in that ticket.

[sumanm]

This patch adds page limitation for comments non existing page and redirect to parent post

[sumanm]

added unit tests for comments limit pagination

[mukesh27]

Minor changes

[mukesh27]

In 50233.2.patch​ added some minor text and space changes.

[SergeyBiryukov]

Didn't get a chance to review this in time for 5.6 RC, moving to the next release for now.

[chaion07]

Thanks @devrekli for reporting the issue. We reviewed this ticket during a [recent triage session]​https://wordpress.slack.com/archives/C02RQBWTW/p1622577969164000. It would be great if others can review the patch as well.

Drawing kind attention from @asif2bd as the component maintainer for Permalink. Thank you!

[audrasjb]

patch refreshed against trunk, coding standards fixes and @since refresh

[audrasjb]

In 50233.3.diff, I refreshed the previous patch against trunk, fixed some coding standards issues and I refreshed @since mentions.

[whyisjake]

In 51118:

Permalinks: Limit pagination for posts with comments.

Additionally, redirect pages back to the source page if comments don't exist.

Props devrekli, carike, sumanm, mukesh27, chaion07, audrasjb, whyisjake, SergeyBiryukov.

Fixes #50233.

[whyisjake]

In 51125:

Permalinks: Revert the changes stemming from pagination limits.

In [51118], an attempt was made to add pagination limits. The added tests need to be updated to ensure that they pass with the new changes.

Reverts [51118].

See #50233.

[devrekli]

you haven't fixed it for a long time

[costdev]

Adds these changes to src/wp-includes/link-template.php. Tests pass. Do not commit this patch.

[costdev]

Patch 50233.4.diff adds these changes to src/wp-includes/link-template.php. This makes the unit test pass.

However, this raises the following questions:

1. Is wp_get_canonical_url() the correct method to use in the existing unit test?
   • If not, the correct method should be determined and the unit test corrected.

2. Does 50233.3.diff work with manual testing?

3. Does 50233.4.diff work with manual testing?

4. Does 50233.4.diff work without the changes to src/wp-includes/canonical.php?
   • If not:
     • Both src/wp-includes/canonical.php and src/wp-includes/link-template.php need to be patched.
     • More tests are needed to properly test the changes in src/wp-includes/canonical.php.

---

Adding needs-testing so this can be picked up by the Test team and suggest moving this to the Future Release milestone as it still needs work.

[hellofromTonya]

More testing and discussion is needed. Moving to 6.0.

[costdev]

Per the discussion in the bug scrub, I'm adding dev-feedback.

Some comments from @ironprogrammer:

• This should be checked against the new Comments Query Loop as well, in case there is any overlapping functionality.
• Redirecting URLs that exceed the max makes sense, though I haven’t looked at the patches yet. Nobody has chimed in about it breaking backward compat, so this looks like a straightforward SEO win?

[peterwilsoncc]

Redirecting URLs that exceed the max makes sense, though I haven’t looked at the patches yet. Nobody has chimed in about it breaking backward compat, so this looks like a straightforward SEO win?

I think redirecting might be problematic:

• 301 Permanent redirects are cached by the browser permanently. Someone visiting page two of the comments before it exists would never be able to visit page two of the comments
• 302|307 Temporary redirects can be indexed by search engines as I understand it.

(Someone working in the WordPress SEO space may wish to correct me.)

I think the best option would be to either:

• show a 404 page if the comments page doesn't yet exist
• ensure the canonical tag points to the post's default page and the comments on that page are displayed.

My preference is leaning towards a 404 page.

As this hasn't had any substantial work on it during the 6.0 cycle, I'm going to move the ticket on to a future release.