WordPress.org

Making WordPress.org

Opened 3 months ago

Closed 3 months ago

Last modified 6 weeks ago

#4900 closed defect (wontfix)

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

Reported by: jonoaldersonwp Owned by:
Milestone: Priority: lowest
Component: General Keywords: seo
Cc:

Description

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.

Change History (11)

#1 @ocean90
3 months ago

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.

#2 @jonoaldersonwp
3 months ago

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

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

#3 @ocean90
3 months ago

  • Resolution set to wontfix
  • Status changed from new to closed

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.

#4 @jonoaldersonwp
3 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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

#5 @jonoaldersonwp
3 months ago

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?

#6 @dd32
3 months ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Let's fix this here instead?

No.

#7 @jonoaldersonwp
3 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Why not?

#8 @dd32
3 months ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

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.

#9 @jonoaldersonwp
3 months ago

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.

Last edited 2 months ago by jonoaldersonwp (previous) (diff)

#10 @jonoaldersonwp
6 weeks ago

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

#11 @jonoaldersonwp
6 weeks ago

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

Note: See TracTickets for help on using tickets.