Sorry, I was tracing this on a test site using a mockup, and apparently the <span> is actually only added once the post is published, so the issue doesn’t manifest when using previews. That’s why I never caught it while actually writing the posts and using previews, only after publishing.
The trailing <span class="__iawmlf-post-loop-links"> element introduced in PR #338 causes WordPress to render a trailing newline as a <br /> tag in the last paragraph. This behavior differs from when Link Fixer is not active.
I don’t know if the block editor is affected, since I don’t use it, but the issue is present when using the Classic Editor, and even there you have to use the Code view (because Visual view either converts the trailing newline into a line with an , or strips the trailing newline when switching to Code view).
My guess is that this is wpautop trying to be smart about the content, seeing the trailing <span> from Link Fixer, and thinking it’s visible content, so the trailing newline in the actual content (as entered in the editor) should be rendered as a visible <br /> too.
This is probably a very niche issue, and I’m sure I can figure out a way to work around it, but I wanted to document it anyway.
</p> tagthe <span> to immediately follow the last word and immediately precede the closing </p> tag, with no newline before or after
the <span> is separated from the last word with a <br /> tag followed by a plain newline
Cool, thanks for the quick fix!
I’ve been using a custom template, which I’ve hooked in via the vlp_get_template filter in my theme, to format previews in the blog’s RSS feed to my liking.
With 2.2.8 this seems to be outright prevented:
“Fix: Only output link in RSS feed”
Indeed, there’s now a branching upon is_feed() in VLP_Link::output() before VLP_Template_Manager::get_template() is called, so my filter is never applied.
Would it be possible to have a filter for the feed case too? I see there’s been someone with a problem with their RSS feeds, but having just the link in the feed is a bit too simplistic for my use.
I’m still getting federated posts from updating old ones on my blog (with the plugin now at version 7.5.0). Not every time, but something like four out of maybe two dozen that I edited today (from 2018) have so far appeared on Mastodon.
Should I open a new report? I noticed the merged PR (above) mentions the block editor, whereas I’m using the classic editor.
A checkbox on the settings page to optionally disable federating updates of existing posts.
If you edit an old post, that is not yet on mastodon, then it is technically an Update Activity but it shows up on Mastodon after the Update, so Mastodon seem to handle Updates without the updated timestamp as an Create.
I edit old posts (from before installing this plugin) every now and then, and find it pretty awkward when this causes those posts to show up on Mastodon as if they were new — more so than not federating updates at all. That’s why I’d like to have that option: to be able to disable federating updates altogether.
Only federating updates for posts that have already shown up on Mastodon would be a better solution, but also a bit more complex I believe. (It’d require some way to keep track of this status, as also mentioned in the issue that the quote above is from.)
No response
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.