Make WordPress Core

Opened 14 years ago

Closed 12 years ago

#12732 closed enhancement (duplicate)

Bulk Actions needs to allow custom bulk actions

Reported by: ptahdunbar's profile ptahdunbar Owned by: scribu's profile scribu
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Administration Keywords: needs-patch
Focuses: Cc:

Description

Patch adds a do_action() hook to allow for custom bulk actions. Plugins can then hook into load-* and process the custom bulk action request.

Attachments (2)

bulk_actions.diff (6.6 KB) - added by ptahdunbar 14 years ago.
bulk_actions_filter.diff (14.0 KB) - added by ptahdunbar 14 years ago.
Uses a filter approach

Download all attachments as: .zip

Change History (26)

#1 @TobiasBg
14 years ago

Wouldn't it be nicer to abstract the current HTML on each of those bulk action <select> boxes in an array, like

$bulk_actions = array (
    'delete' => __( 'Delete' ),
    'spam' => __( 'Mark as Spam' )
);

That array could then be run through a filter, where I could just add an element to that array - which is nicer than having to echo my own HTML in a do_action call. It would also have the advantage, that existing bulk actions could be removed through that filter, if desired.

And finally, the array could be printed to the page by a generic function (which could even be used on all of those bulk action <select> boxes, e.g. like

function wp_bulk_action_select_box( $actions ) {
  echo "<select>";
  foreach ( $actions as $value => $text ) {
    echo "<option value='{$value}'>{$text}</option>";
  }
  echo "</select>";
}

#2 @ptahdunbar
14 years ago

I thought about that same approach too but just wanted to get something in there for now. I'll give it another go using the filter approach.

#3 @dd32
14 years ago

  • Component changed from General to Administration
  • Milestone changed from Unassigned to 3.1
  • Type changed from defect (bug) to enhancement

I remember writing a patch nearly identical to that back when the Bulk actions was first implemented...

This however, is an enhancement over what we've currently got, This probably belongs in 3.1/future release due to the feature freeze.

#4 @jane
14 years ago

I agree, this is coming in too far after feature freeze and should be for 3.1.

#5 @sirzooro
14 years ago

  • Cc sirzooro added

+1 for this idea. I also planned to submit similar ticket - I need this for one of my plugins.

I think that patch should also add another set of actions, which will be used to execute chosen bulk action. For example, add following code to edit.php, around line 128:

default:
  do_action( "do_bulk_actions-$post_type", $doaction, (array) $post_ids );
  break;

#6 @nacin
14 years ago

Apparently, we've all written a patch like this before... I like the approach proposed by TobiasBg, personally.

#7 @ptahdunbar
14 years ago

  • Milestone changed from 3.1 to 3.0

refreshed the patch.

#8 follow-up: @TobiasBg
14 years ago

I really like that one.

A few things I noticed when glancing over the patch:

  • in edit-comments.php, the filter shall probably be called "bulk_actions-comments" and not "bulk_actions-users" (probably leftover from copy&paste)
  • I suggest proper initialisation of each $bulk_actions array, i.e. $bulk_actions = array(); before each one is used the first time. (Although each one seems to have the -1? entry, I believe that that is better practice.)
  • Your tab width seems to be pretty long (like 8 spaces). Or is it just the Trac view of the patch? But maybe the commiter could/would clean that up anyway.

Thanks for the patch!

@ptahdunbar
14 years ago

Uses a filter approach

#9 in reply to: ↑ 8 @ptahdunbar
14 years ago

Replying to TobiasBg:

A few things I noticed when glancing over the patch:

  • in edit-comments.php, the filter shall probably be called "bulk_actions-comments" and not "bulk_actions-users" (probably leftover from copy&paste)

fixed.

  • Your tab width seems to be pretty long (like 8 spaces). Or is it just the Trac view of the patch? But maybe the commiter could/would clean that up anyway.

that's trac. my tabs are 4 spaces.

#10 @nacin
14 years ago

  • Milestone changed from 3.0 to 3.1

I don't want to rush this into 3.0. We should be taking a comprehensive look at how we use bulk actions, and how we may wish to use them, before adding filters and such that we'll then need to support. Far too much changing here.

#11 @Viper007Bond
14 years ago

I'd love to have this in. Adding them using Javascript is ugly. :)

#12 @sillybean
14 years ago

  • Cc steph@… added

#13 follow-up: @scribu
14 years ago

  • Keywords gosc added
  • Owner set to scribu
  • Status changed from new to accepted

I've also written a patch for this as part of my GSoC project. I've taken the same approach as TobiasBg:

http://gsoc.trac.wordpress.org/browser/2010/scribu/wp-admin/includes/template.php?rev=429#L584

#14 @scribu
14 years ago

  • Keywords gsoc added; gosc removed

#15 in reply to: ↑ 13 @ptahdunbar
14 years ago

Replying to scribu:

I've also written a patch for this as part of my GSoC project. I've taken the same approach as TobiasBg:

http://gsoc.trac.wordpress.org/browser/2010/scribu/wp-admin/includes/template.php?rev=429#L584

The bulk_actions_filter.diff patch should be commit ready but may need a refresh.

#16 @scribu
14 years ago

I'm wondering which is better:

apply_filters('bulk_actions', $actions, $screen);

or

apply_filters("bulk_actions-$screen", $actions);

Maybe we can have both?

#17 @nacin
14 years ago

I'd definitely just go with the latter, bulk_actions-$screen.

#18 @Viper007Bond
14 years ago

There's no harm in having a global bulk actions filter and who knows, it may be handy. I know I've run into cases (option value filters for example) where having a global filter is really needed.

But having a bulk_actions-$screen would make it easier to target a specific bulk action dropdown.

So I vote both. You never know what usage someone is going to come up with for a filter. Best to be as flexible as possible IMO.

#20 @voyagerfan5761
14 years ago

  • Cc WordPress@… added

#21 @scribu
14 years ago

  • Milestone changed from Awaiting Triage to 3.1
  • Resolution set to fixed
  • Status changed from accepted to closed

#22 @nacin
13 years ago

  • Keywords needs-patch added; has-patch gsoc removed
  • Milestone changed from 3.1 to Future Release
  • Resolution fixed deleted
  • Status changed from closed to reopened

Most of this was in some way reverted. There are many, many considerations before we continue.

#23 @cogmios
13 years ago

  • Cc deleau@… added

#24 @scribu
12 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

Going to close this as duplicate of #16031. The filter is there. It just needs handlers.

Note: See TracTickets for help on using tickets.