[wp-trac] [WordPress Trac] #31300: redirect_canonical returns too early

[WordPress Trac]

#31300: redirect_canonical returns too early
------------------------------------+---------------------
 Reporter:  stephenharris           |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:
Component:  Canonical               |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+---------------------

Comment (by ninjaseoservices6):

 I'm following up on this ticket (31300), which correctly identifies that
 the redirect_canonical filter doesn't always fire, specifically when
 $redirect_url isn't set or is the same as $requested_url.

 I agree with the original report and the use case provided by mikejolley
 that this prevents plugins from implementing their own canonical logic in
 scenarios where core doesn't trigger a redirect but a plugin might need to
 assert a different canonical URL. The attached patch 31300.diff seems like
 a necessary fix to ensure the filter is consistently available.

 My related question concerns another aspect of redirect_canonical's
 behavior and filterability: How can plugins reliably filter or control the
 handling of specific query parameters within the canonical URL generation?

 redirect_canonical() strips many common query parameters by default. While
 this is often desired for SEO, there are cases where plugins or specific
 site needs require certain parameters to be included in the canonical URL,
 or where a plugin needs to decide which parameters are stripped based on
 its own logic.

 Does the proposed fix in this ticket (moving the filter call) adequately
 address the ability for a plugin to add or prevent the removal of query
 parameters? Or is the parameter stripping logic applied after the
 redirect_canonical filter runs, potentially requiring a separate filter or
 approach?

 It seems like a similar problem of needing plugin control over the final
 canonical URL in scenarios where core has already made a decision (in this
 case, about query parameters) before the filter provides a chance to
 intervene.
 Any clarification on whether the current patch (or potential future work
 based on this ticket) would help with query parameter control, or if
 that's a separate issue, would be appreciated.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/31300#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform