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.

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, 4 months ago by Jan Boddez.

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.

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, 4 months ago by Jan Boddez.

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.

Could also be WordPress’ “cron” (i.e., scheduling) functionality, which isn’t … exact at all. Not by default, at least. So it is absolutely possible that you set a delay of 5 minutes and got, e.g., 10 minutes instead.

The site going down after publishing could have to do with Mastodon. If you post a link (like, to your site), all these different Mastodon servers will fetch that link to try to generate a “preview card.” A caching plugin might help with that. But it could also be something else entirely.

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 …)?

The plugin filters out duplicate image IDs, so … did you perhaps upload the same image twice, once as a featured image and once as part of the post itself? If so, you could avoid that by selecting the “second” image (whichever that is) from the Media Library instead.

If not, can’t really say what’s going on. You could try to disable all but one of the various “image sources” on the plugin’s Images settings tab.

The way alt text works is, if it was saved to the Media Library, the plugin will look for it there. But: I don’t think merely uploading an image from the Edit Post screen is enough to get its alt text saved into the Media Library (this would be a core WordPress quirk, not something we can do much about), though, so the plugin will also scan your actual post content. Even if you’re uploading only a featured image.

If it can find the same image (with the same ID, see above) and it happens to have alt text in the context of your specific post, it will use that for the image uploaded to Mastodon.

You could just move the various template tags onto a new line each. Or add quotes or something around the title.

Just an example:

“%title%”

%excerpt%

%tags%

%permalink%

So, the overall “template” is defined at Settings > Share on Mastodon > Advanced. It’s a setting called “Status Template.”

And then there’s an option to still tweak it on a per-post basis. Which, when enabled, would give you a similar field on the New/Edit Post screen. (But you may not even need it.)

Awesome! (I think you might have a comma somewhere in the “template,” still. Not sure if that was intentional.)

So, the plugin takes WordPress’ default (either set manually or autogenerated) excerpt and then removes anything beyond 125 characters.

To increase this limit, you could try adding a bit of code to either your (child) theme’s functions.php file or a “must-use plugin.”

It’s probably easiest to simply drop a file called longer-excerpts.php (or something, it really doesn’t matter) in your WordPress install’s wp-content/mu-plugins folder (create it if it doesn’t yet exist), with the exact following contents:

<?php

add_filter( 'share_on_mastodon_excerpt_length', function() {
    return 400; // Or another "still safe" number.
} );

(If it somehow doesn’t work or you accidentally end up breaking the site, just remove it again!)

You may have to play with that number a bit to make things work for your use case.

Another possibility is to use a (much) more complex bit of code; like, I did actually create an add-on plugin that looks at the tags and so on to calculate a more optimal threshold, but it’s (currently) meant to work with specific post types only. A PHP developer would definitely be able to make it smarter, though.

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

As for importing comments into WordPress, there are several options:

• A first is to look into “Webmention.” There’s a Webmention plugin that lets other sites “ping” your blog when they mention or “reply” to it. And while Mastodon itself does not send out these webmentions, it is possible to use a free service called Bridgy. Bridgy does send webmentions (and, thus, comments) to your site whenever someone replies to one of your crossposted (i.e., to Mastodon) posts. (I think it may be able to share posts to Mastodon as well, similar to what this plugin does, but it might not be as configurable.) This is what I currently use on my blog (well, except I use a plugin called IndieBlocks rather than the Webmention plugin); an example result would be the different reactions on this page: https://jan.boddez.net/articles/share-on-mastodon-v0-17-0.
• Another is to instead explore “native” ActivityPub, which means turning your blog into an “ActivityPub actor” of its own, separate from your current Mastodon account (but from which you could, e.g., “boost” your blog’s posts); this requires the ActivityPub plugin. This is a bit different from “simply” crossposting, though, and may be more taxing on your server. That said, any comments should make it back to your blog.
• A third would be to use a different “variant” of the above-mentioned Bridgy tool called “Bridgy Fed,” which not just sends webmentions but also does something similar to the ActivityPub plugin (i.e., turn your blog into an actual “Fediverse actor”). I have limited experience (as in, none) with this one, unfortunately.

Hi Ellie, glad to hear you got it working.

Just to recap/for others that may see this, it is possible to set up a custom “template” over on the Share on Mastodon settings page, and use the %title%, %excerpt%, %permalink%, and %tags% “template tags.”

In the case of shortish, mostly plain-text posts, %excerpt% might be enough for your needs. If needed, a bit of custom code (like, one line) can be added to make this “excerpt” a bit longer (although if the overall message, including hashtags and so on, becomes too long, your Mastodon instance will reject it) and include more of the post text.

There’s also an extra option to tweak this same template but on a per-post basis. (Like, in case you ever don’t want to include the title or permalink or something.)

If that doesn’t do and you’re not afraid of a little PHP (the programming language WordPress is written in), please have a look at https://jan.boddez.net/wordpress/share-on-mastodon#share_on_mastodon_status, as it is possible to customize Mastodon statuses even more, programmatically. There’s a few more examples floating around the web, let me know if you need some pointers.

Content Images are displayed in order or last image on page to first image on page.

I think this might be because they happen to also be attached images (i.e., were uploaded during post creation and not elsewhere, e.g., through the Media Library directly), and that you have the “attached” images setting enabled (but not the “in-post” images)?

And that the order is in fact based on image (database) ID and thus upload order. Which happens to be … their order of appearance, yet reversed.

And that this should resolve itself if you switched to “in-post” images … (If the plugin can find them! WordPress is a bit tricky in this regard.)

At least that’s what the tests (and code) seem to suggest.

Ran a couple tests and found another bug (in which large images that get rescaled during upload are missed by the “in-post” setting). ??

That said:

• If (only) “attached” images is enabled, the order should be the order in which the images were uploaded.
• If (only) “in-post” images is enabled, the order should be as they appear in the post.
• If several options are enabled, it’s trickier: in-post images come first (as they appear in the post), followed by the featured image, followed by attached images (older images first). Then, any duplicates are removed. And finally, only the first four remaining images are kept. These four are the images that will be uploaded.

Upcoming changes:

• I’m going to put the featured image (if enabled) first.
• Then in-post (if enabled) images, in order of appearance. I will update the settings page accordingly.
• And then, if enabled, “attached” images (which is a bit of a misnomer, but I may have already mentioned that). Order will be oldest to newest, still.