Ultra Web Hosting Performance Toolkit

No. The cache-purge button calls each caching plugin's own flush routine, so it works alongside LiteSpeed Cache, WP Rocket, W3 Total Cache, and the others rather than replacing them.

No. If a dedicated security plugin (Wordfence, Solid Security, Sucuri, All-In-One WP Security, WP Cerber, Limit Login Attempts, LoginPress, Jetpack Protect, or Imunify Security) is active, The plugin defers login protection to it and shows a notice saying so.

Only if you tell it so. Under Visitor IP detection choose Cloudflare, and the forwarding header will be honoured for requests that genuinely arrive from a published Cloudflare range. The setting exists because that header can be forged by anyone when no proxy is present, which would let an attacker sidestep a lockout or lock out somebody else.

Open https://dash.cloudflare.com/profile/api-tokens while signed in to Cloudflare. Select Create Token, scroll to the bottom, and choose Create Custom Token. Give it a name you will recognise later. Under Permissions choose Zone, then Cache Purge, then Purge. That one permission is all this needs. Under Zone Resources choose Include, then Specific zone, then pick your domain from the list. That list shows domain names rather than IDs; the Zone ID is collected separately in step 7. Continue to summary, then Create Token, and copy the value straight away. Cloudflare only displays it once, but a lost token does not have to be recreated: open it later and choose Roll, which issues a fresh value while keeping the same name, permissions and zone. Back in the Cloudflare dashboard, select your domain and stay on the Overview page. In the right-hand column under the API heading is the Zone ID, a 32 character string, with a copy button. Both values are needed. A token limited to Cache Purge has no permission to list your zones, so the plugin cannot work out which zone your site belongs to on its own.

From another admin account, open Settings > Ultra Performance and click Unlock next to your IP in the lockout log. Otherwise the lockout clears on its own after fifteen minutes, or longer if that address has been locked out several times in a row. You can also clear it with WP-CLI by deleting the ultraperf_lock_*, ultraperf_att_*, and ultraperf_strk_* transients for your IP. I turned off email resets for admins, and now I have forgotten my password. This is the situation the escape hatch is for. Either reset it with WP-CLI: wp user update your-login --user_pass="a-new-strong-password" or, if you cannot reach WP-CLI, add this line to wp-config.php, request the reset in the normal way, then remove the line again: define( 'UWPT_ALLOW_ADMIN_RESET', true ); While that constant is defined the settings page shows the admin-reset toggle as overridden, so it is obvious it is in place and needs removing once you are back in.

Yes, and you do not need an account with anyone. Under Settings > Ultra Performance > Security, in the Password reset CAPTCHA section, pick a challenge. All are off by default and sit on top of the invisible honeypot, token and rate-limit checks rather than replacing them: Invisible proof-of-work (recommended). The visitor's browser silently solves a small puzzle before the form will submit. No account, no external service, and nothing for a real visitor to do. It also proves a real browser ran the page, which a script posting straight to the form cannot. It needs JavaScript, so choose the question below if you must support visitors without it. Arithmetic question. A plain "what is 3 + 4?" on the form. No account, no external service, works without JavaScript, and fully accessible. Simpler and weaker than the proof-of-work, but a good fit where JavaScript cannot be relied on. Cloudflare Turnstile. A managed challenge for sites that would rather use one. This is the only option that needs an account: create a free Turnstile widget in the Cloudflare dashboard, then paste its site key and secret key into the same section. It is verified with Cloudflare on submit, and if Cloudflare is ever unreachable the request falls back to the checks above instead of being blocked. To use reCAPTCHA, hCaptcha or another provider instead, the ultra_reset_allow filter is the hook: return false from it to reject a request.

No. WooCommerce serves its own lost-password form, which does not carry this plugin's token, so the token and honeypot checks are skipped for it. The per-IP and per-account rate limits still apply, which is the part that matters, and a genuine customer resetting a password never comes close to them.

It can. XML-RPC is required by the legacy WordPress mobile app and some Jetpack features. If you rely on those, turn off the Disable XML-RPC toggle. A comment from a real visitor was held for moderation. That is the link limiter working as designed: comments with more than two links are queued rather than rejected, so a genuine comment is never lost. Approve it from the Comments screen, or raise the limit with the ultra_spam_max_links filter. My CSS or JavaScript looks out of date after an update. If you turned on Remove Query Strings, some caching layers may be serving old files because the version string they used for cache-busting is gone. Clear all caches, and if it persists turn that toggle back off. This is why it ships off by default.

Yes. Deleting the plugin removes its settings, lockout log, and all of its transients, across every site on a multisite network. Deactivating leaves them in place so you can reactivate without reconfiguring.

The plugin writes nothing outside WordPress and makes no assumptions about your server's filesystem. A reverse proxy cache, such as nginx or Varnish sitting in front of WordPress, cannot be cleared by touching files: the paths belong to the host, are usually not writable by the site, and differ everywhere. Instead, Clear the Server Cache asks the proxy directly, using the same HTTP method Varnish and nginx purge modules have accepted for years. The request is addressed to your own server, with your site's Host header, so it reaches the proxy running there rather than travelling out through a CDN. Nothing leaves the machine. The setting does nothing until your host configures the proxy to accept it, and the plugin reports that rather than claiming success. For nginx with ngx_cache_purge, one location block is enough: ` location ~ /purge(/.*) { address. Add 127.0.0.1 as well if your setup routes it that way. allow 203.0.113.10; deny all; proxy_cache_purge my_cache_zone "$scheme$request_method$host$1"; } The Environment tab shows the address the plugin will send from, so you can match the rule to it. Where a proxy cannot be addressed from the site at all, the purge can instead be **queued for the server to collect**. Each purge writes a JSON record into wp-content/uploads/ultrawebhosting-performance-toolkit/` containing a timestamp, the site URL, its filesystem path and the layers already cleared. Nothing outside WordPress is touched, and the directory denies web access. A privileged process on the server collects those records and clears what WordPress cannot reach itself. This is the approach to use where the proxy cache is owned by root and is deliberately not writable by the site, which is the normal arrangement on shared hosting. Records are pruned automatically, so a host that never collects them costs a site a few bytes and nothing else. A minimal watcher, run from cron once a minute: find /home/*/public_html/wp-content/uploads/ultrawebhosting-performance-toolkit \ -maxdepth 1 -type f -name 'purge-*.json' -mmin -15 | while read -r trigger; do user="${trigger#/home/}"; user="${user%%/*}" [ "$(stat -c '%U' "$trigger")" = "$user" ] || continue # trigger must belong to the account rm -f "$trigger" your-purge-command "$user"