Scheduled posts not sharing

I have also discovered that I can also trigger the share by making any single edit to the post, without needing to touch the Share on Mastodon switch.

without needing to touch the Share on Mastodon switch

You mean with the toggle disabled? Because it is enabled by default … which will get your post shared.

If it shares even when it is disabled … did you perhaps check the “Share Always” option on the plugin’s settings screen?

Re: scheduled posts, I can’t say I’ve been able to reproduce this behavior (i.e., “it works on my machine”). The so-called “hook” the plugin uses to trigger sharing should work the same regardless of how or when the post was set to “Published.”

Which editor are you using? The block editor, classic editor, or something else (third-party app …)?

To clarify, the switch does indeed get set on automatically. My original thinking was I had to toggle it off and back on to get the share to happen, but in fact with the switch already (automatically) on, any update to the post triggers the share.

I am using a fairly plain setup and the block editor. I do have the Twentig plugin which adds blocks, and have some host-specific caching.

I also still have Jetpack Social installed, but the “Automatically share your posts” switch has been off since before these posts were created.

Oh, and I also have a VERY rudimentary plugin I created to customise the share content, per your blog posts. Here’s the entire thing (apart from comments).

add_filter( 'share_on_mastodon_status', function( $status, $post ) {
  $status  = $post->post_title;
  $status .= "\n\n" . wp_strip_all_tags( $post->post_content );
  return $status;
}, 10, 2 );

Re: the toggle: clear! Looks like at least that part is working as intended. (There’s also an “opt-in” option, by the way, which will disable the toggle by default; you’d then have to explicitly enable sharing for those posts you want shared.)

I tested scheduled posts, and it … just worked. Or rather, I did initially have an (unrelated to this plugin) issue getting scheduled posts to work. After that was solved, sharing to Mastodon worked.

You’re sure scheduled posts work as intended, right? Because editing a post that missed its scheduled date could also result in it being published after all, and (only then) posted to Mastodon.

In fact, I tried it again just now, and it … still works. :-S

Other things you could try is give it another go with all other plugins disabled, or enabling WordPress’ debug logging (requires a small change to wp-config.php) as well as Share on Mastodon’s debug setting (Settings > Share on Mastodon > Debugging). And look for any obvious errors in the resulting debug.log file.

Or, if you’re familiar with WordPress’ database and such … After it is scheduled, your post should have a “hidden” post meta field called _share_on_mastodon, and its value should be '1'.

And then when it is published (automatically), WordPress kicks off a series of “events,” one of which will trigger posting to Mastodon. Exactly the same code gets called for both scheduled and “regular” posts, though, so …

• This reply was modified 1 year, 1 month ago by Jan Boddez.

Yes, the posts are publishing on their own, I can see them on the site and in the admin interface they show as published.

I will go look in the database, but I assume that field is reflected in the switch visible in the post editor? I’ve got a couple just about to publish now so will look at those after they go live, as well as some future ones.

I can do the debug thing in a day or two. I was hoping you’d come up with some things to check (and you did) before getting to the “disable all plugins” but I guess that won’t be too cumbersome on this site.

So the database approach proved interesting…

Descending order of post ID (and time as it happens). Everything below the red line has published. The top two (Cat and Trouble) just minutes ago. No sign of any SoM meta values. All those below those two have been manually ‘goosed’ to share.

I then edited the post titled “Workhorse” which has yet to reach its publish time. The SoM switched showed, and was on, but re-running the SQL shows it still has no meta values.

I guess it can be deduced that the actual publish workflow is not at fault… it’s not getting the right meta for that to work unless I edit it when already published.

• This reply was modified 1 year, 1 month ago by zkarj. Reason: Clarification

Yeah, that is weird. I just did a test post, and checked the wp_postmeta table prior to it going public, and it definitely is there (for me):

+---------+---------+----------------------+-------------
| meta_id | post_id | meta_key             | meta_value  
+---------+---------+----------------------+-------------
|   62952 |   16392 | geo_address          | Olen, BE    
|   62949 |   16392 | _edit_last           | 3           
|   62948 |   16392 | _share_on_mastodon   | 1           
|   62947 |   16392 | _indieblocks_kind    | note        
|   62946 |   16392 | _edit_lock           | 1698352114:3

Now, what I don’t get is why it wouldn’t get saved when you click “Schedule” but does get saved when you click “Publish” or “Update.”

That’s another thing you could test: open your browser’s “dev tools” (F12, normally), and look for a “network” tab. Then create a new post, set a future date, click “Schedule” (and confirm if needed). You should see a POST request (to wp-json/wp/v2/posts/<etc.> or something). If you click “Request,” it should show a JSON object similar to the one below:

(If you click “Response,” it should show a similar object but with more properties.)

Anyway, besides a post content and title and so on, there should be a meta property with at least _share_on_mastodon in it.

You could even run the same test for a “regular” post, clicking “Publish” instead.

If we somehow can’t figure this out, I see two possible workarounds:

1. Either set the “Share Always” plugin option, but this would always share all posts (that aren’t private or draft or …, of course).
2. Or try the “classic” meta box option, which uses somewhat different, or rather, much less, JavaScript and hopefully does register the value okay.

I think I found what you were after, and a bit more that is interesting.

This is what you asked about:

"meta": {
    "footnotes": "",
    "_share_on_mastodon": "1"
},

But then it gets interesting, as further down I see this.

"share_on_mastodon": {
    "errors": {
        "invalid_id": [
            "Invalid post ID."
        ]
    },
    "error_data": {
        "invalid_id": {
            "status": 400
        }
    }
},

Although, I just ‘goosed’ another post that published earlier today and kept an eye on the response for that.

"meta": {
    "footnotes": "",
    "_share_on_mastodon": "1"
},

"share_on_mastodon": {
    "errors": {
        "invalid_id": [
            "Invalid post ID."
        ]
    },
    "error_data": {
        "invalid_id": {
            "status": 400
        }
    }
},

I.e. the same stuff, and yet that one did share successfully. #shrug

What PHP version do you use? Could it be 8.2 or up?

The invalid post ID is thrown when it tries to fetch the URL after sharing. And I recently discovered a bug there that likely affects might affect PHP versions higher than 8.1. But that happens after sharing has taken place (or not).

But none of that explains why the value seems to be missing from the database. Saving (only) the _share_on_mastodon field happens through a different mechanism (which should be the same for scheduled/draft/published posts). And if the response does indeed say '1', that suggests it got saved …

• This reply was modified 1 year, 1 month ago by Jan Boddez.

Really appreciate your help on this, by the way. This type of feedback helps bring to light things I wouldn’t have caught (well, obviously …) myself.

It’s PHP 7.4. Last I checked (which was a while ago, admittedly) WordPress did not play nice with 8.x.

And yes, I can confirm the response shows the _share_on_mastodon value of 1.

Here’s Safari’s Object Tree view of the full response (because it’s easier to pick out the stuff we’re interested in).

So if the response says it’s recorded, but the database doesn’t have it… that suggests something is blocking the database write?

I tried turning on debug but for some reason it does not appear to work. Which is to say WP doesn’t even write a debug.log file for me. Maybe that’s something peculiar to my host, too.

Next step, I guess, is to try turning off other plugins.

I turned all the plugins off one at a time. With each one off, I edited a post, then ran the database query. Still no change — the flag is not written to the database. (And Jetpack is a pig.)