Wp-calypso: Gutenberg: Ensure we always use the latest custom Publicize settings

Created on 19 Nov 2018  ·  10Comments  ·  Source: Automattic/wp-calypso

Quoting @melchoyce:

I updated my message right before publishing to be something like “ignore this,” but the message didn’t update — it published with my old message

Unfortunately, it also ignored my publicize settings and published to Facebook, which I’d deselected from the list.

It appears that if we didn't manage to save the custom Publicize settings that the user specified, they will not be considered when actually publicizing the post.

We need to make sure that if the user updates the settings in the last second before publishing, we either block the publishing until the settings are saved, or we send the new settings together with the save request.

Jetpack [Goal] Gutenberg [Pri] High [Type] Bug

Most helpful comment

See https://github.com/Automattic/jetpack/pull/10673 and D21118-code.

I'm AFK starting tomorrow (now), sorry :( Can Luna be in charge of those patches?

All 10 comments

Changes to the Publicize message or connections immediately trigger an editPost, so it seems that what we need to do is disable the Publish button while that hasn't finished.

Hmm, tho it looks like that editPost doesn't change the post object (as returned by wp.data.select( 'core/editor' ).getCurrentPost()) immediately... :thinking:

Update, as Andrew pointed out (p1542646651566600-slack-gutenberg), getCurrentPost() gives the unmodified post, i.e. without edits. We need getEditedPostAttribute( 'jetpack_publicize_connections' ) andjetpack_publicize_connections( 'meta' )` here (which do reflect our edits).

However, 'Publish' ignoring these changes is in fact unexpected.

I'm starting to think that the problem is on the server side (i.e. JP's REST API), since checking the browser console's 'Network' tab reveals that the payload that is sent from the client when clicking 'Publish' has the correct custom Publicize message and connection settings.

My current hypothesis is that WPCOM_REST_API_V2_Post_Publicize_Connections_Field::update() (through WPCOM_REST_API_V2_Field_Controller::update_from_request, registered with register_rest_field in WPCOM_REST_API_V2_Field_Controller::register_fields) is executed _after_ the post is publicized.

Maybe we just need to modify some filter's priority to make sure that the post object is update from the REST request before it is publicized.

/cc @mdawaffe

Odd - this was working for me before. I guess there's a race condition :( I suspect it's what you pointed out above. I'll take a look.

See https://github.com/Automattic/jetpack/pull/10673 and D21118-code.

I'm AFK starting tomorrow (now), sorry :( Can Luna be in charge of those patches?

Fixed by Mike's Automattic/jetpack#10673 and D21118-code.

Was this page helpful?
0 / 5 - 0 ratings