transition_post_status runs twice with same old and new status

[RavanH]

Describe the bug
When submitting a post update or an new post, it appears the transition_post_status hook(s) get called twice. First without the is_admin flag, then with is_admin passing true. The result may be unexpected as actions may behave differently or different actions may be included in both runs.

Please note this behavior is not seen with the classic editor.

Related issue #12897

To reproduce
I'll write a quick test plugin to show what is happening and how it may affect behavior...

[drov0]

I've had this issue for as long as gutenberg rooled out too.

In the end I used a mutex to make sure that only one of the two was taken into account.

[RavanH]

To show what is going on behind the scenes, I've made this little plugin:

<?php
/*
Plugin Name: Github Issue #15094
Plugin URI: https://github.com/WordPress/gutenberg/issues/15094
Version: 0.1
Author: RavanH
*/

add_action( 'transition_post_status', 'ghi15094_publish_action', 10, 3 );

function ghi15094_publish_action( $new_status, $old_status, $post ) {
	error_log('Request '.$_SERVER['REQUEST_URI']);
	error_log('transition_post_status '.$old_status.' > '.$new_status);
	error_log(print_r($_POST,true));
}

With WP_DEBUG on, this will reveal the difference between the two passes that occur with Gutenberg and not with Classic Editor (or older WP versions).

With Classic Editor on, when editing and saving an existing published post, the log entries will look like this (as expected) :

[23-Apr-2019 23:51:11 UTC] Request /wp-admin/post.php
[23-Apr-2019 23:51:11 UTC] transition_post_status publish > publish
[23-Apr-2019 23:51:11 UTC] Array
(
... LONG ARRAY HOLDING ALL POST DATA ...
)

But with the block editor it's like this:

[23-Apr-2019 23:55:37 UTC] Request /wp-json/wp/v2/posts/5277?_locale=user
[23-Apr-2019 23:55:37 UTC] transition_post_status publish > publish
[23-Apr-2019 23:55:37 UTC] Array
(
) <<< EMPTY ARRAY !!!

[23-Apr-2019 23:55:38 UTC] Request /wp-admin/post.php?post=5277&action=edit&meta-box-loader=1&_wpnonce=c53452de80&_locale=user
[23-Apr-2019 23:55:38 UTC] transition_post_status publish > publish
[23-Apr-2019 23:55:38 UTC] Array
(
... LONG ARRAY HOLDING ALL POST DATA ...
)

This shows that both passes have the same post old/new status, but the first pass does not carry any $_POST data (empty array).

So simply testing for post status (old or new) does not allow us to distinguish between the two, nor can we rely on up-tot-date post data or (custom) post meta data as the first pass will fetch such data from the database, not from the post submission.

It does show however, that we can work around the issue by polling for an empty $_POST array. Like:

function ghi15094_publish_action( $new_status, $old_status, $post ) {
	if ( empty($_POST) ) return;

	// Do our action on the second pass with the block editor, on the first with the classic editor.
	// Note: updated (custom) post metadata is also available in the $_POST array!
	// Fetching such data with get_post_meta will likely get the old data because meta data is 
	// typically saved at "save_post" which runs after "transition_post_status"...
}

[RavanH]

Hmmm... come to think of it, that won't work for planned posts. A future post transitioning to published status shows these log messages:

[24-Apr-2019 14:33:13 UTC] Request /wp-cron.php?doing_wp_cron=1556116393.1422309875488281250000
[24-Apr-2019 14:33:13 UTC] transition_post_status future > publish
[24-Apr-2019 14:33:13 UTC] Array
(
)

Which means we cannot distinguish between the first Gutenberg API pass and a publication via WP Cron... We'd need something like an is_rest() flag here as suggested three years ago on https://core.trac.wordpress.org/ticket/34373 or manually test for defined( 'REST_REQUEST' ) && REST_REQUEST like:

function ghi15094_publish_action( $new_status, $old_status, $post ) {
	if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) return;

	// Do our action on the second pass with the block editor, on the first with the classic editor.
	// Note: updated (custom) post metadata is available in the $_POST array!
	// Fetching such data with get_post_meta will likely get the old data because meta data is 
	// typically saved at "save_post" which runs after "transition_post_status"...
}

[RavanH]

Improved test plugin, shows which flags are present during the different passes, and on different occasions:

<?php
/*
Plugin Name: Github Issue #15094
Plugin URI: https://github.com/WordPress/gutenberg/issues/15094
Version: 0.2
Author: RavanH
*/

add_action( 'transition_post_status', 'ghi15094_transition_action', 10, 3 );

function ghi15094_transition_action( $new_status, $old_status, $post ) {
	error_log('Transitioning post from "'.$old_status.'" to "'.$new_status.'"');
	error_log('Request: '.$_SERVER['REQUEST_URI']);
	if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) error_log(' - Is a REST request');
	if ( is_admin() ) error_log(' - Is an admin request');
	if ( !empty($_POST['action']) && 'editpost' == $_POST['action'] ) error_log(' - Submitted from post edit page');
	if ( !empty($_POST['action']) && 'inline-save' == $_POST['action'] ) error_log(' - Submitted from Quick Edit post list');
	error_log(print_r($_POST,true));
}

[RavanH]

Further testing shows that issue #12897 is indeed related: when switching a post from draft to publish, the first REST API pass will say draft > publish without $_POST data while the second pass will say publish > publish but with the $_POST data. So there is actually NO way to both test for draft to publish and have up-to-date post or post meta data available at the same time...

This is completely useless when we need the actual posted data (not what is stored as draft in the DB) on an new publication (not a post edit) :'(

[rgomezp]

I'm also having the same issue

@drov0,
Could you please provide some more info on how exactly you used a mutex to solve this? Would appreciate it

[noisysocks]

This was also reported here: https://core.trac.wordpress.org/ticket/47548

[noisysocks]

I can confirm that this happens but am not yet clear on why. We'll need to do some more digging. It could be due to the extra HTTP request made by saving meta boxes. Maybe this second request happens so soon after the first that the database hasn't had a chance to update, yet.