Jan Boddez

Oh, I hadn’t yet heard of that use case!

You should be able to filter the status messages, like use PHP’s str_replace() to replace the local with your public domain. This of course requires you’re able to add code snippets someplace, like in functions.php, a custom (must-use) plugin, or through the use of a separate “code snippets” plugin:

Just a quick example:

add_filter( 'share_on_mastodon_status', function( $status, $post ) {
  $status = str_replace( 'http://localhost.test/', 'https://www.example.org/', $status );
  
  return $status;
}, 10, 2 );

This would modify the message before it gets sent to your Mastodon server.

Of course, depending on how or when the static pages are pushed to your web host, Mastodon instances might temporarily hit a 404 and cache the wrong link preview data. (It might be possible to work around that by setting a delay, under the plugin’s advanced settings. But maybe I’m overthinking things.)

Strange indeed. Sounds like maybe it was a temporary server hiccup after all. Or some caching thing. Either way, good it’s working again!

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 year, 8 months ago by Jan Boddez. Reason: Added additional questions

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 1 year, 11 months ago by Jan Boddez.

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

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

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.)