|
Hi,
Sorry for the delay in responding.
I've spent considerable time investigating your staging site and found several critical issues that were preventing it from working properly with the LiteSpeed Cache plugin active. I believe these same issues are affecting your production site as well.
The good news is that I've found a way to restore the staging site when it crashes — by clearing the OPcache using a script. Let me walk you through what I've discovered, what I've done so far, and the solutions that are showing positive results.
I looked at multiple layers of your stack to understand what's happening:
- WordPress database schema and query profiling
- Plugin activation sequences and how they depend on each other
- LiteSpeed LSPHP bytecode cache (OPcache) behavior
- Action Scheduler queue
- Database bloat in the wp_postmeta and wp_options tables
- WPML translation tables integrity
- Server-level caching and PHP-FPM process behavior
Issue #1: LiteSpeed LSPHP Bytecode Cache Corruption:
The LiteSpeed server's LSPHP module maintains a bytecode cache (OPcache) to store compiled PHP code for faster execution. When the LiteSpeed Cache plugin was activated, it triggered a class collision where PHP functions from WooCommerce or WPML were being loaded twice.
The problem is that the server's bytecode cache had stored corrupted compiled PHP code from previous crash states. Even after I modified or deleted plugin files, the server continued serving the corrupted cached bytecode.
This is a server-level caching issue, not a plugin code issue. The LiteSpeed FPM process was serving stale, corrupted bytecode that references PHP files in states that no longer exist on disk.
Solution: I created a script to clear the Opcache, but you can install a plugin called WP Opcache and flush the OPcache from there. After that, the staging site stayed up and running. This approach should work for preventing future crashes.
Issue #2: Action Scheduler Queue Saturation:
Your wp_actionscheduler_actions table contained 22,073 pending scheduled tasks that were never processed. On every page load, WordPress was trying to query and process this massive queue, causing memory exhaustion and 503 errors.
- Normal pending tasks: < 100
- What I found: 22,073 pending tasks
Solution: I canceled all stuck tasks using a direct database query:
-- Cancel all pending/in-progress/failed Action Scheduler tasks
UPDATE StR_actionscheduler_actions
SET status = 'canceled'
WHERE status IN ('pending', 'in-progress', 'failed');
-- Verify the fix
SELECT status, COUNT(*) as count
FROM StR_actionscheduler_actions
GROUP BY status;
Result: Pending tasks reduced to 0.
Issue #3: Orphaned LiteSpeed Postmeta Entries:
Your wp_postmeta table contained over 81,000 orphaned entries with meta_key values like 'litespeed%'. These were optimization flags left behind by the LiteSpeed Cache plugin that were no longer needed but were still being queried on every product page load.
Your total postmeta rows: 3,133,828 (abnormally high for 76K products)
Solution: I removed the orphaned LiteSpeed meta and optimized the table:
-- Delete LiteSpeed orphaned postmeta entries
DELETE FROM StR_postmeta WHERE meta_key LIKE 'litespeed%';
-- Delete orphaned meta (for deleted posts)
DELETE pm FROM StR_postmeta pm
LEFT JOIN StR_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;
-- Optimize the table
OPTIMIZE TABLE StR_postmeta;
Issue #4: Bloated WooCommerce Transients:
Your wp_options table contained a 454KB transient (_transient_wc_products_onsale) that was being loaded on every page request, significantly impacting memory usage.
Solution:
-- Delete bloated WooCommerce transients
DELETE FROM StR_options WHERE option_name = '_transient_wc_products_onsale';
DELETE FROM StR_options WHERE option_name LIKE '_transient_wc_%';
```
You can also remove transients from WooCommerce → Status → Tools.
Throughout my investigation, I specifically tested WPML, WPML String Translation, WooCommerce Multilingual, WooCommerce, and SEOPress in isolation without LiteSpeed Cache. All these plugins functioned correctly without any fatal errors or 503 responses.
The crashes only occurred when the LiteSpeed Cache plugin was active. While the issue is not caused by WPML itself but by how LiteSpeed operates, I continued the investigation since it had been troubling you for some time.
What we found is that the LiteSpeed server-level bytecode cache (OPcache) had retained corrupted compiled code from previous crash states. Because of this, the site kept crashing even after file-level fixes were applied. The problem was resolved only after forcefully invalidating the OPcache so that all PHP files were recompiled cleanly.
WPML is working correctly and is not contributing to this behavior. With LiteSpeed Cache disabled, the site has been stable for over 30 minutes with all plugins active. I also sent more than 70 items for translation, and they were completed successfully without any fatal errors or server issues.
Additionally, even the WooCommerce transient clearing tool was triggering Fatal Error and 503 responses when LiteSpeed Cache was enabled, which did not happen once the plugin was disabled.
Please refer to the attached screenshots for confirmation.
However, I also found a malicious plugin file on your staging site. The file is significantly large and contains code that doesn't appear legitimate. It's located in the /wp-content directory and named plugin.php. If you're not aware of this file, please delete it immediately for security reasons as it could be a leftover by Hacker.
So, in summary, the 503 errors and fatal crashes were caused by:
1. LiteSpeed Cache plugin triggering PHP function redeclaration errors
2. LiteSpeed LSPHP bytecode cache serving corrupted compiled PHP code from previous crash states
3. Database bloat from 22,073 stuck scheduled tasks and 81,000+ orphaned cache entries
WPML is not the root cause. The issue is specifically with the LiteSpeed Cache plugin's integration behavior and the server's aggressive bytecode caching.
If you'd like to apply these fixes to your production environment, please make sure to take a full backup of both your site files and database before making any updates. I can guide you through the process step by step once you're ready.
I hope this clarifies everything. If you have any questions or need me to explain anything further, please don't hesitate to ask. I'm here to help!
Best regards,
Prosenjit
|
