[wp-trac] [WordPress Trac] #44353: Replace `site_url( 'wp-login.php' )` in `wp_send_user_request()`
WordPress Trac
noreply at wordpress.org
Fri Jun 15 18:20:41 UTC 2018
#44353: Replace `site_url( 'wp-login.php' )` in `wp_send_user_request()`
----------------------------------------------------+---------------------
Reporter: 7studio | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 4.9.7
Component: Privacy | Version: 4.9.6
Severity: normal | Resolution:
Keywords: good-first-bug has-patch needs-refresh | Focuses:
----------------------------------------------------+---------------------
Changes (by desrosj):
* keywords: good-first-bug has-patch => good-first-bug has-patch needs-
refresh
* milestone: Awaiting Review => 4.9.7
Comment:
The second parameter of `site_url()` is passed down to `set_url_scheme()`,
as @birgire detailed above. This function ensures that `http` and `https`
is used correctly in the URL, or that the protocol is stripped out if the
scheme is `relative`. It doesn't seem that passing `comfirmaction` to
`site_url()` for context is a good idea.
Because the URL links to `wp-login.php`, I think using `wp_login_url()` is
the right thing to do here. That would allow a plugin or theme to use the
`login_url` filter to filter the login URL, and ensure the correct scheme
is applied (using the already supported `login` scheme). This would also
handle moving the `action`, `request_id`, and `comfirm_key` parameters to
the new login URL automatically instead of requiring plugins to handle
that.
@rwebster85 Making the array of data that is passed filterable is also not
a bad suggestion, but I think that deserves a separate ticket for
discussing. Filters could be added to all privacy email data before
constructing the emails. Can you open a ticket for that?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/44353#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list