[wp-trac] [WordPress Trac] #31005: wp_send_json(): Filtering of $response prior to passing it to wp_json_encode().

[WordPress Trac]

#31005: wp_send_json(): Filtering of $response prior to passing it to
wp_json_encode().
-------------------------+------------------------------
 Reporter:  ap.0         |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  4.1
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by ap.0):

 Agreed, it would be better to filter earlier, were that an option. It
 doesn't look like that's necessarily always the case, though.

 For example, I'm currently dealing with a third-party theme. I'm avoiding
 changing the theme directly, to try to make future updates easier.

 This particular theme is somewhat complex, and uses AJAX for part of its
 custom admin functionality.

 Some of these AJAX handlers return some user data (wp_users.user_pass, for
 example...) that may be tolerable while using it on a single site with a
 single admin, but isn't when using it in a multi-site setup with multiple
 admins.

 While this is a problem with the theme itself, I was hoping to use
 WordPress' extensibility to fix or work around it, instead of modifying
 the theme directly.

 I can't share the code in question from the theme, but the flow is
 roughly:

 {{{
 function ajax_handler() {
     // "fields" isn't specified, so it defaults to "all".
     // This results in a query like "SELECT wp_users.* FROM wp_users ..."
 eventually being generated.
     $query = new WP_User_Query( ... );

     // Get and mildly process the results (but no hooks exist in this
 theme-provided result-processing function, unfortunately).
     $result = array();
     foreach ( $query->results as $result_item ) {
         $result[] = function_with_no_hooks( $result_item );
     }

     // Prepare the response data.
     $response = array(
         ...
         'data' => array(
             'result' => $result
         ),
         ...
     );

     // Send the response.
     wp_send_json( $response );
 }

 add_action( 'wp_ajax_SUFFIX', 'ajax_handler' );
 }}}

 The "pre_get_users" hook in WP_User_Query->prepare_query() might be an
 option, but I'd rather not have to list all of the fields individually
 (which could potentially change in the future, both in terms of which ones
 are available/returned, and which ones the theme's code may expect to be
 present) just to remove "user_pass".

 The same goes for using "pre_user_query", and altering the SELECT clause
 directly.

 WP_User_Query's constructor and WP_User_Query->query() don't seem to have
 any hooks that could be used to modify the results just after they're
 retrieved, as well.

 I haven't noticed any other hooks that might be used to perform this
 filtering.

 Given the apparent lack of useful existing hooks in this particular case,
 a hook for filtering in wp_send_json() starts to look like a more useful
 and general option. The theme's code can be left unchanged, with the small
 amount of unwanted data removed just prior to returning the results.

 Filtering in lower-level functions doesn't seem to be without precedent,
 as well. wp_die() and wp_redirect() both support filtering, for example,
 and they seem to be at roughly the same level as wp_send_json().

 As for the potential for abuse/misuse possibly causing breakage, wouldn't
 that apply to pretty much every hook that already exists?

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