Comment actions should omit arbitrary parameters / use the canonical URL rather than the request URL

[jonoaldersonwp]

When a page is requested with arbitrary query parameters (e.g., ​https://rup.wordpress.org/2016/03/05/hello-world/?cats=awesome), functional links should ignore such parameters - they should use the canonical URL instead.

E.g., on ​https://rup.wordpress.org/2016/03/05/hello-world/?cats=awesome and similar, inspecting the page's source shows that the "Leave a Reply" link, a hidden input field in the subscription functionality, and the "Send to Email Address" form all reference the URL with the ?cats=awesome string.

In each of these cases, these components should reference the canonical URL, rather than the request URL.

[ocean90]

What's the actual issue here? The current behaviour seems to be correct as you can't tell whether a query argument is necessary for the current page or not.

[jonoaldersonwp]

Same as everywhere else; wasted crawl budget, messy analytics, etc.

The canonical URL should tell us exactly what's necessary for the current page.

[ocean90]

The subscription/sharing widget is part of Jetpack, I suggest to submit this request to ​https://github.com/Automattic/jetpack/.
The comment link is generated by core's get_cancel_comment_reply_link() function so a ticket on ​https://core.trac.wordpress.org/ would be a better place for this.

The canonical URL should tell us exactly what's necessary for the current page.

No, it doesn't. Just imagine some argument which should still be available after a form is submitted that redirects you to the previous page.

[jonoaldersonwp]

"Just imagine some argument" - got any examples? These are static blog posts.

[jonoaldersonwp]

Core doesn't handle canonicals well enough for us to be able to alter get_cancel_comment_reply_link reliably. Let's fix this here instead?

[dd32]

Let's fix this here instead?

No.

[jonoaldersonwp]

Why not?

[dd32]

As explained by @ocean90 already, there's legitimate reasons for the current behaviour. If you want to "fix it", open a core ticket, which is a better place.

We're not going to "fix" every tiny detail on WordPress.org when it's a squarely a WordPress behaviour.

I'm closing this again, please don't reopen unless there's a HUGE improvement with data to back it up.
Discussion can continue woke a ticket is closed.

[jonoaldersonwp]

Let's split this out.

1) Why would we deliberately choose not to fix a fault on wordpress.org, simply because it's a fault with/in WordPress? There are a thousand other scenarios where dot org diverts from / improves on WP core behaviours. Unless there's a specific reason that we can't fix it here, I challenge that distinction.

2) It's completely unrealistic to expect a core solution to this. Our problem/solution is simple, contained, and constrained. A solution in core would need to account for myriad other factors, and, core's canonical URL mechanisms are laughably unsophisticated. We'd be looking at years of shoring up basic capabilities before we could even start on housekeeping fixes.

3) We don't have data on the expected impact, nor will we have isolatable data on the impact of it. That's not how this works. For a start, we're not A/B testing our changes, so there's no baseline to compare against. We're also deep in a position where we're still fixing a million tiny broken things, attempting to put our a raging fire - until we put the fire out, we'll struggle to meaningfully assess the position/performance of the site. In lieu of such data, I'd appreciate you assuming that my expertise and experience is sufficient to have determined that the effort/reward ratio for this fix is worthwhile; at least, it might have been, until we spent an hour bickering about it instead of just fixing it.

[jonoaldersonwp]

This remains a problem, and is actively harming our crawl budget.

[jonoaldersonwp]

And, we've already fixed similar problems locally: https://meta.trac.wordpress.org/ticket/4325