Request for hook after posts are completely updated via the rest API

[jazbek]

We have a post that has its title generated automatically using a concatenation of the title of a p2p connection and a meta value attached to the post.

Prior to 4.7 (we were using 4.6+ the rest API plugin) we've been using a method hooked to both wp_insert_post (if the post was edited via the regular admin) and rest_insert_$post_type (if the post was edited via the API).

We're now working on updating our code to work with 4.7, and our post titles are not being updated with new values any longer when they're edited via the rest api.

Ticket https://core.trac.wordpress.org/ticket/38905 moved rest_insert_$post_type to fire before the metadata is updated. There is no longer a hook that runs on the post after all of the post data ($post + all meta) is updated. We could hook into updated_metadata but that runs on every field and would be much more inefficient to use.

Would it be possible to add an action or filter to the rest api posts controller that a post can be passed through after it's completely done being updated?

[jnylen0]

Hi @jazbek - I wouldn't be opposed to adding a set of actions (rest_processed_* maybe?) that work as you've described. However, I wonder if either of the following approaches might work for you instead?

1. If you're using a custom post type, register it with a custom rest_controller_class that inherits from WP_REST_Posts_Controller and defines update_item and create_item methods that call the parent method, then perform your custom logic.

2. Use the ​`rest_request_after_callbacks` filter as follows:

<?php
add_filter( 'rest_request_after_callbacks', function( $response, $handler, $request ) {
        if ( is_wp_error( $response ) ) {
                return $response;
        }

        if (
                isset( $handler['callback'] ) &&
                is_callable( $handler['callback'], false, $callable_name )
        ) {
                switch ( $callable_name ) {
                        case 'WP_REST_Posts_Controller::create_item':
                        case 'WP_REST_Posts_Controller::update_item':
                                // Get $request['id'] and perform your custom logic
                                break;
                }
        }

        return $response;
}, 10, 3 ); 

[jazbek]

@jnylen0 awesome, thanks for the suggestions, either could work, and for now I can move forward.

However, it does seem like there should be an action in create/update that runs after the post and all fields are saved. It seems like that would be more useful than an action that runs when the create/update is "half" done.

I think it would be ideal if wp_insert_post and rest_insert_$post_type were "parallel" so to speak, like they were previous to the 4.7 release, or if that's not possible, it would be great if there were another rest hook "parallel" to wp_insert_post for rest requests.

[jnylen0]

Replying to jazbek:

I think it would be ideal if wp_insert_post and rest_insert_$post_type were "parallel" so to speak, like they were previous to the 4.7 release

These two are parallel now - unless you mean "the combination of wp_insert_post and the additional field updates". In any case I think we'd need to add a new set of actions/filters rather than moving the existing ones again, now that they've shipped in a stable release.

However, it does seem like there should be an action in create/update that runs after the post and all fields are saved. It seems like that would be more useful than an action that runs when the create/update is "half" done.

We could structure this as a set of filters that operate on the API response after a successful create/update.

@rachelbaker - your thoughts on the purpose of the current rest_insert_* actions and possible next steps here would be helpful.

[TimothyBlynJacobs]

"Duplicate" of #42864. This was just committed and I think should solve your need @jazbek.