Make WordPress Core

Opened 3 years ago

Last modified 3 months ago

#22889 reopened enhancement

Reconsider no-JS ?replytocom= links

Reported by: markjaquith Owned by: markjaquith
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Comments Keywords: has-patch dev-feedback
Focuses: Cc:


We have a no-JS fallback for comment replies. Normally JS moves the comment form around. For people with JavaScript disabled, they follow the ?replytocom={123} link. This results in a lot of extra crawling by search engines (potentially an additional crawl per reply-able comment!) in exchange for enabling an awkwardly executed, likely underused, and non-essential feature for non-JS users.

I'd like to consider making comment reply JS-only.

Attachments (3)

22889.patch (4.8 KB) - added by joostdevalk 3 months ago.
Patch v1
22889.2.patch (5.8 KB) - added by markjaquith 3 months ago.
22889.3.patch (749 bytes) - added by joostdevalk 3 months ago.
Patch to add nofollow to ?replytocom links

Download all attachments as: .zip

Change History (25)

comment:2 @mdgl3 years ago

Agreed that the current replytocom mechanism is really ugly and causes numerous difficulties, but it would be disappointing to lose the ability to handle threaded comments completely unless JS is enabled.

As far as I can see the underlying issue is how to get the variable comment_parent set for wp-comments-post.php when you submit a comment. It might be worth thinking through some other ways in which the user could get this variable set appropriately and without JS.

This and many other tickets are indicating that our comments system is probably long overdue for a revamp. I would suggest a phased approach over perhaps two releases: first clean up the underlying mechanisms and APIs; second create a better front-end with POST through the page template, overlayed with some nice AJAX support for those using JS.

comment:3 @banago2 years ago

.. for enabling an awkwardly executed, likely underused, and non-essential feature for non-JS users

Can't agree more. Using the HTML5 "data" attribute to have something like this, would work I think:

<a href="#" data=reply="{123}" title="Reply to this comment">Reply</a>

Or even move away from the anchor tag altogether.

Version 0, edited 2 years ago by banago (next)

comment:4 @joostdevalk3 months ago

Can I bump this one? Would love to get this fixed. We default to disabling these non-JS links in our SEO plugins and never get complaints about it.

comment:5 @helen3 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

I can move this into Future Release, as it's too late for 4.3. Mostly this needs a patch, I don't think there's any real opposition.

@joostdevalk3 months ago

Patch v1

comment:6 @joostdevalk3 months ago

  • Keywords has-patch dev-feedback added; needs-patch removed
  • Owner set to joostdevalk
  • Status changed from new to assigned

comment:7 @markjaquith3 months ago

I think we should keep the no-robots code. At least for a few releases. Those URLs might be floating around somewhere.

add_action( 'wp_head', 'wp_no_robots' );

comment:8 follow-up: @joostdevalk3 months ago

In theory, the noindex shouldn't be needed because there's a canonical on the page that points to the right URL, especially as there are no internal links to those URLs anymore.

comment:9 in reply to: ↑ 8 @markjaquith3 months ago

Replying to joostdevalk:

In theory, the noindex shouldn't be needed because there's a canonical on the page that points to the right URL, especially as there are no internal links to those URLs anymore.

Ah, the canonical point is a good one. That should handle it. I retract my suggestion.

comment:10 @joostdevalk3 months ago

As this has a patch and is fairly straightforward, I'd love to milestone it to 4.3 :) @sam, @obenland?

comment:11 @markjaquith3 months ago

Warning: Missing argument 3 for comment_form_title(), called in /Users/mark/Sites/wp.dev.git/src/wp-includes/comment-template.php on line 2286 and defined in /Users/mark/Sites/wp.dev.git/src/wp-includes/comment-template.php on line 1652


Notice: comment_form_title was called with an argument that is <strong>deprecated</strong> since version 4.3 with no alternative available. in /Users/mark/Sites/wp.dev.git/src/wp-includes/functions.php on line 3571

Also one of the changed PHPDoc lines removed an ending period.

@markjaquith3 months ago

comment:12 @markjaquith3 months ago

There. That should do it.

comment:13 @slackbot3 months ago

This ticket was mentioned in Slack in #core by mark. View the logs.

comment:14 @markjaquith3 months ago

  • Milestone changed from Future Release to 4.3
  • Owner changed from joostdevalk to markjaquith
  • Status changed from assigned to accepted

comment:15 @markjaquith3 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 33038:

Say goodbye to ?replytocom=123 links and their URL pollution.

  • Comment reply links continue to use JS as before.
  • ?replytocom=123 links are deprecated.

props joostdevalk
fixes #22889

comment:16 @markjaquith3 months ago

In 33039:

Restore $noreplytext default value in comment_form_title()

props ocean90
see #22889

comment:17 @peterwilsoncc3 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

I’m reopening this as I have significant concerns about the implications around progressive enhancement/usability. I missed the slack conversation due to time-zones.

My concerns are:

  • the comment-reply JS is not enqueued by core when it’s needed, any themes that are not enqueuing the script properly will be incompatible with 4.3. This commit breaks backward compatibility
  • core functionality of any sites should be available without JavaScript. By switching to a JavaScript-only model, replies are removed from core-functionality with relatively little discussion
  • as I mention in #31590, the JavaScript for comment-replies can fail on large threads or slow connections for quick clicks on a reply link
  • in ideal network conditions this will have little effect. Users on slower networks are more likely to be affected than those in ideal conditions
  • the stated concern (crawling by search engines) is a concern for large sites with lots of comments. Such sites should be resourced.

I think removing progressive enhancement from the front end should be plugin territory. There is a filter in place to allow website owners to do this if they choose.

Removing progressive enhancement from 24% of the internet needs more discussion than a ticket milestoned an hour before the commit allows.

comment:18 @markjaquith3 months ago

  • Milestone changed from 4.3 to Future Release

I don't agree with all these objections (or rather, don't care about all of them), but #31590 is a definite blocker.

comment:19 @markjaquith3 months ago

Reverted for now: [33042]

comment:20 @joostdevalk3 months ago

Ok if we're going to revert, I'm going to propose that we add a nofollow to these replytocom links. Should make Google's crawling slightly more sane.

@joostdevalk3 months ago

Patch to add nofollow to ?replytocom links

comment:21 @SergeyBiryukov3 months ago

In 33047:

Restore rel='nofollow' for comment reply links to reduce extra crawling by search engines.

This reverts [16230], which didn't have enough review at the time of commit.

props joostdevalk.
see #22889, #18547, #16881.

comment:22 @peterwilsoncc3 months ago

Thanks, [33047] is a great pragmatic mid-point. I'd like to see this closed as fixed with this patch.

It solves the stated problem of excessive crawling by bots without penalising the JavaScript impaired. Google's SEO advice is to make sites for humans before bots, we've done that.

Note: See TracTickets for help on using tickets.