Why no Twitter (X)?

Hi @jamminjames , Great question! Unfortunately, X (previously Twitter) is no longer available as a connection option in Jetpack Social. Back in 2023, X dramatically changed the terms and pricing of their API, and despite our attempts to negotiate, we weren’t able to reach an agreement. As a result, we had to discontinue the X integration. You can read more about what happened here: https://jetpack.com/resources/the-end-of-twitter-auto-sharing/ We know it’s frustrating, X would indeed be a no-brainer to include. In the meantime, Jetpack Social still supports auto-sharing to Facebook, LinkedIn, Tumblr, Instagram, Mastodon, and Bluesky. For X, the workaround for now is to manually share your posts by pasting the link into a tweet. Hope that helps clarify things!

Ok, thanks. It’s not accepting my Mastodon handle. My profile is at https://mastodon.social/@humortimes , so the handle should be “@humortimes”, correct?

Also, when I try to share a previously published post (classic editor), I get: “An error occurred while sharing your post.” I can’t find anything in our server logs that might indicate the reason for the error. Tried deactivating all plugins except Jetpack & Jetpack Social and Classic Editor, no change. Also removed our child theme functions.php file and a couple mu-plugins we have, no change. How can we troubleshoot this? Thanks!

Hi @jamminjames , Since you’re having more than one issue, I suspect there might be an issue with your Jetpack connection, and we’d love to take a closer look at it. Could you please post your site URL here so that we can take a look? If you want it to remain private, you can also contact us via this contact form . If you choose to reach out directly, please include a link to this thread. Thanks!

humortimes.com , thanks! Yes, it’s definitely the connection. We are using an mu-plugin for REST API hardening, but have provisions in it for Jetpack. The problem persists whether or not the mu-plugin is present. The script is here .

We also use Cloudflare CDN, but I’ve checked the rules that we have set up, and don’t think that’s the problem.

Hello there, Sebastian here. I hope you are doing well. Thank you for sharing additional details of these issue with us-. I reviewed your site and saw an issue where the Jetpack Connection fails because your server is sending a 503 error code . Jetpack needs this connection to function correctly for most of its features. A web server sends a 503 error code when you exceed its resource limits. This may mean that you need to upgrade your server. In any case, you should contact your hosting provider about this. They can investigate why this is happening on your server and offer suggestions for fixing it. You can find more details about Jetpack and how to fix Jetpack connection issues here: https://jetpack.com/support/getting-started-with-jetpack/fixing-jetpack-connection-issues/ I recommend checking into this as soon as you can because your site’s visitors may occasionally have trouble accessing it. Regarding the script you share, helping with these level of customizatrion fall outside of our scope of support Let us know when you have resolved this, and we can test the Jetpack connection again.

Thanks, was able to find the problem in our Nginx settings. Now, I’m trying to re‑share posts. I can do it in the Classic Editor, but not with the Block Editor. In the documentation, it says: “Bring up the Jetpack menu by clicking the Jetpack in the top right corner.” However, there is no Jetpack link nor icon there. We have Yoast, so I see that icon, but not for Jetpack. Scrolling down the ‘Post’ column, I see nothing for Jetpack. One more question: Shares show title with link, plus image. This is great. How can we add author and/or anything else, like our company name? This reply was modified 5 months ago by jamminjames .

Also, does Jetpack automatically install a Woocommerce mu-plugin? Since installing Jetpack, it keeps reappearing.

I’ve got it set up and not seeing errors, log shows some posts sent, however, checking my socials, they were not in fact posted.

After trying for hours to diagnose this issue with the help of Copilot, it suggested posting a support request with Jetpack , telling them: “My Jetpack connection is stuck in a ghost state. Locally, Jetpack is fully disconnected and reconnected cleanly, but test__wpcom_connection_test fails and WordPress.com still shows the site as connected… Please purge the Jetpack connection for site ID xxxxxx” I did that, guess we’ll see what happens.

Hi @jamminjames , Thanks for all the detailed testing and for your patience so far. At this point, we can narrow everything down to one core issue. Right now, the Jetpack connection can’t fully establish because access to xmlrpc.php on your site is being blocked or modified . Until that’s resolved, Jetpack won’t be able to complete its connection handshake, and features that depend on the connection, like Social sharing and the Jetpack panel in the Block Editor, won’t work reliably. A simple way to verify this, without any command-line tools, is to check the XML-RPC endpoint directly in your browser: https://www.humortimes.com/xmlrpc.php?for=jetpack When XML-RPC is working correctly, that URL should return a plain XML response. If it shows a blank page or regular HTML output, it means something upstream is still interfering with access to xmlrpc.php . From what we’re seeing so far, something at the server or CDN level is blocking or altering that endpoint . Since you mentioned Cloudflare earlier, this is a common place where XML-RPC can be affected by security rules or optimizations. This guide may be helpful as you investigate further on that side: https://jetpack.com/support/getting-started-with-jetpack/configure-jetpack-cloudflare/ Jetpack relies on xmlrpc.php to communicate with your site, and certain Cloudflare settings, such as WAF rules, bot protection, or response transformations, can interfere with that communication. Jetpack support can’t adjust Cloudflare configuration directly, but once XML-RPC responds correctly, the Jetpack connection should be able to complete normally. For now, the best next step is to focus on getting that XML-RPC endpoint responding correctly. After that, we can recheck the Jetpack connection and then look again at Mastodon or any remaining Social issues if they still persist. Let us know once that endpoint is accessible and we’ll be happy to continue from there.

Silly me, our Really Simple Security plugin had ‘disable xml-php’ set to on. Now working, including Mastodon and Jetpack icon in Block editor. Still curious, does Jetpack install the mu-plugin, woocommerce-analytics-proxy-speed-module.php? It keeps installing itself since we started using Jetpack. Also: Our shares show title with link, plus image. This is great. How can we add author and/or anything else, like our company name? This reply was modified 5 months ago by jamminjames .

A couple other questions, the shares show the first part of the article, instead of the excerpt (set with Yoast). Can that be changed? Also, I’ve seen conflicting info on this: Is it possible to install Jetpack Social as a stand alone plugin, without the main Jetpack plugin?

I thought everything was working now, but I guess not. Re-share seems to work, however, the newly published posts are not making it to the social platforms. After publishing a notice says: “Post published and sharing on LinkedIn (Humor Times), Mastodon (@humortimes@mastodon.social), Instagram (Humor Times), Threads (humor_times_pub).” However, they are not there.

Tried it by updating the post (after checking the social shares), and that worked, after several tries. Maybe it’ll work on Publish now as well, I’ll let you know. The image doesn’t appear in Mastodon, but is showing in the others.

Hello there, @jamminjames , I’m going to answer your questions one by one as follows 🙂 does Jetpack install the mu-plugin, woocommerce-analytics-proxy-speed-module.php? It keeps installing itself since we started using Jetpack. Jetpack itself does not install that Woo MU plugin. That file is added by WooCommerce and is related to WooCommerce Analytics performance. It can look confusing because it lives in the mu-plugins folder, but it isn’t coming from Jetpack or Jetpack Social. **** How can we add author and/or anything else, like our company name? Are they looking to add this information automatically to every post, or just occasionally? There is no direct or default way to add this info, however there are some few workarounds you can try: When publishing or scheduling a post, you can edit the share message in the Jetpack Social panel, and add this info in there Add text overlays to your share images with that info **** The shares show the first part of the article, instead of the excerpt (set with Yoast). Can that be changed? That sounds more like an Open Graph conflict to me. Both Jetpack and Yoast can generate Open Graph meta tags (which control how content appears when shared on social media). If both are active, they may conflict, and the social platforms might pull the wrong description. What you may want to try to start is to check that the Social → Facebook/Twitter description fields in Yoast are filled in for the post, not just the standard excerpt. That might fix that, keeping in mind that social platforms ultimately choose what they display. Alternatively, you can try using the Always Use Open Graph with Jetpack to see if that addresses the problem. **** Is it possible to install Jetpack Social as a stand alone plugin, without the main Jetpack plugin? Yes! Jetpack Social is available as a standalone plugin, and you can keep it installed and activated without having the Jetpack core connected too. Just keep in mind that all the Jetpack core free features won’t work if you disconnect the core Jetpack plugin 🙂 **** I thought everything was working now, but I guess not. Re-share seems to work, however, the newly published posts are not making it to the social platforms. I checked at our end, and I can see some errors affecting the sharings, which match with your report. Despite the Jetpack connection now looks okay, the sharing jobs report a HTTP Error - http_request_failed - cURL error 28: Operation timed out after 5001 milliseconds with 0 bytes received error. Such errors typically indicates a timeout: your server tried to reach Jetpack’s sharing endpoint but didn’t get a response in time. This is almost always a server/hosting connectivity issue, not a problem with your post or Social settings. The best way to address it is to ask your host to confirm that outbound HTTPS (port 443) connections are allowed to Jetpack / WordPress.com services, and to check (again, if done already) whether any security plugins or server-level firewall...

Thanks, we are making adjustments to our server settings. When I tried to deactivate Jetpack, to keep only Jetpack Social, it says: Once you deactivate Jetpack, these features will no longer be available. Jetpack Social – Live social media site connections, powered by Jetpack: 5

Hi there, @jamminjames , From what you reported, the Jetpack core plugin is warning you about losing all the plugin’s capabilities and features if you deactivate it. Keeping Jetpack Social activated and connected as a stand-alone plugin, will allow you to use only the Social features – anything else included in the Jetpack core plugin won’t work at all. Hope that’s all clear! Let us know if that doesn’t look like it, and how the connection goes and what your hosts says about. It seems to be working at the moment on https://www.humortimes.com/ 🤞

But the warning is about Jetpack Social settings, indicating our connections to our social media platforms won’t work: Jetpack Social – Live social media site connections, powered by Jetpack: 5 Is that a false message? Also, we corrected the cause of the error: HTTP Error - http_request_failed - cURL error 28: Operation timed out after 5001 milliseconds with 0 bytes received … and still, only re-share is working, the posts do not happen when a scheduled post is published. Where do you see the sharing jobs report that showed the above error? I’d like to check that, now that we made changes that should fix the timeout error. Lastly, when re-sharing, images appear in all but Mastodon. Is there something that can be done to fix that? This reply was modified 4 months, 4 weeks ago by jamminjames .

I saw an error somewhere, something like: You’ve reached your Jetpack Social monthly post limit. Yet our re-shares still work. Is this only a problem with scheduled posts or when publishing a post manually? What is the limit for a free account?

Please help. Jetpack Social still only shares when we use re-share. It does not share scheduled posts.

Okay, the problem seems to be caused by conflicts with either the Yoast or Redis plugin or both, and/or modifying posts after they’ve been scheduled, which apparently may mess with Jetpack Social’s logic. With the help of Copilot AI, we added an mu-plugin to re-save post with save_post action hook: If modified time is AFTER publish time, fix it via wp_update_post hook. Check if cron event already exists via _get_cron_array hook and if in future, but not scheduled via publish_future_post hook, fix it. If not scheduled, force schedule it via wp_schedule_single_event hook. This has apparently solved the problem, at least in our initial tests. It seems like we should not need an mu-plugin to fix these problems, perhaps Jetpack can look into it.

Correction on my last post, we’re using the transition_post_status hook, not the save_post action hook. I will try to report back after this mu-plugin has had more time to work, to let you know how successful it is. This reply was modified 4 months, 3 weeks ago by jamminjames .

Hi @jamminjames , Thanks for sharing your findings, that’s really interesting and helpful. From what we can see, Jetpack Social works as expected on its own, but in some setups, interactions with other plugins or caching layers can affect how scheduled posts trigger sharing. If you’re able to confirm that one of those plugins (or the combination) consistently affects Jetpack Social’s behavior, please let us know. That kind of confirmation would be very useful for us to investigate further on our side. For now, it looks like your workaround is a reasonable temporary solution, and we appreciate you taking the time to dig into this.

Well, sorry to report back that it’s not working after all. Going back to square one, I removed the mu-plugin and tried a few test posts. It seem that scheduling a post as the logged in user works, but, as admin or editor, if I schedule a post that someone else owns, it does not work. Is this something intentional with Jetpack Social? We have many authors, but restrict that role from being able to publish, as we want to review before publishing. So we need to be able to schedule posts by other authors as admin. We tried this new mu-plugin filter to try and bypass the behavior, but it doesn’t work: add_filter('jetpack_social_pre_publish_post', function( $should_share, $post ) { if ( $post instanceof WP_Post ) { // You can tighten this if you only want to affect certain post types/statuses. // For now, if it's transitioning to publish, we force sharing. if ( $post->post_status === 'publish' ) { return true; } } return $should_share; }, 10, 2); This reply was modified 4 months, 2 weeks ago by jamminjames . Reason: example filter This reply was modified 4 months, 2 weeks ago by jamminjames .

Okay, solved it. Just needed to check the “Mark the connection as shared” box in Jetpack Social Connected accounts. This is apparently needed if scheduling an Author post as Admin. I did have to be logged into https://cloud.jetpack.com/ in order for the setting to take. There, the checkbox is called “Connection available to all administrators, editors, and authors.” Does this mean we have to be logged in there at the moment we publish a scheduled post? I think it will log us out automatically at some point, correct? We spent days trying to figure this out. It ought to be emphasized somewhere in the plugin interface. This reply was modified 4 months, 2 weeks ago by jamminjames .

Hi @jamminjames , Thank you for circling back with the solution, and for sticking with this through a very long and frustrating investigation. You’re absolutely right, this behavior is not obvious enough today. To answer your key question directly: No, you do not need to stay logged into cloud.jetpack.com when scheduled posts are published. Once that setting is saved, the connection permission is stored on our side. Logging into cloud.jetpack.com is only required at the moment you change the setting, not when posts are later published or scheduled. What’s happening under the hood is this: Each social connection has a permission flag that controls whether it can be used by all admins, editors, and authors, or only by the user who originally connected it. If that box is unchecked, Jetpack Social will not share posts scheduled or published by another user, even if they have the correct WordPress role. Re-shares can still work, which makes this especially confusing and hard to diagnose, as you experienced. Your feedback that this should be emphasized much more clearly in the plugin UI is completely valid. The amount of time you had to spend to uncover this is not reasonable, and I’m going to pass this along internally as strong UX feedback for Jetpack Social. Thanks again for documenting everything so thoroughly, this thread will genuinely help other users and our team as well. If anything else comes up, feel free to reply here. Since the issue is resolved, I’ll go ahead and mark this thread as resolved, but if anything else comes up down the road, feel free to reach out anytime. Best regards, Alin