attached patch adds hook_node_operations, which gives the ability for modules to inject custom actions into the mass editing dropdown box located at admin/node. the action can either be a database query of the form you'll find in the standard node_operations function (which is performed on each of the checked nodes), or it can be a custom callback with custom args, which is passed an array of the check nodes for processing.

if you'd like to see this in action, here's a demo site:

http://hooknodeoperations.xcarnated.com

if you'll click the dropdown menu for the mass edits, you'll see a couple of silly actions i added in from another module. try them out, they work! :)

Comments

hunmonk’s picture

Title: allow modules to inject custom operations at » custom operations at admin/node
merlinofchaos’s picture

Oooh. +1. Not much code, adds real power to the interface.

hunmonk’s picture

StatusFileSize
new3.42 KB

ok, some under-the-hood refinements:

it didn't seem neccessary to have the option to pass a database query--everything can be handled with callbacks, and it makes the hook usage much simpler to grok. so i've revamped the array in node_operations() to reflect that change and removed the query option altogether.

dries’s picture

Sweet. It would be better if the node module would eat its own dogfood and implement the new hook rather than going with a hybrid approach.

hunmonk’s picture

StatusFileSize
new3.81 KB

@Dries: i thought you might say that... :)

attached patch has node module implementing the hook as well.

hunmonk’s picture

StatusFileSize
new3.83 KB

keeping up to date w/ HEAD.

demo site: http://hooknodeoperations.xcarnated.com/

dries’s picture

I'd like it better if you'd have separate functions for each of the actions. Then we could also get rid of the weird-ish callback argument.

hunmonk’s picture

I'd like it better if you'd have separate functions for each of the actions. Then we could also get rid of the weird-ish callback argument.

i can do that, but are you sure that's what you want? i'm in favor of keeping it because:

  1. it will save some code duplication in node module.
  2. we use state switches like this in nodeapi.
  3. most importantly, every time we add a functionality like this where modules can invoke their own callback function, it seems to me we always end up realizing that it's a more powerful and flexible approach to allow them to pass args into their callback function if they need to.

lemme know...

hunmonk’s picture

StatusFileSize
new4 KB

ok, i found a way to avoid the code duplication i wasn't happy about, while separating out the callbacks and also making the db queries for them more efficient. plus, i really like having a function called node_operations_sticky... :P

note that i left in the the ability to include callback arguments in hook_node_operations--it's an optional third element in the operation array elements that are returned, itself being an array of args to pass to the callback function.

when this patch gets committed, i'll write up doc on the hook.

my test site is down temporarily. sorry about that, i'll get it fixed up soon.

dries’s picture

Status: Needs review » Fixed

Committed a modified version of this patch. Thanks.

Anonymous’s picture

Status: Fixed » Closed (fixed)