GDPR filters should provide either $request or $request_id

[garrett-eclipse]

Hello,

While discussing #44376 and reviewing #44235 I realized that the GDPR email filters should provide either the $request object or $request_id so if users are trying to replace $email_data using the filter they can recreate some of it that relies on the request.

That affects these filters;

• user_confirmed_action_email_content
• user_request_action_email_subject

By supplying the request (id or object) in the filter then customizations can be made which insert request specific information, etc.

For instance if you want to replace the confirm_url with a custom one you would want the request information on that custom confirm_url so your custom interception function knows what request is being confirmed.

Hope that makes sense,
Cheers

[garrett-eclipse]

Depending on the results of #44314 more filters will need to be covered by this. The current patch on that ticket adds a new filter namely;
user_erasure_fulfillment_email_content

As well in my ticket I mentioned user_request_action_email_subject which will also need the request data but had meant user_request_action_email_content so both of them should be addressed.

[desrosj]

@garrett-eclipse can you clarify a bit more. I see that both of those filters are already providing the $request object as an argument.

[garrett-eclipse]

Hi @desrosj

I assume you're speaking on the mention of $request in the docblocks like here;
​https://github.com/WordPress/WordPress/blob/3ee58b55b14683af4c568bce1845c37408c88fbb/wp-includes/user.php#L3379

In actuality that's incorrect as the first object in $email_data is $request->email and not the $request or $request_id, and unless wp_get_user_request_data supports lookup via the email then it doesn't give you the request which is needed if you try to recreate say confirm_url in a similar fashion as it does now but by supplying a front-end page instead of wp-login.php;

		'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' ) ),

*This stems from the request in #44376, currently he'd have to recreate the wp-login.php code for confirmaction in his own page but without the request available to these filters it's hard to generate a similar confirm_url.

So looking at the docblock again I think it was expected that the first item in the email_data array was supposed to be the request but it's not actually there. So either the filters should provide it as a param or it should be part of email_data.

Cheers

[Otto42]

Putting the request into the email data at https://core.trac.wordpress.org/browser/trunk/src/wp-includes/user.php#L3353 would seem to be the simplest way to solve the problem.

[garrett-eclipse]

Agreed @Otto42

That would introduce it for both user_request_action_email_content and user_request_action_email_subject.

Looking at both cases for user_confirmed_action_email_content looks like request is in the email_data, that filter changes in another ticket but uses the same email_data array so shouldn't change.

So I don't believe would need to be introduce anywhere aside from the one mentioned by @Otto42

Cheers

[desrosj]

Add missing $request to $email_data to match the inline documentation for the following filters.

[desrosj]

Replying to garrett-eclipse:

I assume you're speaking on the mention of $request in the docblocks like here;
​https://github.com/WordPress/WordPress/blob/3ee58b55b14683af4c568bce1845c37408c88fbb/wp-includes/user.php#L3379

Ah, yes. I see not that the request is not included. We should definitely add this. I am changing this to a bug because the documentation is inaccurate.

I also discovered it was difficult to replace the login URL working on #44353, which I detailed in 44353:comment:6. TL;DR: replacing site_url( 'wp-login.php' ) with wp_login_url() will allow plugins to change the login URL without having to rebuild the confirm request URL.

[garrett-eclipse]

Thanks @desrosj for the update and good catch on switching to use wp_login_url

[ocean90]

4.9.7 has been released, moving to next milestone.

[azaozz]

In 43477:

Privacy: Add $request to $email_data to make it available to all filters.

Props desrosj.
Fixes #44379.

[SergeyBiryukov]

In 43488:

Privacy: Add $request to $email_data to make it available to all filters.

Props desrosj.
Merges [43477] to the 4.9 branch.
Fixes #44379.