Sharing fails in v0.17.0 (Gutenberg)

[janboddez]

See also https://wordpress.org/support/topic/suddenly-stopped-working-54/

[janboddez]

This is a different bug than #87, which was (or will be) fixed in https://github.com/janboddez/share-on-mastodon/commit/5717fb036e011632a4e7e3d5f850db7ac17f7579 and thus in v0.17.1.

It affects only Gutenberg users, I think because only one call (to the REST API) is ever made.

[janboddez]

I think I can fix this by detecting if the _share_on_mastodon field was previously set (to 1). If so, I probably should not ignore the first call.

Let's say, however, that sharing used to be enabled, somehow didn't happen, and is now disabled before the user hits save.

If the Gutenberg panel is being used, the value will get saved OK before our function runs, and we return early. Had sharing not been disabled, everything would "just work."

If the old meta box is being used, the new, disabled (0) value will not have been saved when our function is first run (the old value is still active), and the post will, incorrectly, be shared. Now, Gutenberg users only ever get the old meta box if it is explicitly enabled, so we can check for this.

Update:

• (only) if Gutenberg users have explicitly enabled the meta box, ignore the first call as before (a 2nd call will take place)
• if Gutenberg users haven't, and thus get the new panel, do not ignore that first call

"Classic editor" users won't be affected; we never ignore any call for them (as they only get one anyway, and sharing can happen only once).

[janboddez]

If the Gutenberg panel is being used, the value will get saved OK before our function runs.

Looks like this is in fact not what happens, and the value is saved after "accidental" sharing has already taken place.

[janboddez]

I was hoping it was a prio thing, but I'm using a prio of 999 already.

Looks like I should be using rest_after_insert_{$this->post_type} instead, but only for Gutenberg users that haven't explicitly enabled the classic meta box (and thus get the new panel).

[janboddez]

Okay, so 20580f8 should fix this, but I'm meaning to still clean up the code

[janboddez]

Looks like I should be using rest_afterinsert{$this->post_type} instead, but only for Gutenberg users that haven't explicitly enabled the classic meta box (and thus get the new panel).

Long story short (haha, who am I kidding): when the new panel is in use, transition_post_status runs before metadata is saved regardless of its prio. We should use that new hook. (In the past, if things worked, that was because there were two calls, the first of which we ignored.)

[janboddez]

Can't we use the new hook always? Yes, we could, for Gutenberg users. For classic editor users, we should still use the old one.

But here's the thing: for Gutenberg users that opt to use the classic meta box (an option explicitly provided in case problems like this showed up), we should ignore the first request always, regardless of what hook is being used.

In conclusion: we can just always use the old hook, and schedule the "new" one only for Gutenberg + new panel users (first request, in this case!).

[janboddez]

So, this should be fixed in 0.17.1.