The Block Editor, Custom Meta, and ActivityPub

I’ve been using WordPress’ “new” block editor for quite a while now, have moved my site over to a block theme, and so on, but I also almost always have a couple “old-style” meta boxes open.

And because of how WordPress works, this combination of Gutenberg and meta boxes results in posts being “saved” twice, (less than) a second apart, whenever I click the Publish or Update button.

Now, this normally isn’t an issue, and most people won’t ever notice.

But plugins that rely on one of the “actions” that run whenever a post is saved, may get triggered more often than expected.

ActivityPub is one such plugin. (Share on Mastodon is, or rather, was, too; I spent a fair amount of time debugging this behavior.)

If you’ve “disabled” WP-Cron, you may not notice, because of the implicit delay between a post’s being saved, and it being sent (to followers’ servers).

But if you haven’t, there’s a decent chance that (1) a “Create” activity gets sent out right after a post is saved (during¹ the transition_post_hook, at which point, by the way, things like tags haven’t yet been processed), and (2) an “Update” activity gets sent out² a split second later (now with tags).

Is this a problem? Most likely not. But some Mastodon clients may show posts as having been edited without being able to display any actual edits.

And if, like me, 🤓 you’ve been experimenting with limiting “unnecessary” updates, some of your followers’ servers may be unaware of posts’ tags. (I’ve since addressed this.)

If eventually this needs fixed, I think the first step would be to have only Gutenberg installs use the rest_after_insert_{$post->post_type} hook instead. That would deal with “incomplete” Creates.

It’d also address potential future issues. E.g., if the plugin were to ever add a Gutenberg sidebar panel, that panel’s values too, will not yet have been saved at the time transition_post_status runs.

Whether the plugin should send an Update during a potential second back-end request (which depends entirely on the presence of meta boxes) could be investigated after.

1. In fact, the activity will get scheduled during this hook; it won’t be sent until WP-Cron is next triggered. Except that, in my case, it is triggered precisely by that second request I mentioned.
2. The same remark holds here, too. But, even if you weren’t going to click around WordPress’ admin interface, it “pings” its back end often enough that this won’t be long.