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.

[ericmann]

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.

[josephscott]

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

[ericmann]

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.

[ericmann]

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.

[ericmann]

Uses filters where appropriate.

[josephscott]

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

[ericmann]

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.

[ericmann]

Switch new action hooks to filters.

[markoheijnen]

To be honest I don't get the patch. Why use filters over actions and not use the data that get returned. I guess that is a mistake.

I think it is better to put in actions like #14283. Changing data that should be returned feels weird to me. Maybe that I can't think of any situation where this would be necessary.

[ericmann]

Replying to markoheijnen:

Why use filters over actions and not use the data that get returned. I guess that is a mistake.

If you look at the patch history, originally I was using filters only when data was being returned and actions elsewhere. But @josephscott recommended using filters for all methods for the sake of consistency in the API. Functionally, they serve the same purpose.

[ericmann]

Refresh patch to match latest version of trunk.

[ericmann]

Since actions are more appropriate hooks here, all filters have been replaced in the latest patch refresh.

[westi]

This looks good.

I agree that actions are more appropriate here to allow a plugin to action on the change but not to affect the returned data which is already a success value.

[westi]

In [20157]:

XMLRPC: Add some xmlrpc_call_success_* actions to some of the credit/edit/delete calls. Fixes #17109 props ericmann.