Add post-success action hooks to edit/create/delete calls.

[ericmann]

It was suggested in #14283 that we add call_success hooks for post creation using the Blogger API. The ticket was later expanded to add hooks for all relevant post/page methods.

We should extend this workflow concept and add hooks to all edit/create/delete calls for different data types (comments, media, etc) to make the XML-RPC system more pluggable.

These hooks should use the following format:

do_action( 'xmlrpc_call_success_{method name}', {object id}, $args );

These hooks should be called before returning data to the client, but should not be called before any processing is done or before error messages are created.

Add action hooks to the following calls:

• wp_newCategory
• wp_deleteCategory
• wp_deleteComment
• wp_editComment
• wp_newComment
• mw_newMediaObject

Post-related hooks are added by #14283.

In order to potentially modify the data before returning it shouldn't we be filtering instead and returning the filter variable?

Replying to josephscott:

In order to potentially modify the data before returning it shouldn't we be filtering instead and returning the filter variable?

That's a good question. But I would say no.

For many of these calls, the only thing returned at this stage is the ID or a boolean representing whether or not the call succeeded. Adding a filter doesn't add any value, but adding an action hook provides the user with a way to further manipulate data or act on the content of a successful call after it's completed. But there's no further output at this stage to be filtered.

Replying to josephscott:

In order to potentially modify the data before returning it shouldn't we be filtering instead and returning the filter variable?

Actually, I've changed my mind. With the methods that actually return data, we should be using filters rather than actions. But not everything returns data. Some only return Boolean values that don't make sense being passed through a filter.

The new patch uses filters where they make sense, but sticks to actions where they don't.

Uses filters where appropriate.

Any reason not to make these all filters? Seems strange to allow for filtering the return value of some methods, but not others.

Replying to josephscott:

Any reason not to make these all filters? Seems strange to allow for filtering the return value of some methods, but not others.

It was based on return values. For example, the functions that return data (i.e. IDs) are using filters on the IDs. The functions that return bools (i.e. success/failure) fire an action instead.

My intention was to only use filters when the result of the filter would be returned by the function and use actions elsewhere to still allow devs to hook in to the function.

Switch new action hooks to filters.