I’m experiencing an issue with transients in my WooCommerce store. I noticed that certain transients, such as _transient_wc_ptk_patterns, keep regenerating even after I set their autoload value to “no” in phpMyAdmin.

Here’s what I’ve tried so far:

• Manually setting autoload to “no” in wp_options.
• Clearing transients via WooCommerce > Status > Tools.
• Running the SQL query: sqlCopierModifierDELETE FROM wp_options WHERE option_name LIKE '_transient_%'; But the transients keep coming back.

I’m concerned that this might be affecting performance since my site health is indicating a critical autoload error telling me that I have 1041 autoloaded options (size: 911 KB). Is there a way to prevent WooCommerce from recreating these transients or manage them properly?

Any insights would be greatly appreciated.

Thanks!

I have tried reconnecting, reinstalling worker, disconnecting the key and tried to reconnect

I have tried to connect with login credentials and the connection key.

I have tried incong mode, on mobile app

Ive tried stripping all but essential plugins

It will not connect. What can i do?

• Publishing or editing posts
• Editing with Elementor
• Liking posts
• Other admin-related actions

This issue started immediately after running the following code:

session_destroy();
clear_wordpress_cache();
wp_cache_flush();
$wpdb->query("DELETE FROM $wpdb->options WHERE option_name LIKE ('_transient_%')");
$wpdb->query("DELETE FROM $wpdb->options WHERE option_name LIKE ('_site_transient_%')");
flush_rewrite_rules();
clear_wordpress_cache();

Some actions return the following error response:

{
  "code": "rest_cookie_invalid_nonce",
  "message": "Cookie check failed",
  "data": { "status": 403 }
}

What I’ve Tried So Far:

Checked Browser & Cleared Cookies
Disabled Security Plugins (Wordfence, iThemes Security, etc.)
Regenerated .htaccess by visiting Settings → Permalinks → Save Changes
Verified File Permissions (755 for folders, 644 for files)
Checked if Cloudflare, ModSecurity, or Firewall is blocking requestsPossible Causes?

• Deleting _transient_% and _site_transient_% entries from wp_options may have removed security-related tokens used by WordPress and plugins.
• session_destroy(); might have cleared active session data, causing authentication failures.
• REST API nonces became invalid, leading to rest_cookie_invalid_nonce errors.

Questions:

1. How can I restore the correct transient data if it’s causing these issues?
2. Could this be related to missing security tokens or authentication issues?
3. Any recommended steps to debug the persistent 403 error?

Any insights or solutions would be greatly appreciated!
Thanks in advance for your help.

This version clearly outlines the problem, lists debugging attempts, and asks specific questions, making it more effective for getting help. Would you like me to adjust anything further?

{code: “rest_cookie_invalid_nonce”, message: “Cookie check failed”, data: {status: 403}}
code
:
“rest_cookie_invalid_nonce”

this is a multisite, we have couple of cache pluggin installed but active in respective projects only. i have nitropack ut deactivated it. Kindly help me with the solution.

I have an issue with my WordPress back office, which has become very slow. The back office takes 13 seconds to load, and this is due to HTTP API calls (I was able to verify this with Query Monitor).

On each back-office page load, there are many API requests, some coming from WordPress Core and others from plugins like WooCommerce, WPML, WP Rocket, etc. Each request takes on average between 0.3 to 0.8 seconds to load. These are mainly update checks, notifications, and so on.

Here is a screenshot of all the requests (link) :

What I don’t understand is why each back-office page triggers all these requests. I have checked other WordPress sites I manage (including WooCommerce sites), and there are not nearly as many HTTP calls. Typically, there is only one HTTP request or none at all.

I have tried many solutions to prevent these requests from being generated, but none have worked. I have switched to the default theme, deactivated plugins, and tried different caching solutions. I even reset the site with WP Reset, but these calls continue to be triggered. When I add this line to the wp-config.php file:

define('WP_HTTP_BLOCK_EXTERNAL', true); 

the loading time drops to a maximum of 3 seconds. However, this is not a good solution because updates and HTTP calls related to WooCommerce (such as for payment gateways) are blocked. The HTTP Requests Manager plugin also allows me to limit these requests, but it doesn’t solve the root issue.

I have tried other solutions, but nothing works. Does anyone have an idea or a potential solution for the origin of these HTTP calls on each back-office page load? Thank you.

The Transients Manager did the trick, after I made a backup of the database, of course. The table went from 1.3 gb (and the host had disabled the table!) to 43.2 mb after running the Transients Manager.

I’ve used The Events Calendar on several of my clients for years and, while the knowledgebase is very helpful, having personal support and follow-ups saved my client (a municipality) from not being able to post notices for their community.

My subscriber count has been stuck at 4 despite (a) my adding several subscribers from another domain name I have and (b) my wordpress.com subscriber count being at 11 currently. I’ve been going through support for relevant solutions (https://jptools.wordpress.com/debug/ says the site looks great; I deleted any and all relevant jetpack transients (https://jetpack.com/support/extra-sidebar-widgets/blog-stats-widget/#troubleshooting); I have disconnected and reconnected Jetpack (https://jetpack.com/support/reconnecting-reinstalling-jetpack/); I’ve deleted and re-installed Jetpack; my hosting company Hostek has little-to-nothing when searching about cache clearing, etc.) but nothing has made a dent in the subscriber count on the site. Was hoping anyone had any additional sets of possible solutions (or direction to such a page if it exists). Early thanks for any insights!

WordPress 6.4.2, Jetpack 12.9.3, php 7.4