| 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). |