Closed jazzsequence closed 1 year ago
There are no dependencies, but the "instance URL" should be the "bare" instance URL (e.g., https://mastodon.social, or https://fosstodon.org and so on).
I'm making this more clear/robust in the next version (which isn't out, yet ...). But if you tried that, it should work. (I just tried it with your instance :-) and it worked.)
Once you've done that, you'll see an Authorize button that'll bring you to your instance so that you can approve WordPress posting to your timeline. (At this point, WordPress will know your user as well. That is, the user's [obviously] tied to the auth token being exchanged in the background.)
When you've done so, you'll get sent back to WordPress and things should "just work." (If you want to customize Mastodon statuses and stuff, the docs should be able to get you on your way.)
Hmm...that's what I have. I just tried in Chrome (was previously using Firefox) and getting the same thing. There's no way to "force" the process to jump to the Authorize step? I can test on another machine as well and see if that makes any difference.
Oh, that's a first.
There's no way, at least for now, to bypass this bit. In fact, the error is only shown because your WP install somehow could not register a new API client with your Masto instance, and that's the first step.
Must be WordPress is somehow "blocking" the background request toward your instance, or something else is failing.
What you could do is enable debug logging by adding the necessary constants to wp-config.php (not sure how much experience you have with this sort of thing). If you then refresh the settings page or again hit Save Changes it may write something to the debug log.
If the logging shows nothing, we could try adding some more useful error_log()
calls, try to pinpoint exactly what's going wrong, but who knows, maybe the current statements suffice.
I just put in https://mstdn.social in my local install and it worked OK ...
👍 Yep, I can try firing up a local and playing with it, I was just wondering if there was something that was obviously conflicting (which is why I asked about XML-RPC, which I doubt anyone uses anymore).
I mean, you can manually define apps when logged in to Mastodon, and try to copy all the keys over into your WP database, but it's an extremely hacky process and not something I've done before. (Although I could make that sort of thing a bit easier in a next version.)
I SSH'd into the server to see what the debug log was saying and here's what I found.
[03-Feb-2023 23:11:38 UTC] WP_Error Object
(
[errors] => Array
(
[http_request_failed] => Array
(
[0] => cURL error 60: SSL certificate problem: certificate has expired
)
)
[error_data] => Array
(
)
[additional_data:protected] => Array
(
)
)
Not super descriptive (e.g. what's actually triggering the error) but I guess that's something.
FWIW the site is binaryjazz.com and I doublechecked and it has a valid Let's Encrypt SSL cert, so I'm not sure what certificate it's referring to that's expired.
Yeah, strange. I know PHP's cURL functions let you bypass SSL verification (which you probably shouldn't do, but it could help troubleshooting …) but I'm not sure if there's a way to filter WP's HTTP requests. I'll have another look tomorrow.
Meanwhile, maybe Google can help. But it's def something that's blocking the normal auth flow.
So, two updates.
mu-plugin
that was pretty specific in scope to get the job done:<?php
/**
* Plugin Name: SSL Verify Disable
* Description: Disables SSL verify to fix Mastodon plugin.
* Author: Binary Jazz
* Author URI: https://binaryjazz.com
*/
namespace BinaryJazz\SSLVerifyDisable;
function init() {
add_action( 'admin_menu', __NAMESPACE__ . '\\maybe_disable_ssl_verify', 999 );
}
function maybe_disable_ssl_verify( $pagenow ) {
global $pagenow;
if ( $pagenow !== 'options-general.php' ) {
return;
}
$slug = isset( $_GET['page'] ) ? esc_attr( $_GET['page'] ) : false;
if ( ! $slug || $slug !== 'share-on-mastodon' ) {
return;
}
add_filter( 'https_ssl_verify', '__return_false' );
}
init();
Yeah, I've seen reports on upgrading your PHP version and whatnot, but no idea what causes it in this particular case. It's almost definitely a server thing, though, outside WP or this plugin.
Glad it works, although I now wonder if actually syndicating posts will work?
Otherwise, the https_ssl_verify
does accept a URL, so you could "simply" do something like:
add_filter( 'https_ssl_verify', function( $ssl_verify, $url ) {
if ( preg_match( '#^https://your-instance.url#', $url ) ) {
$ssl_verify = false; // Mastodon API stuff.
}
return $ssl_verify;
}, 10, 2 );
Didn't actually test that, but you get the idea.
Good thought. I went ahead and made the change rather than waiting for it to (potentially) fail. I've got a post scheduled for Friday (I've already added the share_on_mastodon_enabled
) so we'll see if that does it. 🤞
Hi! I'm just trying to use this plugin to share post links to Mastodon. After adding the Instance URL and saving, I just see "Something went wrong contacting your Mastodon instance. Please reload this page to try again." under Authorize Access. Is there another step that I'm missing? It seems like it's supposed to make an authentication request but that never happens, and there's no way for it to know what my Mastodon user is. Is there a dependency on XML RPC or something?