Jan Boddez

Hm, that’s weird. Wondering if it’s the Mastodon server somehow. Did it work okay before? There hasn’t been a plugin update for like 2 months …

Other possibilities:

• Are these posts different somehow? Longer? With/without pictures? There might be a clue there.
• Do you use the “opt-in” setting? Delayed posting? One of the other “advanced” plugin settings?
• Have you otherwise customized the plugin (like, through a PHP code snippet)? Do you use any custom filters or …? (It could be a bug in a callback function …)

What could help find out what’s up is enable WordPress’ debug logging (you’ll need to define both the WP_DEBUG and the WP_DEBUG_LOG constant in wp-config.php) as well as enable the “debug” setting in WordPress’ Settings > Share on Mastodon screen (under the Debugging tab).

And then try again and look for errors in WordPress’ debug log (often under wp-content/debug.log, but it depends on your web host).

• This reply was modified 1 month, 4 weeks ago by Jan Boddez. Reason: Added additional questions

Hi again, took a bit longer than a day or two, but version 0.19.1 should fix this.

Before I do that (afraid I can’t just give WP-Admin access), I just noticed the update_23_7 function in lib/Updater.php, which seems to hold exactly the changes I was missing.

I was able to run, essentially, ALTER TABLE wp_bookly_customers ADD COLUMN tags TEXT DEFAULT NULL AFTER info_fields. The problem looks solved. (While I was at it, I also added the newly introduced option to the options table.)

No idea why the migration failed to run when the plugin was first updated.

Think I have a working fix, still have to release it, though. Give it a day or two!

It looks like you have PHP installed without the mime_content_type function (or rather, the Fileinfo extension). Or that your web host has somehow disabled it.

I’ll make sure to check for this in a next version of the plugin, although it could still mean posting images is not possible from your specific WordPress installation (but at least things wouldn’t break horribly anymore).

Alternatively, I may be able to do a quick and dirty check based on file extension (which of course requires that your image have valid extensions). This wouldn’t be as “clean,” but it’s not really an issue (in the end it’s up to Mastodon to properly validate media files).

Update: I think I may be able to cook up a valid fallback. Meanwhile, it’d be worth asking your hosting provider if or why this extension/function is disabled/blocked. They may be able to still enable it for you.

• This reply was modified 4 months, 2 weeks ago by Jan Boddez.

Thanks for the kind words!

Yes, the “challenge” is storing per-user auth details (and even client details, as different users could be on different Mastodon instances). Not really a problem but it requires rewriting part of the code plus deciding where to show the necessary form fields and so on …

Like, I’m actually looking into this, but it’s going to take … a few weeks at least. (And even then I can’t really guarantee anything, sorry!)

Hi! At the moment this isn’t possible, sorry. Maybe in a future version!

Thanks for the input! These are things I may consider in the future. I don’t think I can get those from the OPML itself (I’m not 100% sure though), but I guess I could always try to poll the feeds/sites themselves. (My feed reader plugin supports feed icons, for instance.)

So, it gets the WordPress excerpt but then cuts it off at (only) 125 characters.

What you can do is create an “mu-plugin” with the following code in it:

<?php

// Prevent direct access.
if ( ! defined( 'ABSPATH' ) ) {
  exit;
}

add_filter( 'share_on_pixelfed_excerpt_length', function () {
  return 400; // Or whatever number works for you.
} );

Or instead of an mu-plugin, you could also add it to your theme’s functions.php as long as you ensure it won’t get overwritten by subsequent theme updates, or you could add it through some plugin of sorts.

Not sure what max length Pixelfed instances typically allow, plus if you’re also going to include tags, etc., you may want to stay a little bit below the 500 or whatever characters is the real maximum.

You could also make that code a bit smarter, as long as it returns an appropriate number.

• This reply was modified 10 months ago by Jan Boddez.

Hmm, guessing there’s somehow a conflict with some of your custom code, or perhaps another plugin.

In any case, Share on Mastodon itself just uses get_permalink( $post_id ), like WordPress itself.

And to initiate sharing, it uses the save_post_{$post->post_type} hook, with a priority of 20.

So if you were to somehow overwrite post slugs whenever, e.g., the save_post or wp_insert_post hook runs, and thus after the hook Share on Mastodon uses, it could be there’s a kind of “conflict” there. Not really a “race condition,” but similar.

Have you tried setting a delay? If it’s a prio thing, that actually may work. Just 60 seconds or so.

If you use the Gutenberg editor but have not enabled the plugin’s “classic meta box” option, and you publish immediately, sharing to Mastodon doesn’t actually happen until the rest_after_insert_{$post->post_type} hook, which does run later in time, so that could indicate why it works in that case …

The delay relies on WP-Cron, which is triggered only when an actual request reaches your site. Like, if you were to serve all of your pages from Cloudflare’s edge cache, it could simply be the case that there isn’t enough traffic reaching WordPress and that the 5 minute delay becomes a 1 hour delay (or something). But you browsing the admin interface would be such a request, so … I mean, it should still work, probably. Merely protecting the login page likely isn’t the culprit (but who knows).

But you might wanna disable the delay just in case. There could be something else preventing WP-Cron from working reliably. (The WP Crontrol plugin can give some insights here.)

Depends on what exactly isn’t working. But if you see the toggle and have checked it (or it is checked by default) and nothing seems to be going through after you’ve hit “Publish,” it could be there’s a conflict of sorts with another plugin; or that your Mastodon server somehow still rejects WordPress’ requests. (Mastodon.social would publish my posts all right, but somehow reject all attachments; indieweb.social works just fine.)

We also had a couple issues around that time that would impact only a small percentage of WP installs, so … have you tried again since? (I’m guessing you have, but …)

The most obvious start is to enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php and enable the debugging checkbox under Share on Mastodon’s settings.

The resulting debug log (usually in wp-content/debug.log, unless you specifically set it to a different location or your web host has WordPress or PHP write to a different log file) may then tell us something.

Although it could also be, as another user reported, that the “sharing” flag seemingly doesn’t get saved at all. (We’ve never really figured that one out, unfortunately.)

So what you could also do, if that’s something you’re comfortable with, is after the toggle’s definitely enabled and the post was saved, check the (wp_)postmeta database table for a row with your post’s ID, and look for a _share_on_mastodon meta field; it should say "1".

Alright, cool! If you do encounter something, feel free to let me know.

I don’t normally run the Webmention plugin itself, just IndieBlocks, although I have tested with it in the past. But things change (and eventually break), so …

Hi, sorry for the late reply, I somehow missed this one.

I see you’re currently using (I think?) the Webmention plugin’s own “facepile option”? (But then it, too, somehow doesn’t seem to “filter out” the 2 “Bridgy responses.”) That’s the “original” Likes header and like you’re seeing. Which I believe can be disabled also in that plugin’s settings.

But then … the way the Facepile block works is two-fold: There is (1) the option in the plugin’s settings which you need to enable to filter the “regular” comment list (removes likes and such) and adjust the “comment count” accordingly. From what you’re describing, this part seems to work okay.

And then (2) there’s the Facepile block itself.

In fact, the Facepile block supports “inner blocks” and by default contains two more blocks: a heading and a so-called “Facepile Content” block. And you’re right: both will (or should) remain hidden if there’s nothing to show. So the fact that the heading shows means it “finds” something.

So if you add the Facepile block (and, in it, a Facepile Content block) and enable the Facepile setting on the Webmention tab (even if IndieBlocks’ Webmention option is disabled [because you’re using the Webmention plugin]), it should just work.

I just learned (from a different issue, haha) that it seems to work for others, e.g.: https://nicksimson.com/likes/1e88a68f6a/.

Anyway, if we assume it indeed finds those likes, then the only reason it doesn’t display them … is it probably can’t “find” an avatar for them. Except I’m not sure why that would happen.

Thanks for bringing this up! Will be fixed in the next version.