WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 6 months ago

#38905 closed defect (bug) (fixed)

REST API: Bring consistency to the `rest_insert_*` actions

Reported by: rachelbaker Owned by: rachelbaker
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.7
Component: REST API Keywords: dev-feedback has-patch
Focuses: Cc:

Description

We are inconsistent on when we fire the rest_insert_* actions in the create_item() and update_item() methods.

I see three possible options here:

option A:
Immediately after the wp_insert_*() or wp_update_*() function - before any meta or additional fields are processed.

option B:
After the wp_insert_*() or wp_update_*() function and meta or additional fields are processed - before the response is prepared.

option C:
After the wp_insert_*() or wp_update_*() function and meta or additional fields are processed and the response is prepared - before the response is sent.

In the endpoint controllers we tend to do a mixture of B or C. Personally, I would expect option A.

Either way, we should be consistent here.

Attachments (1)

38905.diff (15.5 KB) - added by rachelbaker 6 months ago.
Fire the rest_insert_* actions after the initial object has been inserted or updated

Download all attachments as: .zip

Change History (6)

@rachelbaker
6 months ago

Fire the rest_insert_* actions after the initial object has been inserted or updated

#1 @rachelbaker
6 months ago

  • Keywords has-patch added; needs-patch removed

In 38905.diff I move the rest_insert_* actions to fire after the related object is updated or inserted. Thge patch also includes some shuffling and clean-up as well including:

  • Ensure we are passing the most current $post and $user objects to the update_additional_fields_for_object() callbacks.
  • Changes the function signature ofhandle_status_param() in the comments controller to accept just the comment_id as the 2nd parameter, instead of a full WP_Comment object. Only the comment_id is needed in the method, and I wanted to avoid adding another get_comment() function. (not married to this, just seemed like the most logical approach)
  • Renames some variables in the create_item() method of the Posts controller to be more explicit.
  • Minor fixes/clarifications to the rest_insert_* hook docs

#2 @joehoyle
6 months ago

This all looks good to me, though I'd like to get a review from @rmccue given how late in the cycle this is - it would be then good to commit asap to make rc1.

This ticket was mentioned in Slack in #core-restapi by joehoyle. View the logs.


6 months ago

This ticket was mentioned in Slack in #core-restapi by rachelbaker. View the logs.


6 months ago

#5 @rachelbaker
6 months ago

  • Owner set to rachelbaker
  • Resolution set to fixed
  • Status changed from new to closed

In 39348:

REST API: Always fire the rest_insert_* actions after the related object is updated or inserted.

Brings consistency to the rest_insert_* actions. Also includes some shuffling and clean-up as well including:

  • Ensure we are passing the most current $post and $user objects to the update_additional_fields_for_object() callbacks.
  • Changes the function signature of handle_status_param() in the Comments controller to accept just the comment_id as the 2nd parameter, instead of a full WP_Comment object. Only the comment_id is needed in the method, this avoids having to include another get_comment() call.
  • Renames a variable in the create_item() method of the Posts controller from $post -> $prepared_post to be more explicit.
  • Minor fixes/clarifications to the rest_insert_* hook docs

Props rachelbaker, joehoyle
Fixes #38905.

Note: See TracTickets for help on using tickets.