[wp-trac] [WordPress Trac] #64785: Add filter for redirect_to URL in get_the_password_form()

[WordPress Trac]

#64785: Add filter for redirect_to URL in get_the_password_form()
-----------------------------------+------------------------------
 Reporter:  regnalf                |       Owner:  (none)
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Posts, Post Types      |     Version:  6.9.1
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:
-----------------------------------+------------------------------

Comment (by regnalf):

 Hi @westonruter and everyone,

 You are absolutely right about the "redirect_to field" — the likelihood of
 it ever being renamed is practically zero, so relying on the field name
 isn't the fragile part here.

 The goal of a "Public Preview Link" approach already works perfectly for
 me. The only remaining minor flaw is the password submission redirect
 itself.

 When a client visits the password-protected post via a special link (e.g.,
 ?preview_hash=abc123), they still need to enter the post password. After
 submitting the form, the default redirect drops these custom query
 parameters. To seamlessly maintain the preview state for the client, I
 just need to append that specific hash back to the redirect URL using
 add_query_arg().

 This is where the WP_HTML_Tag_Processor approach or version with
 str_replace falls short. If we rely on parsing the HTML, safely modifying
 the URL to append parameters becomes highly complex. A developer would
 have to:

 • Extract the existing URL from the HTML attribute.

 • Parse the URL to safely append new arguments (checking for existing ? or
 & in case other plugins already added parameters).

 • Re-inject the string back into the HTML.

 This makes it impossible to simply use core functions like
 add_query_arg(), which expect a raw URL string, not an HTML block.
 Furthermore, if multiple plugins try to append parameters this way by
 parsing the same HTML string, they risk overriding each other and breaking
 the markup.

 A dedicated data filter (apply_filters( '...', $url )) provides a clean
 API. It allows any plugin or theme to safely run add_query_arg() on the
 raw URL before it is rendered. This guarantees interoperability between
 plugins and keeps the logic completely separate from the presentation
 layer.

 My opinion is that a hook to filter the url is the only truly robust
 solution for handling URL parameters in this scenario.

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