Introduction
I have a customer running WP Ultimo Version 1, specifically the latest version of their 1.x.x branch which is 1.10.18 and they were getting 30-second page loads no matter the page. The server load was high, but it didn’t make sense that the page loads were so high. I did upgrade their instance just as a quick measure for troubleshooting, and no difference. So I started digging further into WordPress, something was delaying the loads.
Root Cause Analysis
Typically I set up php-fpm slow log, but this customer was running Openlitespeed, and unfortunately, LSAPI_SLOW_REQ_MSECS doesn’t work with Openlitespeed. So I turned to the trusty Query Monitor.
From there, I found that there I found the following issues API was timing out after 5000 secs.

The plugin in question was wp-ultimo, I blocked out the license key but the request looks to be verifying licensing information. The functions are as follows.
WU_Page_Feature_Plugins->get_remote_addons_count() wp-content/plugins/wp-ultimo/inc/class-wu-pages-feature-plugins.php:181 WU_Page_Feature_Plugins->get_new_addon_count() wp-content/plugins/wp-ultimo/inc/class-wu-pages-feature-plugins.php:74 WU_Page_Addons->get_remote_addons_count() wp-content/plugins/wp-ultimo/inc/class-wu-pages-addons.php:194 WU_Page_Addons->get_new_addon_count() wp-content/plugins/wp-ultimo/inc/class-wu-pages-addons.php:83
Upon further investigation, the link is no longer working. I ran a curl on the versions.nextpress.co and the sub-domain seems to be not responding at all.
But how do we fix this? You can go through the code and comment out anything that relates to get_remote_addons_count() or $this->get_remote_golden_ticket(); which is another function that was causing the same problem.
Resolutions
Option #1 – Update /etc/hosts file
If you’re running a VPS or bare metal instance, you can simply edit your /etc/hosts file if you have root and add the following.
# Fix ultimo issue 127.0.0.1 versions.nextpress.co
This will essentially point versions.nextpress.co to your local server which will return a response, versus not returning a response and timing out. This isn’t a good long term resolution, I’m looking at developing a mu-plugin to disable the remote check. But for now, this works.
Option #2 – Hook into pre_http_request
This wasn’t Option #2 original, it was actually Option #3 which unfortunately doesn’t account for all cases. So I replaced it with the code below. Simply put this into your mu-plugin folder and goodbye to 10+ second load times.
add_filter('pre_http_request', function($pre, $r, $url) { if (strpos($url, 'https://versions.nextpress.co/updates/') !== 0) { //error_log("Good API: $url"); return $pre; } else { // Target only WP Ultimo update/license server calls //error_log("Bad API: $url"); return [ 'headers' => [], 'body' => '', 'response' => ['code' => 201, 'message' => 'OK'], 'cookies' => [], 'filename' => null, ]; } }, 10, 3);
I have more code snippets at https://github.com/managingwp/wordpress-code-snippets
Option #3 – Hook into Transient Data Before it’s Retrieved (Half Works, Use Option 2)
Note: This doesn’t capture all instances, see Option 2
With WordPress, you can hook into any transient data before it’s retrieved and affect the value using the pre_site_transiet_ function.
/* wu_golden_ticket */ function wu_gold_ticket_return_true($value, $transient) { if ($transient === 'wu_golden_ticket') { return true; } return $value; // Return original value for other transients } add_filter('pre_site_transient_wu_golden_ticket', 'wu_gold_ticket_return_true', 10, 2); /* wu_saved_ff_count */ function wu_saved_ff_count_return_true($value, $transient) { if ($transient === 'wu_saved_ff_count') { return "10"; } return $value; // Return original value for other transients } add_filter('pre_site_transient_wu_saved_ff_count', 'wu_saved_ff_count_return_true', 10, 2);
So with the following code we can change the value of both wu_golden_ticket and wu_saved_ff_count to true and skip the process of reaching out to the now disabled domain versions.nextpress.co that takes 5 seconds to timeout.
Option #3 – Upgrade to Ultimo 2.x.x
Another solution is to upgrade to WP Ultimo 2.x.x where this most likely isn’t occuring.
Change Log
- 04-24-2025 – Updated Option 2 with a proper fix.