[wp-trac] [WordPress Trac] #44500: Mark data requests failed when an expired link is clicked

[WordPress Trac]

#44500: Mark data requests failed when an expired link is clicked
-------------------------------------------------+-------------------------
 Reporter:  desrosj                              |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Privacy                              |     Version:  4.9.6
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-unit-    |     Focuses:
  tests                                          |  administration
-------------------------------------------------+-------------------------

Comment (by garrett-eclipse):

 Thanks @desrosj some more notes here.

 **Generalize User Request Status Transitions**  [[BR]]
 I tend to agree with @birgire on a more generalized function instead of
 wp_mark_user_request_failed and now would be the time to do that as it's a
 new function. So we'd have a wp_set_user_request_status with a switch for
 the new status so when it's going to fail and is already completed that's
 blocked, and tie it with a wp_transition_user_request_status() for calling
 the necessary hooks which we'd want documented and unit tested.  [[BR]]
 The following are locations I found that this transition function would be
 used;  [[BR]]
 https://github.com/WordPress/WordPress/blob/56c162fbc9867f923862f64f1b4570d885f1ff03
 /wp-admin/includes/user.php#L633  [[BR]]
 https://github.com/WordPress/WordPress/blob/56c162fbc9867f923862f64f1b4570d885f1ff03
 /wp-admin/includes/user.php#L781  [[BR]]
 https://github.com/WordPress/WordPress/blob/7ee752e40cf47feb2591711efb8074217b6961f2
 /wp-includes/user.php#L2949  [[BR]]
 https://github.com/WordPress/WordPress/blob/7ee752e40cf47feb2591711efb8074217b6961f2
 /wp-includes/user.php#L3515

 **Minor Comments**  [[BR]]
 1. We've been referencing the user_request post as just user request so
 the comment 'Marks a user_request post as failed.' should be 'Marks a user
 request as failed.'
 2. The get_post method can return null which isn't a boolean so should be
 instead checking for `if ( ! empty( $post ) )`
 3. You missed a space after the opening brace here `} elseif
 ('user_request' !== $post->post_type ) {`
 4. Is there a reason we're setting post_status to an empty string?

 **Rewriting wp_validate_user_request_key** [[BR]]
 Aside from the note to pull the status check out of this method we may
 want to revisit and follow the convention of the `wp_validate_auth_cookie`
 function which returns false or an int instead of WP_Error and instead
 fires actions for all the errors before returning false. By doing this we
 follow an existing convention and then the function can be called as a
 boolean without the is_wp_error check as well the call to mark request
 failed when expired can be done through a separate function attached to
 the action that's thrown in that case.
 The wp_validate_auth_cookie function -
 https://github.com/WordPress/WordPress/blob/56c162fbc9867f923862f64f1b4570d885f1ff03
 /wp-includes/pluggable.php#L602

 These might deserve extra tickets but wanted to discuss further before
 spawning any.

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