Bruce (a11n)

Hi @abhishekgarg97

Thanks for sharing those PHP notices – I can see they’re showing up pretty frequently in your logs, which is definitely annoying.

What I’m understanding: You’re getting these translation loading notices every few minutes related to Jetpack Protect, and you’d like to get them cleared up.

What’s going on: Jetpack Protect is trying to load its translations a bit too early in WordPress’s loading process. WordPress got stricter about this timing starting with version 6.7, which is why these notices are now showing up in your logs.

The good news is your site is working fine – these are just notices telling us about timing, not actual errors breaking anything.

Let’s try a few things:

1. Plugin conflict test – You’ve got quite a few plugins running (including some security ones like All-in-One WP Security). Try temporarily turning off your other plugins to see if the notices disappear. If they do, we can narrow down which one might be causing the timing issue.
2. Clear your WP Rocket cache – Just to make sure we’re seeing current behavior.
3. Quick theme test – Switch to a default WordPress theme temporarily to rule out any theme-related timing issues.

If those steps don’t help, this might be something our developers need to take a look at. Your specific setup (PHP 8.4.11 with WordPress 6.8.2) could be part of what’s triggering this.

The notices won’t hurt your site’s security or performance, so no rush – but definitely reach out to our support team if you need more hands-on help getting this sorted.

Hope that helps get you pointed in the right direction!

Hi @tajabakhar

Thanks for reaching out! We can see that Facebook sharing is working fine, but Instagram is rejecting the posts. The error on our side is:

“The image container could not be created. Error 400 (Only photo or video can be accepted as media type.) — Media download has failed. The media URI doesn’t meet the requirements.”

This usually happens when Instagram can’t fetch the featured image in a format it accepts. Common triggers are:

• The image isn’t a standard JPG/PNG, or is being served in another format (like WebP/AVIF).
• The filename contains non-ASCII characters (letters outside A–Z or numbers), which Instagram’s API can’t process.
• The image can’t be fetched directly from the public URL (because of redirects, CDN issues, or access restrictions).

How to fix it:

1. Re-upload the image as a JPG with a simple filename (letters, numbers, and dashes only, e.g. post-image.jpg).
2. Set that image as the featured image and try sharing again.
3. If you use a CDN or image optimization plugin, make sure the URL being shared points to the direct .jpg.

Instagram’s requirements are listed in Meta’s docs here:

https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-user/media

Hi @chumidor

Thanks for reaching out — I know how frustrating those downtime alerts can be, especially when your site eventually loads.

Jetpack Monitor flags downtime when your site doesn’t respond quickly enough — and with over 100 active plugins, even small slowdowns can trigger alerts.

Here are a few things you can try to reduce the load:

• Try enabling Jetpack’s Site Accelerator to offload images and static files to our CDN. This can significantly speed things up.
• Temporarily deactivate any non-essential plugins to test performance.
• Ask your host to check for resource spikes around the alert times — they may spot a bottleneck.
• Health Check plugin (in Troubleshooting Mode) can help test performance plugin-by-plugin without impacting site visitors.
  
  Your XML-RPC endpoint is functioning normally — that message is expected when visiting it in a browser.

Hi @teddyhappy

Thanks for reaching out! We’ve merged the stats and subscribers back onto your main site.

Please let us know if you need anything else.  

Hi @marjoriesdaughter

Thanks for the detailed follow-up. From what you’ve described, the first step I recommend is to reconnect Jetpack so that any stuck or excessive sync records can be cleared properly:

1. In your site’s WP Admin, go to Jetpack → My Jetpack.
2. Scroll to Manage Connection and click Disconnect Site from WordPress.com.
3. Once disconnected, reconnect using your administrator account linked to WordPress.com.

This will refresh the sync process and ensure Jetpack only tracks relevant events going forward.

Regarding your question — the sync table stores data Jetpack uses to keep your site and WordPress.com in sync for features like stats, backups, and security. While it’s possible to remove records directly from the database, doing so without a proper sync reset can cause inconsistencies or leave behind orphaned data in other Jetpack-related tables. That’s why a reconnect is the safest first step.

Here’s more about Jetpack Sync and its role:

https://jetpack.com/support/what-data-does-jetpack-sync/

Let me know once you’ve reconnected so we can proceed.

Hi @pronetsweb

We’ve updated the URLs on the Jetpack side. Can you try to reconnect to WordPress.com now?

Jetpack connects ww.wp.xz.cn sites to be able to use WordPress.com features, which is why the WordPress.com account is needed.

Hi @cardozoadvocacia

We have a general guide for Cloudflare here:

https://jetpack.com/support/getting-started-with-jetpack/configure-jetpack-cloudflare/