WordPress.org

Make WordPress Core

Changes between Version 1 and Version 2 of Ticket #16031, comment 65


Ignore:
Timestamp:
10/21/2015 05:41:36 AM (6 years ago)
Author:
Veraxus
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #16031, comment 65

    v1 v2  
    44
    55* Every admin screen handles actions ''outside'' of the `WP_List_Table` class, on its respective screen.
    6 * After hard-coded default actions are handled, a custom redirect is built by feeding the current URL through `add_query_arg()` as necessary. This ensures that duplicate actions aren't accidentally executed on refresh, since the redirect effectively flushes the request data after it's handled.
    7 * `$wp_list_table->prepare_items()` is usually run after the aforementioned redirect (and after actions are caught and handled), meaning our request data will never reach it. It's also not executed consistently before or after actions are handled.
    8 * When and where the redirect is handled by each screen sometimes varies wildly. But each time the hook needs to occur ''before'' the forced redirect occurs (which flushes our request data), but before `$wp_list_table->prepare_items()` is executed.
     6* After hard-coded default actions are handled, a custom redirect is built by feeding the current URL through `add_query_arg()` as necessary. This ensures that duplicate actions aren't accidentally executed on refresh, since the redirect effectively flushes the request data after it's handled. Any handler hook we create must allow for modifying the redirect URL, so that devs can create custom result messages.
     7* `$wp_list_table->prepare_items()` is ''usually'' run after the aforementioned redirect (and after actions are caught and handled), meaning our request data will never reach it. It's also not executed consistently before or after hard-coded actions are handled (and therefore that redirect).
     8* When and where the redirect is handled by each screen sometimes varies wildly. But in each case the hook must occur ''before'' the forced redirect occurs (which flushes our request data).
    99
    1010And this is why the comprehensive patch adds the hooks to each admin screen, contingent on the redirect, and not `WP_List_Table`.
     
    1212Unfortunately, we simply won't be able to neatly package this behavior into `WP_List_Table` without dramatically reworking every single core admin screen as well. We'd have to merge the action-handler logic and redirect handling into each screens respective list table child class... but that seems like a different project/ticket.
    1313
    14 BUT... maybe that's what we ''should'' do given the wild lack of any common style or convention in those files (i.e. use it as an opportunity to tidy up the code for each screen). My point is: putting the handler inside `WP_List_Table` is anything ''but'' straightfoward due to the way these screens are constructed. It would be a pretty substantial refactoring project.
     14BUT... maybe that's what we ''should'' do given the wild lack of any common style or convention in those files (i.e. use it as an opportunity to tidy up the code for each screen).
     15
     16My point is: putting the handler inside `WP_List_Table` is anything ''but'' straightfoward due to the way these screens are constructed (action handling + redirect building). It would be a pretty substantial refactoring project.
    1517
    1618Thoughts?