[wp-trac] [WordPress Trac] #47488: add "extensibility" to WP_Privacy_Requests_Table

[WordPress Trac]

#47488: add "extensibility" to WP_Privacy_Requests_Table
-------------------------+------------------------------
 Reporter:  pbiron       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Privacy      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:
-------------------------+------------------------------

Comment (by pbiron):

 Looking for some advice on a couple of matters related to row actions for
 the privacy list tables.

 1. all other core list tables that have "builtin" row actions allow
 some/all of those builtin actions to be filtered out with their respective
 `xxx_row_actions` filter.  That is, they build up their builtin row
 actions array and then pass it to `apply_filters( 'xxx_row_actions',
 $actions, $item )` and then pass the result to `$this->row_actions(
 $actions )`.  It seems to be, however, that that **might** not be
 appropriate for the privacy list tables...since the `Download Personal
 Data` and `Force Erase Personal Data` row actions are really how a user
 "operates" on the row (i.e., there is no equivalent "edit" action as in
 all other list tables).  So, my question is: should a plugin be allowed to
 remove those row actions?  I ask because I don't have any real-world
 experience processing privacy requests and don't know what the
 implications would be if a plugin were to filter them out.

 2. would it be useful to have a "generic" `privacy_request_row_actions`
 filter in addition to specific ones for each sub-class of
 `WP_Privacy_Request_Table` (e.g., `export_personal_data_row_actions` and
 `remove_personal_data_row_actions`)?
 `WP_Privacy_Data_Export_Requests_List_Table` and
 `WP_Privacy_Data_Removal_Requests_List_Table` are unique in core in that
 they extend an abstract class that itself extends `WP_List_Table`.  There
 is precedent in core for both a "specific" and a "generic" hook, e.g.,
 `save_post_{$post->post_type}` and `save_post`.

 3. the markup for the 2 "builtin" row actions uses a `<div>` tag to wrap a
 couple of `<span>` tags.  That `<div>` causes when
 `WP_List_Table::row_action()` builds up a string with each action
 separated by `|` (see
 [[https://core.trac.wordpress.org/attachment/ticket/47488/privacy-row-
 actions-div-problem.png|screenshot]]).  As far as I can tell, it does
 **not** need to be a `<div>`, and everything works fine if it's changed to
 a `<span>`.  Does anyone know of a reason it needs to stay a `<div>`?

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