About a week ago my new posts stopped being posted to Mastodon. Of course I can’t think of any changes I made that would have caused it. I’ve been using it for months with no problems.
I’m using Version 0.17.0 on WP Version 6.3.1.
I’ve tried revoking and re-authorizing access. I turned on logging and I don’t see anything in the log file related to this plugin.
Can you tell me what the next step would be to trouble shoot? It’s such an awesome plugin and has been doing exactly what I need for many many months now.
EDIT: OK, going back through settings I see that there is a setting specific to this plugin to turn on debugging that wasn’t ticked. Somehow I managed to change the wp-config file without changing this setting. I will update once I publish a new post tomorrow.
That did it. I wonder if it was upgrading to the latest version of WP that caused the problem.
Honestly, the explanation under “Known Bugs” didn’t make me think that it had anything to do with my problem. It just says
If somehow the plugin’s “meta box,” i.e., the “Share on Mastodon checkbox” (e.g., on the “Add New Post” screen) has disappeared
The meta box was there and it was ticked. So there is no way I could have known from that that it related to not publishing.
Also, labeling the checkbox in the interface “experimental” doesn’t seem accurate either. It’s not an experimental feature. More like a workaround. It also doesn’t explain that it may be related to things not publishing.
Any way, just some thoughts. I really appreciate the plugin and hope that your update fixes things for good.
This is interesting. (I was able to reproduce the disappearing meta box, but not, I think, the problem you’re describing.)
It’s not an experimental feature.
Sorry about the wording. It was meant to be an “experimental” workaround for users that somehow didn’t like the new block editor side panel; I added it quite last-minute. But people are finding it works as a temporary fix for problems I had not encountered during testing, so I’m glad I did.
By any chance, are you using the block editor (“Gutenberg”)? Or do you have the “classic editor” plugin installed? Does your setup allow you to switch between editors? Or do you happen to use an entirely different “page builder”?
Oh, and a last question: do you use an app, or the WP admin web interface?
A-ha, so you were getting the “new” Gutenberg panel, and found it didn’t work for you, but the classic meta box does.
FYI, this is the “new” panel:
Whereas the classic meta box can be seen in your screenshot:
Now, I obviously wanted the new panel to work (when it does, it’s actually a bit more reactive than the meta box, which does not get refreshed on publish, a Gutenberg limitation), so I might have to add a debug statement or two in a next version.
Alright, I think what may be happening is the following (sorry for the technicalities):
When one or more meta boxes are present, the block editor actually makes two calls to WordPress’ back end, and our little plugin happily ignores the first one, because the per-post settings (checkbox value, custom message if applicable, etc.) are known/saved only after the second call.
If, however, there are no (“old-style”) meta boxes on the edit screen, the block editor only ever makes one call. Which is … ignored.
(You could try to confirm this by again disabling the “classic meta box” option and, in the block editor, enabling the “custom fields” panel, which happens to be a [rather big] meta box. Sharing should work, because two calls will be made, and so on.)
If you look again at my screen shot, you can see that I already/always have the custom fields metabox enabled (I need it for a different plugin). So would that disprove your theory?
I’m more than happy to work with you to solve the problem.
Did some testing, and with (only) the custom fields panel open, there’s two back-end requests (the first of which is ignored, yada yada), whereas if I “hide” it, there’s only one, and nothing happens. (Whenever I re-enable any plugin that adds a meta box, there’s always two requests.)
But, yeah, that kinda disproves it.
That said, I have come up with a fix for both the other issue and the “ignored single call” I just described, so maybe I should just try and get those out there. If it doesn’t solve your issue, at least there’s the workaround still.
There in fact is one specific failure mode that involves the custom fields panel. When it is open, anything in it will overwrite (in the second back-end request) whatever metadata was set through Gutenberg panels “natively.”
That’s a known WordPress core bug that’s been around for a while.
Now, it should *not* affect Share on Mastodon, because this plugin’s custom fields are “hidden,” i.e., prefixed with an underscore.
Like, the custom field that we use to tell the rest of code to proceed with sharing is _share_on_mastodon. We share only if it equals '1' or if the “Share Always” option is enabled.
However, it *is* possible to “unprotect” these fields, e.g., using a custom PHP filter. Some devs do that; I know I have, which is how I initially found out about the issue.
So that could also be it.
Only known workaround is to explicitly not “unprotect” this plugin’s post meta or … use the “classic” meta box. (The issue only affects Gutenberg + the “native” Gutenberg panel. Meta box users are “safe.”) Or use “Share always.”
Just FYI: The newest v0.17.1 is expected to fix both issues. I.e., if you’re using the block editor and wanted to give the default panel (i.e., not the “old” meta box) another try, feel free to again disable that one setting and try again.
If it still doesn’t work: well, at least there’s the earlier workaround; could still be a conflict with another plugin.
Viewing 15 replies - 1 through 15 (of 15 total)
The topic ‘Suddenly stopped working’ is closed to new replies.
