Hi!
Please try the following:
- Export current settings at WPO > Settings > Export settings.
- Wipe current settings at WPO > Settings > Wipe settings.
- Purge all cache and minified files at WPO > Cache > Page cache and WPO > Minify > Minify status respectively.
- Deactivate the plugin, then reactivate.
- Import your settings at WPO > Settings > Import settings, and Save changes.
Try running the preloader and let us know how that goes.
Regards.
Hi,
thank you very much but the problem is still the same.
As I already mentioned the AJAX call is successfully sent when clicking the preload button with status 200 and success: true
But no preload is starting. The minimized css and js files are correctly written to wp-content/cache/wpo-minify. In folder wp-content/cache/wpo-cache only 2 files are written: a .htaccess and an empty index.php.
Can it be a problem parsing the sitemaps? But they worked until a few days ago:
https://www.mb-nosparts.com/sitemap_index.xml
Webserver runs with PHP 8.1.33. Is this ok?
Should there be a wp cronjob generated when clicking the preload button which cares for the preload? There is none, only the ones for scheduled preload and purge old files.
Best regards,
Thanks for the update.
To help with investigating this issue, please take the following steps:
1. Enable WPO logging at WPO > Settings > Logging settings > Add logging information. Select Log events into PHP error log and save your changes.
2. Set define(‘WP_DEBUG’, true);, define(‘WP_DEBUG_DISPLAY’, false); and define(‘WP_DEBUG_LOG’, true); in your sites wp-config.php file.
3. Run the preloader and after a few minutes, check the log at wp-content/debug.log.
Send us the last entries related to WPO.
Regards.
Hi,
I activated WordPress debug and WPO logging.
I find this in the debug.log:
[30-Jul-2025 14:56:18 UTC] [DEBUG] : running wpo_cron_deactivate()
[30-Jul-2025 14:58:55 UTC] [DEBUG] : running wpo_cron_deactivate()
[30-Jul-2025 15:00:56 UTC] [DEBUG] : running wpo_cron_deactivate()
What do you think is the problem?
Best regards,
Hi @kingofrocknroll
Do you see any other lines related to preloading? Did you click preload button?
Best regards
Yes I clicked the preload button. Nothing more is in the log file.
@kingofrocknroll That’s very strange. It seems like preloading isn’t even starting, perhaps it’s failing while collecting URLs from the sitemap. There should be at least a “N urls found.” message when preloading starts, but there’s nothing. Do you see any other errors in the debug.log?
Hello,
yes, really very strange. Nothing in error_log, and the only thing in debug.log is:
[30-Jul-2025 15:25:22 UTC] [DEBUG] : running wpo_cron_deactivate()
No “N urls found.” or anything else.
Can you tell me the php files relevant for manual preload? I will add some debug code there.
Thank you in advance!
Best regards,
Hi @kingofrocknroll
There is also a cache related log file in uploads/wpo/logs/cache-xxxx.log though it mainly logs when the caches are purged. May be you look into that file, to see if caches are purging for some reason.
You should also see wpo_page_cache_preload_continue cron event when preload is running.
WP_Optimize_Preloader which is extended by WP_Optimize_Page_Cache_Preloader are the classes responsible for Preloading .
@kingofrocknroll Try to add debug into run() method in the /includes/class-wp-optimize-preloader.php
Hello,
thank you both for your assistance.
In the meantime I realized that there was a WPML plugin update earlier which is writing hreflang info into the sitemaps for every page like this:
<xhtml:link rel=”alternate” hreflang=”en” href=”https://www.mb-nosparts.com/en/” />
<xhtml:link rel=”alternate” hreflang=”de” href=”https://www.mb-nosparts.com/” />
<xhtml:link rel=”alternate” hreflang=”x-default” href=”https://www.mb-nosparts.com/” />
The WPML plugin update was earlier but it seems it showed no effect immediately but later after regenation of the sitemaps.
Can this cause problems for WP-Optimze?
I think so, because after deactivating this option I move a step forward.
The debug.log now shows:
[01-Aug-2025 08:14:27 UTC] PHP Deprecated: strip_tags(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/vhosts/mb-nosparts.com/stage.mb-nosparts.com/wp-admin/admin-header.php on line 41
Best regards,
@kingofrocknroll Thank you for your research. I’ll check for possible compatibility issues with the WPML plugin and get back to you later.
Hi,
yes I think it’s good to check it!
But in my case it’s not relevant anymore because I deactivated the hreflang feature of WPML anyway because I prefer to have hreflang data in the head section of the pages.
I want to ask if this debug.log entry can be caused by WP-Optimze?
[01-Aug-2025 08:14:27 UTC] PHP Deprecated: strip_tags(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/vhosts/mb-nosparts.com/stage.mb-nosparts.com/wp-admin/admin-header.php on line 41
I don’t know, it also can be related to WordPress. But maybe you can check this. Thank you!
Best regards,
@kingofrocknroll Only way to find out is to find out backtrace.
You may want to try Query Monitor plugin and this constant in wp-config.php file
define( ‘QM_ENABLE_BACKTRACE’, true );
First of all I added an error_log output to the start of every function in /includes/class-wp-optimize-preloader.php. This is the output:
[04-Aug-2025 22:44:03 UTC] __construct
[04-Aug-2025 22:44:03 UTC] __construct
[04-Aug-2025 22:44:04 UTC] __construct
[04-Aug-2025 22:44:04 UTC] __construct
[04-Aug-2025 22:44:05 UTC] __construct
[04-Aug-2025 22:44:05 UTC] __construct
[04-Aug-2025 22:44:06 UTC] __construct
[04-Aug-2025 22:44:06 UTC] __construct
[04-Aug-2025 22:44:10 UTC] __construct
[04-Aug-2025 22:44:10 UTC] __construct
[04-Aug-2025 22:44:21 UTC] __construct
[04-Aug-2025 22:44:21 UTC] __construct
[04-Aug-2025 22:44:21 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:21 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:21 UTC] __construct
[04-Aug-2025 22:44:21 UTC] __construct
[04-Aug-2025 22:44:22 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:22 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:22 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:22 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:23 UTC] __construct
[04-Aug-2025 22:44:23 UTC] __construct
[04-Aug-2025 22:44:27 UTC] __construct
[04-Aug-2025 22:44:27 UTC] __construct
[04-Aug-2025 22:44:27 UTC] run
[04-Aug-2025 22:44:27 UTC] delete_cancel_flag
[04-Aug-2025 22:44:34 UTC] __construct
[04-Aug-2025 22:44:34 UTC] __construct
[04-Aug-2025 22:44:34 UTC] __construct
[04-Aug-2025 22:44:34 UTC] __construct
[04-Aug-2025 22:44:36 UTC] __construct
[04-Aug-2025 22:44:36 UTC] __construct
[04-Aug-2025 22:44:36 UTC] __construct
[04-Aug-2025 22:44:36 UTC] __construct
[04-Aug-2025 22:44:37 UTC] __construct
[04-Aug-2025 22:44:37 UTC] __construct
[04-Aug-2025 22:44:40 UTC] __construct
[04-Aug-2025 22:44:40 UTC] __construct
[04-Aug-2025 22:44:40 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:40 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:40 UTC] __construct
[04-Aug-2025 22:44:40 UTC] __construct
[04-Aug-2025 22:44:41 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:41 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:41 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:41 UTC] get_continue_preload_cron_interval
[04-Aug-2025 22:44:49 UTC] __construct
[04-Aug-2025 22:44:49 UTC] __construct
Somehow I think there isn’t any cronjob for manual preload. In WP Cron among others there’s a cronjob wpo_page_cache_schedule_preload for the scheduled preload but no cronjob which is generated when the manual preload is started. What is the name of the cronjob for the manual preload?
