Open Aluhut opened 2 years ago
Hm, this sounds like it might be related to https://github.com/janboddez/share-on-mastodon/issues/22.
That was fixed here: https://github.com/janboddez/share-on-mastodon/commit/3c90be3b225d9f4f5140321d608d724c0ff6146e, but the fix hasn't yet been released to the WP plugin repo, so the version there is in fact outdated, still. Let me take care of that, and apply the same fix in "Share on Pixelfed."
Would you mind sharing your blog's URL? If the images are indeed behind a CDN, that could point to the issue above.
Could be the mobile app, too, although I have very little data to work with there. Wasn't able to replicate previous issues, and I could never really exclude a different root cause (like the CDN thing above). Would be nice if you could help trying to get to the bottom of this.
Hm, this sounds like it might be related to janboddez/share-on-mastodon#22.
Actually I doubt that, because when I post from WP itself (from my computer, not mobile) it works oftener I think
Would you mind sharing your blog's URL? If the images are indeed behind a CDN, that could point to the issue above.
Sure, its anyway public :) https://www.andreas-l-berg.com/blog/
Could be the mobile app, too,
that's what I guess but I have no clue what's the difference
(like the CDN thing above).
I don't know what that means
Would be nice if you could help trying to get to the bottom of this.
Im totally down (even for pretty selfish reasons :) ), just tell me what you need or what I need to do!
Cool! I think you're setting these as Featured Images, that's good. I also see you're using Jetpack's CDN. What that means is the plugin is probably looking for a resized version of these images, in the wrong place. Aka, I made a mistake and need to fix the code in WP's plugin repo.
I'm going to try to pick this up this weekend.
Okay, so, if you're feeling adventurous, you could, in the meantime, replace wp-content/plugins/share-on-pixelfed/includes/class-post-handler.php
with https://raw.githubusercontent.com/janboddez/share-on-pixelfed/master/includes/class-post-handler.php and see if that somehow helps.
I have to admit I just noticed the message at the bottom "Something went wrong contacting your Pixelfed instance. Please reload this page to try again.". As much as I recall I didn't had that message before but im also pretty sure the URL is properly. Maybe we should proceed with the mastodon plugin, because that's well connected and only have that issue as described, in the meantime I'll try to solve the connecting thing. But anyways,
you could, in the meantime, replace
Done!
Something went wrong contacting your Pixelfed instance. Please reload this page to try again.
That would indicate your WordPress install has not been given a client ID and secret by your Pixelfed instance. Could be the URL is wrong, the server is down or returning an error, or a bug I've yet to discover.
If you were to enable debug logging, you should see [Share on Pixelfed] Could not register new client.
in the log somewhere, probably followed by the instance's response (a large array of data that may, somewhere deep down, contain a description of what went wrong). :-)
Debug logging can be enabled by setting the following in wp-config.php
:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true); // Alternatively, set this to the absolute path of your desired debug log file.
define('WP_DEBUG_DISPLAY', false); // Prevent errors from showing on the front end.
If you stick with the default values, the debug log will be generated at wp-content/debug.log
. May be a different location, though, it really depends on your web host. Also, depending on your server settings, this file may or may not be publicly available, so best to disable and remove it after you've saved it offline.
Anyhow, if you're able to set this up and then try again (add and save an instance URL, the plugin should try to get a client ID and secret automatically), and there are indeed [Share on Pixelfed]
notices in the generated log file, feel free to email it to me so I can have a closer look.
This is what my settings look like. I.e., if you're on Pixelfed.social, the URL should simple be https://pixelfed.social. But the logging should be able to tell us what's really going on.
That would indicate your WordPress install has not been given a client ID and secret by your Pixelfed instance. Could be the URL is wrong, the server is down or returning an error, or a bug I've yet to discover.
done! I was just a little dumb and had also my username written. I guess it happened through all that trial and error procedure.
If you stick with the default values, the debug log will be generated at
wp-content/debug.log
.
I've done that above but no debugging file falls out. I looked in almost every place on my server that I could think of. :(
I'd also just uploaded a new post just to test the two plugins, but neither on mastodon nor at pixelfed is anything to see. But you can see it on my blog now if that somehow helps.
Does that mean you've now successfully coupled WordPress to your Pixelfed instance?
Log files might be outside of public_html
, in a logs
folder or similar. Or in /var/log/<php-something>
, it really depends.
Alternatively, you could choose to enable DEBUG_LOG_DISPLAY
after all, update any post, and look for any output on the Edit Post screen or in its source, and immediately disable it again. Would only work if authorizatoin now went fine.
Does that mean you've now successfully coupled WordPress to your Pixelfed instance?
Yes, success! Your screenshot showed me what I did wrong :)
Alternatively, you could choose to enable
DEBUG_LOG_DISPLAY
on the wp-config, right? I set it now with "true" but I don't know where to find any other debug file, I searched again the server and couldn't find any change or new file.
update any post, and look for any output on the Edit Post screen or in its source
I did it from my computer, directly in WP and it worked fine. Tried afterwards the mobile up and did something similar and nothing to see on any platform. What I noticed while I did that was, in WP I have in the sidebar both plugins "share on $socialmedia", whats not visible when I use the mobile app. Might that indicate something?
Oh, I see. Cross-posting normally depends on a setting set in the admin interface, but all that can be worked around with the following bit of code:
add_filter( 'share_on_pixelfed_enabled', '__return_true' );
You would add that to, e.g., functions.php
. A site-specific must-use plugin would also work.
I'll update the documentation to make this clearer.
Perhaps in a future version, this could be an actual setting.
Note that this will enable sharing for every post (that meets the other conditions, i.e., has a featured image, etc.), regardless of the state of the checkbox on the Edit Post screen.
A more advanced filter would allow sharing, e.g., only posts that belong to a certain category, and so on. Again, I'll try to make this clearer.
You would add that to, e.g.,
functions.php
.
ok, cool! I just put it on the bottom of it, that works, right?
And same goes for mastodon, then?
add_filter( 'share_on_mastodon_enabled', '__return_true' );
My target is to crosspost to all sites that I have sharing enabled in wp, but I use my blog anyway just for that one purpose.
Yes, awesome it works on both now! Thank you! Im really happy now! :)
If you'll build it in the plugin in a future Version, please let me know if I have to change something from what I did recently.
wait... I just posted a new picture. For mastodon it worked, on pixelfed its not visible. ;(
And same goes for mastodon, then?
Yes. One remark: if you're not yet using a child theme to make these modifications, they will be overwritten when your theme updates. Not sure how your site's set up, but this may be something to look into. Otherwise, just create a new file, sharing.php
or something, inside wp-content/mu-plugins
(just create the folder if it doesn't exist) with the exact following contents:
<?php
add_filter( 'share_on_mastodon_enabled', '__return_true' );
add_filter( 'share_on_pixelfed_enabled', '__return_true' );
As for Pixelfed not working ... If you again create a log file (empty it first, then try updating the post or publishing a new one), I'll have a look.
I try to always keep changes backward-compatible, and have filters overwrite whatever is set in the GUI so that developers remain able to completely customize the default behavior.
(just create the folder if it doesn't exist) with the exact following contents:
Done!
As for Pixelfed not working ... If you again create a log file
Done, but no entries, just the before seen matzo errors (yes I emptied it before I made that post) btw. when I edit that post, it'll show up... weird behavior!
I try to always keep changes backward-compatible, and have filters overwrite
Ah cool, thanks!
If you enable debugging, do you see values for the different settings at the very bottom of the Share on Pixelfed settings page? Is the instance still correctly connected? Example:
If you don't see any error/server response in the log, that would indicate an error here, an unsupported post type, or that the post was already shared.
Can you also add the following to your newly create mu-plugin file?
add_filter( 'is_protected_meta', '__return_false' );
After that, can you go to the Edit screen, in the admin interface, for that post, and enable the Custom Fields view/meta box?
Should look something like this:
Just want to make sure there really isn't a value for _share_on_pixelfed_url
.
It could also be a server error, maybe they're configured to not accept photos over a certain size? Although in that case I would expect a response clarifying what's wrong.
If you enable debugging, do you see values for the different settings at the very bottom of the Share on Pixelfed settings page?
nope, never showed up. That why I was wondering when you asked for it.
Is the instance still correctly connected?
I guess, it still says:
You’ve authorized WordPress to read and write to your Pixelfed timeline. Access tokens are refreshed automatically, but a manual refresh is possible, too.
and as I said above, when I edit the post, it'll also go over to pixelfed, just in the initial/usual share process must be a bug.
maybe they're configured to not accept photos over a certain size?
hmmm my pictures are exported as 1920px but wouldn't explain why it goes afterwards through and/or when posted from the wp itself
I see. Might still be a race condition then with uploading images from mobile clients. I'm going to add some additional debug statements, and I would also like to test an alternative solution, where sharing to Pixelfed (or Mastodon) is delayed a few minutes after a post is published (to overcome any background image processing delays, should that be the reason for this issue).
Tried to reproduce using the WordPress (Android) app, with Jetpack's Site Accelerator enabled as well, and the other settings mostly the same, and with a must-use plugin in place with the following contents:
<?php
add_filter( 'share_on_pixelfed_enabled', '__return_true' );
And that works fine ... Even when I try to hit "Publish" before the image is done uploading. (The post will stay "draft," apparently, until all is well, and then gets published just fine, and appears on my Pixelfed account, too.)
Could you try debugging again, but this time with the following wp-content/plugins/share-on-pixelfed/includes/class-post-handler.php
? https://raw.githubusercontent.com/janboddez/share-on-pixelfed/debug/includes/class-post-handler.php
Just save that file and upload it to your server, overwriting the existing class-post-handler.php
file?
If that still doesn't tell us anything, we can try delaying the sharing action for a couple minutes after the post's first published. Not sure it'd work, but we could give it a try.
jips, done! Logfile and stuff is on the way to you
Alright, already replied. Looks like it really cannot find a featured image, so either it's not set, or it is set (when you go look in WordPress itself, I mean the WP admin web interface) but with a delay of sorts (due to uploading or processing).
Tbh, it kind of looks like it isn't set (at all), but if it really does work if you later on edit and save the post in WP's web interface, then that would indicate that it's merely a delay. It definitely is puzzling.
Anyhow, assuming the feature image is set correctly in the app, and then somehow takes somehow a while before it is "recognized" by WordPress but in the end ends up being correctly linked, could you test the following, still?
In wp-content/mu-plugins/sharing.php
(or however you've named it), can you copy-and-paste the following:
<?php
add_filter( 'share_on_mastodon_enabled', '__return_true' );
add_filter( 'share_on_pixelfed_enabled', '__return_true' );
add_action( 'plugins_loaded', function() {
if ( class_exists( 'Share_On_Mastodon\\Share_On_Mastodon' ) ) {
$m_plugin = \Share_On_Mastodon\Share_On_Mastodon::get_instance();
$m_post_handler = $m_plugin->get_post_handler();
// Remove default behavior.
remove_action( 'transition_post_status', array( $m_post_handler, 'toot' ), 999 );
add_action( 'toot_toot', function( $new_status, $old_status, $post_id ) use ( $m_post_handler ) {
// Should get called no less than 3 minutes after a post is saved.
$post = get_post( $post_id );
$m_post_handler->toot( $new_status, $old_status, $post );
}, 10, 3 );
}
if ( class_exists( 'Share_On_Pixelfed\\Share_On_Pixelfed' ) ) {
$p_plugin = \Share_On_Pixelfed\Share_On_Pixelfed::get_instance();
$p_post_handler = $p_plugin->get_post_handler();
// Remove default behavior.
remove_action( 'transition_post_status', array( $p_post_handler, 'toot' ), 999 );
add_action( 'toot_toot', function( $new_status, $old_status, $post_id ) use ( $p_post_handler ) {
// Should get called no less than 3 minutes after a post is saved.
$post = get_post( $post_id );
$p_post_handler->toot( $new_status, $old_status, $post );
}, 10, 3 );
}
// Add a different callback function, 3 minutes after a post is saved (updated, etc.).
add_action( 'transition_post_status', function( $new_status, $old_status, $post ) {
wp_schedule_single_event( time() + 180, 'toot_toot', array( $new_status, $old_status, $post->ID ) );
}, 10, 3 );
} );
This should delay posting to both Mastodon and Pixelfed with 3 minutes, approximately. Because of how WordPress works, it may be wise to quickly visit either your website or WP Admin after those 3 minutes (WordPress needs an "external" request in order to kick off scheduled background actions).
The 3 minutes is a random number, could be 30 seconds is already enough, I really don't know.
ok, you have to be strong I guess... After three minutes it showed up on mastodon, with picture! On pixelfed is nothing to see, I didn't edited this time, I think we know already what will happen.
Pretty mysterious!
For the Masto plugin, most of these image issues seem to have been resolved: https://github.com/janboddez/share-on-mastodon/issues/17
Need to deploy the same changes here.
Done.
Need to deploy the same changes here.
Ima run some more tests, then release to WP.org.
Hey there,
Im trying to use your plugins (both for mastodon and pixelfed) for a while now for my blog, thank you for it!
I have not really a clue why, but as I recently recognized just a few posts are going through to mastodon, the rest not. All the settings seem perfect. Usually I post one picture a day and from 20.02. this year on, just three posts are getting through. Im using the WP mobile client on my iPhone to blog and sometimes directly from my computer, I assume it shouldn’t matter, but I have the suspicion that this could be the reason.
Do you have any idea how to solve this riddle?
Best regards