Or we could always “force opt-in” for posts older than, say, 30 minutes? Same for “Share Always”: this is (obviously) meant for new posts only. You write a quick note, hit Publish, expect it to be shared nearly immediately. You’re going to edit it later, it will already have been shared, so no issue there. But it _would_ prevent accidental “mass shares.” And, although not without risk, we could consider an upper limit to “delayed sharing,” to avoid conflicts.
The bigger issue is obviously with “Always Share” (or the `*_enabled` filter used the same way) and posts created before that setting was set. You don’t wanna mass-update those. So we could either use a somewhat reasonable cut-off date, or simply ignore, e.g., posts over a day old (_and_ hang on to the 15- or 30-minute limit for “WP Admin posts”).
That’d probably avoid the worst mishaps and not confuse existing users too much.
@jazzsequence You would normally use the `publish_post` hook, but there’s no way of knowing what happens _outside_ of that. One could be using the admin interface or an app, or a post could be scheduled …
(Actually, you use `transition_post_status`, because `publish_post` runs on updates too, and you compare old & new statuses, but even that doesn’t always work. With Gutenberg, that hook runs up to three times, and meta boxes are updated last, when your post’s already “published.”)
@jazzsequence There may be ways to detect exactly what is happening, I don’t know. It’s tricky.
I’ve just tried the “15 minutes means having to explicitly opt-in” and “always sharing is disabled (unless you use the filter hook) for posts older than a day.” That should prevent the worst scenarios.
With Gutenberg, there’s a post-publish panel too, I believe. I will eventually look into that, add a button or something there. But then I again can’t guarantee it works for apps and such