When we login to sites with our VIP Support user, it often seems to be the first time a user with manage_options is logging into the site. So we get the prompt to confirm that admin email address.
In reality, we shouldn't be getting this prompt, and confirming would end up putting it off for another 6 months until a real admin has a chance to confirm. So instead, let's just skip this screen for the VIP Support user altogether.
Unfortunately, the global user object isn't set at this point. And passing $user along to the filter in core wouldn't be very straightforward given the other place the filter is used (before any user validation).
The filter on line 1235 though runs just before the filter usage we care about, and it does provide the $user object early on. So I'm using this to run our user checks before disabling the confirmation.
Testing
1) Make your user is not a support user, and set the admin email check to expire. Then log in, and note the confirmation. This is the normal flow for users.
2) Make your user a support user, and set the check to expire again. Then login, and note there is no confirmation. This will be the flow for VIP Support users logging in.
3) Remove the support user meta and logout, then login again and note the confirmation is still there. Or, just log in with a different admin. This shows we are just skipping the prompt while still allowing the next real admin to see it.
Problem
When we login to sites with our VIP Support user, it often seems to be the first time a user with
manage_options
is logging into the site. So we get the prompt to confirm that admin email address.In reality, we shouldn't be getting this prompt, and confirming would end up putting it off for another 6 months until a real admin has a chance to confirm. So instead, let's just skip this screen for the VIP Support user altogether.
Implementation
Returning 0 with this filter avoids the confirmation screen: https://github.com/WordPress/WordPress/blob/87a759b81c7a6d7e2ef6a361a55826e46f3c4e21/wp-login.php#L1267-L1270
Unfortunately, the global user object isn't set at this point. And passing
$user
along to the filter in core wouldn't be very straightforward given the other place the filter is used (before any user validation).The filter on line 1235 though runs just before the filter usage we care about, and it does provide the $user object early on. So I'm using this to run our user checks before disabling the confirmation.
Testing
1) Make your user is not a support user, and set the admin email check to expire. Then log in, and note the confirmation. This is the normal flow for users.
2) Make your user a support user, and set the check to expire again. Then login, and note there is no confirmation. This will be the flow for VIP Support users logging in.
3) Remove the support user meta and logout, then login again and note the confirmation is still there. Or, just log in with a different admin. This shows we are just skipping the prompt while still allowing the next real admin to see it.