Alin (a11n)

Hi @nhowarth,

Just to correct one detail from my earlier reply, the debugger link I shared should have used the full site URL with www:

https://jptools.wordpress.com/debug/?url=https://www.news.cyprus-property-buyers.com

I also took another look here, and I do not think this is only a LinkedIn-side issue.

The bigger concern is that the Jetpack connection itself does not look fully healthy at the moment. In particular, the XML-RPC endpoints appear to return the site homepage instead of the normal XML-RPC response, which usually points to some kind of redirect, cache, firewall, or request-handling rule affecting those requests.

Since Jetpack Social depends on the Jetpack connection to publish successfully, that could explain why the problem feels intermittent.

Because you mentioned Cloudflare, and I can also see performance / caching plugins active on the site, I would suggest checking whether anything in Cloudflare, server-level security, WP Rocket, or any custom code/snippet setup could be affecting these endpoints:

• xmlrpc.php
• xmlrpc.php?for=jetpack
• Jetpack / WordPress.com requests to the site

Also, allowing LinkedInBot is useful for LinkedIn previews, but it would not by itself fix Jetpack Social publishing, since that depends on the Jetpack connection being able to communicate properly with the site.

So I would not treat this as fully resolved yet. It looks more likely that the LinkedIn failure was a symptom of an unstable Jetpack connection rather than a problem with that second LinkedIn account specifically.

Regards,
Alin

Hi @nebbens,

Thanks for the detailed report, and for sharing the workaround you tested, that’s really helpful.

I see what you mean about the column name causing issues when it overlaps with a reserved SQL keyword like order. That can definitely lead to query errors in cases like this.

Since this involves a change in how queries are built in Jetpack core, the best next step would be to open an issue on our GitHub repo so it can be reviewed by the development team:

https://github.com/Automattic/jetpack/issues

If you include the method you mentioned, Jetpack_Sitemap_Librarian::get_sanitized_post_columns(), along with your example and the adjustment you made, that should give them enough context to evaluate whether this can be safely improved.

In the meantime, your workaround sounds like a reasonable temporary solution for your setup.

Thanks again for taking the time to report this.

Hi @comunicacionabierta,

Great question, I can see how useful this would be if you’re publishing content through custom post types.

At the moment, Jetpack email notifications are only sent when a standard Post is published. Custom Post Types, pages, or updates won’t trigger a notification email to subscribers, and there isn’t a built-in way to enable this right now.

As a possible workaround, if your goal is to automatically share that content when it’s published, Jetpack Social does support Custom Post Types. With a small adjustment, you can have those posts auto-shared to your social media channels when they go live. You can read more about that here:

https://jetpack.com/support/jetpack-social/auto-share-custom-posts-types-with-jetpack-social/

Hope this helps, but if there are any questions, let us know.

Hi @archon810,

Thanks for the detailed report, I can see why those spikes would be concerning, especially with the impact on your database.

The /wp-json/jetpack/v4/sync/spawn-sync requests are part of Jetpack’s background sync process. On very high-traffic sites, we’ve seen cases where these can spike, especially around scheduled sync runs, which would explain the consistent timing.

If you want it to remain private, you can also contact us via contact form. If you choose to reach out directly, please include a link to this thread.

Best regards,
Alin

Hi @nathanae,

Could you please post your site URL here so that we can have a look? If you want it to remain private, you can also contact us via contact form. If you choose to reach out directly, please include a link to this thread.

Thank you!

Hey @moniquenamie,

Glad that helped clear things up 🙂

Yep, feel free to open a new thread for the other question and we’ll take a look there.

Hi @olikanagold77,

Thanks a lot for sticking with us on this, I can see you’ve already tried quite a few things over the past weeks.

From everything you’ve shared, there’s one really important detail: the Instagram block works on your sub-sites (es / en), but not on the main site (olikana.com). That tells us this isn’t an Instagram or global Jetpack issue, but something specific to the main site setup.

At this point, the most likely cause is something on the main site interfering with the connection (usually a plugin or how requests are handled there).

To move this forward without repeating the same steps, I’d suggest one focused test:

• On olikana.com only, temporarily deactivate all plugins (just for a minute)
• Then try adding the Instagram block again

If it works, we’ll know for sure it’s a plugin conflict and can narrow it down quickly.

If it still doesn’t work, we’ll take a different route and dig deeper from our side.

I know this has been frustrating, especially since it worked fine for years, so I really appreciate your patience here.

Let me know what you see after this test and we’ll take it from there.