New bulk actions hook missing catcher behavior

[Veraxus]

The new bulk actions filter allows you to modify the bulk-actions arrays, but neglects to add the ability to handle the new custom actions.

The fix is to simply add one new do_action() hook to the default case of each affected page (similar to the way 'wp_ajax_' handles custom ajax requests).

For example, the following might be added to users.php at line 285, immediately after <tt>default:</tt>

do_action( 'bulk_action-'. $wp_list_table->current_action() );

Fixes submission handling for pages affected by the new bulk_action filter

The hook in this patch follows the format 'do_bulk_action-screenid-currentaction'.

Without this patch, there is still no non-hacky way to handle custom batch actions that developers may create, which defeats the purpose of the bulk_action hook.

There are also files currently missing a default action handler:

plugins.php
upload.php
network/site-themes.php
network/site-users.php
network/themes.php

Perhaps the hook should be added to them too?

The bulk_actions filter wasn't implemented for those pages; I only added handlers for the filters that are already officially committed.

I'm not sure those screens would really benefit from custom bulk action support, though (excepting network/site-users.php).

The hook in this patch follows the format 'do_bulk_action-screenid-currentaction'.

'tags' isn't the screen id, for example. So, it's more like do_bulk_action-{list-table-type}-currentaction'.

Still, it's a good idea.

If we do want to go with screenid, it should be reflected in the code:

do_action( 'do_bulk_action-' . $current_screen->id . '-' . $doaction );

This patch looks like a good starting place but we should try and cover all of these if we are going to do this.

Sounds like working off the screen id might be a good idea so we can have context when the tables are used in more than one place.

Actually, using the screen id would be the only consistent way, due to this:

$this->_actions = apply_filters( 'bulk_actions-' . $screen->id, $this->_actions );

Anyway, going to clean up the patch.

16031.2.patch​ introduces WP_List_Table::do_bulk_action() and calls it wherever WP_List_Table::current_action() is used.

There are several inconsistencies, though:

On network/sites.php, current_action() is not used, because bulk actions are handled in network/edit.php

On edit-comments.php, the action is run for each selected comment.

On users.php and edit-tags.php, the entire screen is rendered in the default: branch.

16031.minimal.patch​ avoids problematic screens, which would remain to be handled in a future release.

The next step would be to pass the list of elements to be processed to the action.

As useful as this may be, I think it's too big a change for this very late state in the dev cycle.

A workaround is to use the "load-$pagenow" action instead.

#16166 and #16187 make this higher priority. In particular, WP_List_Table::add_query_args() would need to be used by bulk action handlers... Figuring out how to handle this and do the redirect for them would be best.

Maybe these need to be filters, rather than actions. And the filter is the sendback URL, and they can add_query_arg() before returning it.

For now I think the simplest solution is to remove the filter that lets you add bulk actions and revisit the ability to add extra ones in a future version.

That is the best thing for this stage of the cycle

Indeed. Pull it.

Quick patch

Looking for a list of plugins that have already adopted this

We were using the bulk_actions filter in 'Page Security by Contexture'. I don't know who else might have implemented it, though.

The 'bulk_actions_' filter can also be used to remove certain actions, for example. I don't see the point in removing it.

​http://wordpress.org/extend/plugins/backwpup/
and
​http://wordpress.org/extend/plugins/wpematico/

Both have the list tables code copied into them for back-compat

Grunion 2

Viper007Bond pointed out that we already have an 'admin_action_*' hook:

http://core.trac.wordpress.org/browser/trunk/wp-admin/admin.php?rev=17272#L232

The problem with that, as with "load-$pagenow", is that it runs before any capability checking is done.

Still, I think it's good enough for now.

Attached patch prevents no new actions from being added via the filter.

They can still do it by extending get_bulk_actions(), but that isn't supported. Otherwise, this filter ties our hands for future attempts to dry up all of the bulk action handler code (#16166) and also AJAX bulk actions.

(In [17297]) Prevent new bulk actions from being added through the bulk_actions-screen filter. fixes #16031 at least for 3.1.

We can't really call this 'fixed'.

+1, I need exactly this for a custom plugin I'm writing, where I want admins to be able to deactivate and activate users (see ​http://develop.servus.at/trac/cbadevel/changeset/955).
I hate being forced to use a core hack.

I can only wonder why the minimal patch was pulled.

My broadcast plugin would like to be able to mass-broadcast posts but that ain't happening unless I can add my own bulk action.

And would you believe that the table list code is a barren filter-desert? Not a filter or action as far as the eye I can see so I can't even add a custom button above the table, either. *sigh*

You have a great point edward,

While the WP_List_Table class can be extended by developers creating NEW list tables, a few well-positioned filters and actions might be exactly the thing that's needed to make this a reality. It would certainly be a clean, professional solution. I'll look into it this week. That may need a new ticket, though, because it's such a different approach - but it could also be much more future-proof.

I'll report back once I've taken a look.

As far as I can see, adding bulk actions isn't really a problem. A quick add_bulk_actions filter in the bulk_actions() function will solve the adding of filters.

It's the handling of the $_POST that's somewhat more of a problem, seeing that handling should be done before page output.

And since none of the post, link, comment, etc pages have anything in common that will mean adding bulk _POST handling code individually into each page.

Maybe $wp_list_table->handle_bulk_actions(); above $wp_list_table->prepare_items(); ?

+1 about that: a number of users of my plugin (Duplicate Post) ask about selecting and cloning several posts at once.

This will be fixed eventually, probably right after the media library revamp. :P

Replying to scribu:

This will be fixed eventually, probably right after the media library revamp. :P

Is there a chance to fix this for 3.6? After all, that would be exactly right after the media library revamp ;-)

After all, that would be exactly right after the media library revamp ;-)

Hm... I guess we have to stop using "after the media library revamp" as interchangeable with "never"...

Is there a chance to fix this for 3.6?

If no one steps up with a patch, there is no chance, IMO.

Replying to scribu:

If no one steps up with a patch, there is no chance, IMO.

I'm willing to give my best if you could help me a bit by providing details about what's wrong with the 16031.minimal.patch​, and in which direction it should go. The patch looks good enough for me, but the comments from nacin seem to indicate that he wants to prevent some future incompatibilities - although I'm not sure what exactly he seems to have in mind.

I'm willing to give my best if you could help me a bit by providing details about what's wrong with the 16031.minimal.patch​, and in which direction it should go.

Read edward mindreantre's comment again.

Maybe we can revert r17297? I'm trying to add bulk spam to Grunion right now and just ran into this. I'm not sure what we gained by making it harder to hack stuff onto a core list table.

Was looking for adding a bulk action and ran into this ticket, then found scribu's answer on stack exchange ​http://wordpress.stackexchange.com/questions/29822/custom-bulk-action, and I fail to see the point of forcing people to use JS to add a bulk action. Sure it is the easier part of the solution but better then nothing.