Reconsider no-JS ?replytocom= links

[markjaquith]

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.

[joostdevalk]

+1

[mdgl]

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.

[banago]

[...] 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.

[joostdevalk]

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.

[helen]

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.

[joostdevalk]

Patch v1

[markjaquith]

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' );

[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.

[markjaquith]

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.

[joostdevalk]

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

[markjaquith]

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

and

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.

[markjaquith]

There. That should do it.

[markjaquith]

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

[markjaquith]

In 33039:

Restore $noreplytext default value in comment_form_title()

props ocean90
see #22889

[peterwilsoncc]

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.

[markjaquith]

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

[markjaquith]

Reverted for now: [33042]

[joostdevalk]

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.

[joostdevalk]

Patch to add nofollow to ?replytocom links

[SergeyBiryukov]

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.

[peterwilsoncc]

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.

[dshanske]

Can't we resolve this with #34106 ?

[webliberty]

Is it not worth returning to this question? Google does not always follow the rules of robots.txt and rel='nofollow', considering this a recommendation, rather than a strict requirement.

In the plugin Yoast SEO has a fix, maybe it should be replaced as well ? on #.

[peterwilsoncc]

FWIW, the bug that led to reverting above has being fixed in #31590 [42360] .

This has been sitting dormant for three years, let's close as fixed with [33047].

[joostdevalk]

I want to really fix this. The nofollow is just a stop-gap and I'm seeing far too much of these URLs in Google's index. @markjaquith @SergeyBiryukov could you help get this fixed properly?

[peterwilsoncc]

@joostdevalk

Are you able to provide the search link for URL fragments? My google skills are not as good as yours.

I'd like to see if big search ignores the noindex, follow tag & canonical reference core adds to the replytocom HTML header or if it's the result of a bug in a theme or plugin.

My arguments agains this change are largely unchanged from comment 17 above. Removing progressive enhancement places developer convenience above the users is counter best-practice, and in this case a very first world centric change.

[juslintek]

After removing it commentator specified 'Reply to %s' message doesn't work anymore:
site/web/wp/wp-includes/comment-template.php:1850

<?php
/**
 * Display text based on comment reply status.
 *
 * Only affects users with JavaScript disabled.
 *
 * @internal The $comment global must be present to allow template tags access to the current
 *           comment. See https://core.trac.wordpress.org/changeset/36512.
 *
 * @since 2.7.0
 *
 * @global WP_Comment $comment Current comment.
 *
 * @param string $noreplytext  Optional. Text to display when not replying to a comment.
 *                             Default false.
 * @param string $replytext    Optional. Text to display when replying to a comment.
 *                             Default false. Accepts "%s" for the author of the comment
 *                             being replied to.
 * @param string $linktoparent Optional. Boolean to control making the author's name a link
 *                             to their comment. Default true.
 */
function comment_form_title( $noreplytext = false, $replytext = false, $linktoparent = true ) {
        global $comment;

        if ( false === $noreplytext ) $noreplytext = __( 'Leave a Reply' );
        if ( false === $replytext ) $replytext = __( 'Leave a Reply to %s' );

        $replytoid = isset($_GET['replytocom']) ? (int) $_GET['replytocom'] : 0;

        if ( 0 == $replytoid )
                echo $noreplytext;
        else {
                // Sets the global so that template tags can be used in the comment form.
                $comment = get_comment($replytoid);
                $author = ( $linktoparent ) ? '<a href="#comment-' . get_comment_ID() . '">' . get_comment_author( $comment ) . '</a>' : get_comment_author( $comment );
                printf( $replytext, $author );
        }
}

Haven't figure it out yet, how to pass this variable via ajax. Any non-hardcore hacks anyone come up regarding this?

[pento]

This ticket needs further investigation on the current impact, and if search engines aren't obeying the canonical header, why not?

[jonoaldersonwp]

Replying to pento:

This ticket needs further investigation on the current impact, and if search engines aren't obeying the canonical header, why not?

Because canonical is a hint, not a directive. If there are conflicting signals, they'll ignore it. The only way to fix this is to actually fix it.

[hellofromTonya]

Hello all,

Checking in as this ticket's progress stalled 5 years ago.

What's the status of "needs further investigation on the current impact"?

Fast forward from when this ticket was opened: Is there still a need today?

[peterwilsoncc]

I think this is what is needed to proceed:

• Have WP enqueue the script if needed:

  <?php
  if ( is_singular() && comments_open() && get_option('thread_comments') )
    // Maybe check the count of comments too, can't reply if there are none.
    wp_enqueue_script( 'comment-reply' );
  ?>
  

• a11y review to ensure the comment reply script is fully accessible (I don't think it makes any announcements as to the changed content, should it?)

A quick look at google for inurl:?replytocom= wasn't showing a great deal of results, several of those I did see were including the parameter in the canonical meta tag, so it's possible the few results are from server misconfiguration.

If the JS is accessible, I'm less not-keen on removing the progressive enhancement now than I was six years ago. I'd still prefer WP not to require sites enforce the use JavaScript on the front end though, as we can't be sure that's suitable in each case.