WordPress.org

Make WordPress Core

Opened 17 months ago

Closed 17 months ago

Last modified 17 months ago

#44376 closed enhancement (duplicate)

Make $email_data array filterable in `wp_send_user_request()`

Reported by: rwebster85 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9.6
Component: Privacy Keywords:
Focuses: privacy Cc:
PR Number:

Description

It would be very handy for developers if we could hook into the $email_data array and filter it. That way we could replace the url or other parameters. Real world example: my site blocks access to all WP dashboard and backend pages like wp-login.php in order to present a front-end only experience to users. I would like my privacy related request authorisation links to be front-end also.

$email_data as seen here: https://github.com/WordPress/WordPress/blob/3ee58b55b14683af4c568bce1845c37408c88fbb/wp-includes/user.php#L3329

Something like the following would be good:

$email_data = array(
        'email'       => $request->email,
        'description' => wp_user_request_action_description( $request->action_name ),
        'confirm_url' => add_query_arg( array(
                'action'      => 'confirmaction',
                'request_id'  => $request_id,
                'confirm_key' => wp_generate_user_request_key( $request_id ),
        ), site_url( 'wp-login.php' ) ),
        'sitename'    => is_multisite() ? get_site_option( 'site_name' ) : get_option( 'blogname' ),
        'siteurl'     => network_home_url(),
);

$email_data = apply_filters( 'wp_send_user_request_email_data', $email_data, $request, $request_id );

Note: My first ticket, apologies for any errors in submission.

Change History (8)

#1 @garrett-eclipse
17 months ago

  • Keywords close added
  • Resolution set to wontfix
  • Status changed from new to closed

Hi @rwebster85, that matches fairly closely with the one I opened - #44235

It was closed as wontfix which I'm doing for this ticket since there's already a filter which allows you to do this. See comment and example here;
https://core.trac.wordpress.org/ticket/44235#comment:3

Cheers

#2 @Clorith
17 months ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution changed from wontfix to duplicate

Duplicate of #44235

#3 @rwebster85
17 months ago

  • Resolution duplicate deleted
  • Status changed from closed to reopened

This doesn't seem right, unless I've misread. That filter is used twice, both times aren't covered by my original proposal. The email sent to a user to confirm their request is not filtered by user_confirmed_action_email_content

#4 @garrett-eclipse
17 months ago

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

Duplicate of #44235.

Hi @rwebster85

Sorry the two were so similar I overlooked they were for different emails, but the same applies here irregardless as the $content gets filtered before the placeholders are replaced and as such you can use them to supply your own content instead.

So for your specific case the filter is user_request_action_email_content and can be used as follows to update the confirm_url;

add_filter( 'user_request_action_email_content', function( $content, $data ) {
    return str_replace( '###CONFIRM_URL###', 'https://new.confirm.url', $content );
}, 10, 2 );

While writing the example I did note two shortcomings of the current filter which I've addressed in new tickets;
#44379 - The filters should supply $request_id or $request so that information is available in the filter for recreating the confirm_url and others.
#44381 - The logic for confirmaction (https://github.com/WordPress/WordPress/blob/3ee58b55b14683af4c568bce1845c37408c88fbb/wp-login.php#L862) is only available via wp-login.php so even though you can replace the confirm_url with a front-end URL you'd break the action as the confirmaction code wouldn't be available to execute.

The tools were built as admin tools so their reliance on back-end pages isn't surprising. That being said there is a plugin (https://wordpress.org/plugins/gdpr-data-request-form/) which exposes the forms on the front-end but it just pushes requests into the normal queue where they go through the same confirm process that requires wp-login.php.

So aside from waiting for #44381 to be addressed in GDPR V2 (Roadmap - https://make.wordpress.org/core/roadmaps/privacy/) you can create a plugin, template or custom code on a front-end page that accepts your own confirmaction that handles the request and executes the user_request_action_confirmed action for you.
https://github.com/WordPress/WordPress/blob/3ee58b55b14683af4c568bce1845c37408c88fbb/wp-login.php#L862

I'm going to re-close this issue in favour of the other two I spawned as currently you can update the URL but it won't work without additional work which is covered by those other tickets.

Hope that makes sense

Cheers

Last edited 17 months ago by garrett-eclipse (previous) (diff)

This ticket was mentioned in Slack in #core-privacy by garrett-eclipse. View the logs.


17 months ago

#6 @rwebster85
17 months ago

Thanks mate but like I said the data in the function in my title is not exposed to that filter. The filter you're talking about is only present in two functions, neither of them are wp_send_user_request().

Am I explaining it properly? The function that runs to generate a request confirmation email which is sent to the user is not filtered.

#7 @rwebster85
17 months ago

Actually I think I'm being a bit silly here. Apologies. I've noted you spotted we need access to the request data along with the email data.

Reading GitHub on my phone isn't the best. Thanks for your help! :)

Last edited 17 months ago by rwebster85 (previous) (diff)

#8 @garrett-eclipse
17 months ago

No worries @rwebster85

Note: See TracTickets for help on using tickets.