Sounds good to me!

To correct myself, it looks like the default for the WP plugin is to federate the full content, whereas I’ve opted to just use the excerpt, so assuming most other users don’t change the default, their followers do get the full post content inside the app. I don’t know if that still includes the link back to the blog, but then it’s less of an issue if the link doesn’t go to a browser (even though the reloading behavior may still look a bit confusing).

Thank you for the workaround!

I can see the appeal of staying inside the app, and would usually prefer it myself too, but cases like this do challenge the usefulness of that model.

FWIW, I’ve not come across posts from other sites exhibiting this yet, but then again I’m not following many WP blogs, and I suspect the issue could be prevalent there, as my settings for the ActivityPub plugin are pretty much at defaults.

I’m using the ActivityPub plugin to enable following posts from my WordPress blog. The posts federate as excerpts with a URL pointing to the full post on my site.

Tapping on that URL in the Android app only causes it to reload the post (excerpt) inside the app, instead of opening the URL in either webview or a browser as I’d expect it to.

The (official) IOS app does open the URL a browser, as does Firefox on the desktop, which is why I suspect the Android app being at fault here.

I don’t know of a way to link my blog here it so that it opens in the app (which is a bit ironic), but here’s a deck link to the federated posts on mastodon.social. My personal Mastodon account is on mastodon.social.

Both my Android phone and Android tablet are affected, both are on Mastodon version 2.2.1. The phone is running Android 10 (with Samsung’s One UI 2.0), the tablet is on Android 11 (One UI 3.1).

Below is a screen recording from the Android phone exhibiting the issue: the first tap of the URL opens the federated note in single view, and subsequent taps then just reload that same view.

Plugin version: 3.6.2

This is similar to one previously reported issue, but I have a specific situation where this occurs (and appears to be 100 % reproducible):

1. Start editing an article
2. Have your session cookie expire (to simulate, you can delete the cookie in browser settings)
3. Continue editing the article, or just wait until the next heartbeat, to have the login form pop up
4. Fill in the login form (over the editor) to log back in
5. Click Save draft

Result is the ”WP to Twitter: Security check failed” error page.

Thankfully, the draft has still been saved, and going back to the editor (using the browser’s back button) restores it. Also the next attempt to Save draft goes through without issues2 (I’ve only tried this using Firefox though, and can’t say if it’s as harmless in other browsers).

I haven’t looked at the code, but if the issue is caused by nonce invalidation at step 2, the plugin should probably update its nonce(s) when login-related hooks fire after step 3.

The function given to filter upload_filetypes on multisite returns the exploded array if the option already contains webp. Shouldn’t it be imploded back into a string before returning (i.e. unconditionally, outside the if condition)?

WordPress should not display private posts in public RSS feeds, except for those privileged users you mentioned, and even they need to be viewing the feed in a browser where they’ve logged in to your site. If your WordPress does display private posts in the feed for everybody, there’s something wrong; perhaps a misbehaving plugin or theme.

[Since version 4.1.6](https://wordpress.org/support/topic/how-to-disable-mshots-service/#post-12939728), Akismet has a filter which [allows you to turn off the site preview popups](https://wordpress.org/support/topic/how-to-disable-mshots-service/#post-12944077) (”mShots”):

function disable_akismet_mshots( $value ) {
return false;
}
add_filter( ’akismet_enable_mshots’, ’disable_akismet_mshots’ );

Happy to see the plugin get a new lease on life from an active and engaged developer. I only use a small portion of the features (suggested local tags), but this features alone makes it one of the most useful plugins for me.

Thanks for keeping Simple Tags alive!

Simple Tags is great in picking exact local tag matches from the post text, but with Finnish (and probably some other languages as well), inflection often causes it to miss relevant suggestions (from Local tags). For instance, when using the inessive case ”Helsingissä” in the post, Simple Tags won’t suggest (previously added local tag) ”Helsinki”.

A fuzzy matching feature would help here.

While Simple Tags’ future was in limbo, I tested some other plugins, and one of them (maybe Smart Tag Insert) had such a feature: it showed related tags using some kind of fuzzy matching. I have no idea how difficult this feature would be to incorporate into Simple Tags though.

I know I can show all tags with the ”Click tags” feature, but with close to 2000 pre-existing tags, the full list is quite unwieldy.

The release of WordPress 5.0 brought up an issue with the use of gutenberg_parse_blocks() in aesop.php: apparently for WP versions with Gutenberg integrated, parse_blocks() should be used instead of gutenberg_parse_blocks(), otherwise a fatal error occurs when Gutenberg tries to redefine WP_Block_Parser_Block.