Troubleshooting

Problems people hit with SafeHouse, grouped by where they show up. Each entry starts with what you see, then the cause and the fix. If you are locked out of the site, go to Recover from a lockout first.

Use your browser's find (Ctrl+F or ⌘F) with a few words of the message you see.

First, check whether SafeHouse is the cause

1. Turn on safe mode: wp shouse safe-mode on, or create an empty file wp-content/shouse-safe-mode.
2. Try again. If the problem is gone, SafeHouse causes it.
3. Turn safe mode off and switch modules off one at a time, with wp shouse module disable <id> or on SafeHouse → Modules, until the problem goes away. That module is the one.
4. Check the Activity log on the SafeHouse page, or run wp shouse log, for entries from the time it happened.

Logging in

Too many failed login attempts from your address

You see: "Too many failed login attempts from your address. Try again in 15 minutes." The number of minutes varies.

Cause: Login limits locked out your address after too many failed logins from it. Each further lockout of the same address lasts four times longer, up to 24 hours.

Fix: wait, or have another administrator select Lift all lockouts in SafeHouse → Modules → Login limits → Details, or run wp shouse login unlock <your address>. To stop it happening again from your office, add its address to Never lock out these addresses.

This account is paused for new devices

You see: "This account is paused for new devices after many failed attempts. Log in from a device you used before, or try again in an hour."

Cause: someone failed to log into this account 10 times within an hour from browsers that never logged into it. For one hour, only browsers that did can log in.

Fix: log in from a browser you used for this account before, or wait an hour, or run both wp shouse login unlock <login> and wp shouse login unlock <e-mail>.

Everyone is locked out at once

You see: many users report "Too many failed login attempts from your address" at the same time.

Cause: the site is behind a proxy, CDN or load balancer that SafeHouse does not know about, so every visitor seems to come from the proxy's address. Login limits locked out that one address.

Fix:

1. Run wp shouse login unlock --all, or select Lift all lockouts.
2. Tell SafeHouse about the proxy: Behind Cloudflare or a proxy.

Verify: Tools → Site Health shows "Login limits block password guessing".

Login limits cannot block by address on this server

You see: this result in Tools → Site Health, or a note in Login limits Details.

Cause: requests come from a Cloudflare address while SafeHouse is not set up for Cloudflare, or from a private address without SHOUSE_TRUSTED_PROXIES. SafeHouse then stops locking out addresses, so it does not lock out every visitor, and keeps only the per-account rule.

Fix: set up the proxy: Behind Cloudflare or a proxy. On a local or Docker development site this result is expected.

The WordPress mobile app cannot connect

You see: the app or an old desktop editor fails to log in; xmlrpc.php answers "XML-RPC is disabled on this site."

Cause: Hardening turns XML-RPC off by default.

Fix: turn off Disable XML-RPC in Hardening if you need the app. Jetpack and WooPayments keep XML-RPC on automatically.

Forms and checkout

The anti-bot check did not pass

You see: "The anti-bot check did not pass. Please wait for it to finish and try again."

Cause: Cloudflare Turnstile did not confirm the form. Common reasons: the form was sent before the check finished, the page sat open until the token expired, the browser or an extension blocks challenges.cloudflare.com, or the site was opened under a host name other than its WordPress or site address.

Fix: reload the page, wait a moment, and send the form again. Allow challenges.cloudflare.com in content blockers. Open the site under its own address. On wp-login.php, each failure also counts as a failed login for Login limits.

The anti-bot check is unavailable right now

You see: "The anti-bot check is unavailable right now. Please try again in a few minutes."

Cause: your server could not reach Cloudflare, or Cloudflare rejected the secret key, and When Cloudflare cannot be reached is set to Block the submission.

Fix: check outgoing HTTPS from the server and SHOUSE_TURNSTILE_SECRET_KEY. To let forms through during an outage, set When Cloudflare cannot be reached to Let the submission through and log it.

This looks like an automated submission

You see: "This looks like an automated submission. Please make sure JavaScript is on and try again." on registration, lost password or comments.

Cause: the honeypot did not get its proof. The visitor has JavaScript off, sent the form without typing, tapping or clicking in it, or the form is a custom one that does not print SafeHouse's honeypot fields.

Fix: turn JavaScript on. For a custom form, make it fire the standard WordPress hooks (see Developer hooks), or turn off Honeypot on registration, lost password and comments. After rotating the WordPress salts, clear the page cache: cached forms carry an outdated proof.

Turnstile does not show on a form

Cause and fix, in order of likelihood:

• It works but is invisible. Turnstile runs in a mode that shows a widget only when Cloudflare wants the visitor to interact.
• Bot protection is off by default. Switch it on.
• Its Details say "Turnstile is off: add SHOUSE_TURNSTILE_SITE_KEY and SHOUSE_TURNSTILE_SECRET_KEY to wp-config.php." Add the keys.
• Its Details say Cloudflare test keys are not allowed on a production site. Use real keys, or set WP_ENVIRONMENT_TYPE to staging or development on a test site.
• The field shows "Handled by Wordfence Login Security, skipped here.": Wordfence's reCAPTCHA protects login and registration instead.
• Comment forms show it only to visitors who are not logged in.

Checkout orders fail with HTTP 403

You see: block checkout, express payment buttons (Apple Pay, Google Pay) outside the checkout page, or a headless store fails with the error code shouse_bots.

Cause: Turnstile on checkout checks every order sent to the WooCommerce Store API. Buttons and apps outside the checkout page cannot pass the check.

Fix: turn off Turnstile on checkout in Bot protection if the shop uses express payment buttons or another storefront.

Customers see the maintenance page

You see: logged-in customers get "We will be back soon".

Cause: Maintenance mode shows the normal site only to users with the capability in Who sees the normal site. Customers can only read.

Fix: set Who sees the normal site to Every logged-in user, or switch Maintenance mode off.

Plugins and installs

Installing plugins and themes is locked by SafeHouse

You see: "Installing plugins and themes is locked by SafeHouse. Unlock it first (SafeHouse in the admin menu or wp shouse unlock)." The Add Plugin button and the file editor may be missing too.

Cause: Install lockdown is on.

Fix: select Unlock installs for 30 minutes in Install lockdown Details, or run wp shouse unlock --minutes=15. If the button is missing, SHOUSE_LOCKDOWN_UI_UNLOCK is false and only WP-CLI can unlock.

New accounts get the Subscriber role

You see: the default role is Editor or Shop manager, but new accounts become Subscribers.

Cause: Hardening's Keep new accounts out of admin-level roles treats any role that can post raw HTML, manage users, plugins, settings or the shop as admin-level. Editors and Shop managers have some of those rights.

Fix: if new accounts really should get that role, turn the setting off.

Alerts

Alert e-mails do not arrive

Check, in order:

1. SafeHouse → General → Alert recipients, or the site's admin e-mail when that field is empty.
2. Whether the site can send mail at all. Set up SMTP mail and use Send a test e-mail to me.
3. Whether WordPress's scheduled tasks run. The hourly and daily checks need visits to the site, or a system cron when DISABLE_WP_CRON is set.
4. Whether the event is e-mailed at all. Address lockouts, bot blocks and Plugin health findings never are: see Alerts and reports.
5. Change alerts records its first baseline silently. Only changes after that are e-mailed.

A "changes detected" e-mail after every deploy

Cause: your deploy changes plugin folders or wp-config.php, and Change alerts reports it at the next hourly check.

Fix: run wp shouse watch accept at the end of every deploy. See Deploy with git or CI.

The vulnerability notice does not go away

You see: "Security vulnerability in installed software" on every wp-admin screen.

Cause: an installed plugin, theme or WordPress version has a vulnerability with a CVSS score of 7 or more, or no fix yet. Inactive plugins and unused themes count too, because their files can still be attacked. The notice cannot be dismissed.

Fix: update the software to the version named in the notice, or delete it. The notice disappears as soon as the update finishes.

Vulnerability data has not been downloaded yet

You see: this result in Site Health, or "The last download failed: …" in Vulnerability alerts Details.

Cause: the site could not download or verify the data from updates.designhouse.me. SafeHouse retries every hour and keeps the previous data meanwhile.

Fix: check outgoing HTTPS from the server, then select Check now. A signature or checksum failure is also written to the activity log as advisories_rejected.

Settings page and WP-CLI

A module shows Unavailable

The reason is printed under the module's description. The common ones:

Reason	What to do
"Wordfence is active and already warns about vulnerable plugins, themes and WordPress versions."	Nothing: Wordfence does this job. See Running with Wordfence.
"Wordfence brute force protection is on and already limits login attempts."	Nothing, or switch Wordfence's brute force protection off to use Login limits.
"Needs WooCommerce."	Omnibus price history only works in WooCommerce shops.
"DISALLOW_FILE_MODS in wp-config.php already blocks all installs and updates."	Nothing: WordPress already blocks installs.
"DISALLOW_UNFILTERED_HTML is set in wp-config.php, so nobody may add raw scripts."	Remove the constant to use Header and footer scripts.
"The LiteSpeed Cache plugin is active and manages the server cache itself."	Use one of the two, not both.
"Add SHOUSE_CLOUDFLARE_TOKEN … and SHOUSE_CLOUDFLARE_ZONE … to wp-config.php."	Add both constants. The zone ID must be exactly 32 hexadecimal characters. See Cloudflare cache.

A module shows Enabled, not running

Safe mode is on. See Leave safe mode.

A setting is greyed out

Note next to it	Cause
"Handled by …, skipped here."	Another plugin or wp-config.php already does this. See Running with Wordfence.
"Pinned by SHOUSE_MODULES in wp-config.php."	The module is forced on or off in code.
"Settings are locked by SHOUSE_LOCK_SETTINGS in wp-config.php. Change them in code."	The whole page is read-only.
"Set in wp-config.php with SHOUSE_TRUSTED_PROXIES."	The proxy is set in code.
No note, on a script field	Your account may not post unfiltered HTML, so it cannot edit Header and footer scripts.

Settings saved, but the page cache was cleared

Every save of SafeHouse settings clears the whole LiteSpeed and Cloudflare page cache when those modules run, because many settings change what visitors see. This includes wp shouse module enable and disable.

A WP-CLI command is not a registered subcommand

You see: "Error: 'login' is not a registered subcommand of 'shouse'. See 'wp help shouse' for available subcommands."

Cause: module commands exist only while their module runs. The module is off, Unavailable, or safe mode is on.

Fix: check wp shouse status. The always-available commands are listed on Command line reference.

Caching

LiteSpeed does not serve pages from its cache

See LiteSpeed page cache. Test in a private window: logged-in users, commenters and visitors with a cart always skip the cache. On LiteSpeed Enterprise the server cache must be turned on with CacheLookup public on.

Visitors see an old page after a change

• A change made with WP-CLI reaches the LiteSpeed cache only with the next web request. Run wp shouse cache purge.
• Cloudflare cache clears the changed post, the home page and the post's archives, not feeds, paginated archive pages, or author and date archives. Clear everything with Clear the whole Cloudflare cache or wp shouse cloudflare purge.
• Changes within 30 seconds of a previous purge wait for a scheduled task.

Cloudflare refused to clear the cache

You see: this result in Site Health, "The last call on … failed: …" in Cloudflare cache Details, or cloudflare_purge_failed in the activity log.

Cause: usually the API token lacks the Cache Purge permission for this zone, or the zone ID belongs to another zone.

Fix: create a token with only Zone → Cache Purge for this zone, update SHOUSE_CLOUDFLARE_TOKEN, and select Clear the whole Cloudflare cache to test it. See Cloudflare cache.

The SafeHouse object cache cannot reach Redis

You see: this critical result in Site Health, with a reason.

Cause: Redis is down, the connection settings are wrong, or the PhpRedis extension is missing in the web server's PHP. The site keeps working on WordPress's own cache, only slower.

Fix: check the WP_REDIS_* constants and the Redis server, then run wp shouse object-cache status. See Redis object cache.

wp shouse object-cache enable fails

Message	Fix
"The PhpRedis extension is not installed for the PHP that runs WP-CLI. The web server's PHP needs it as well."	Install PhpRedis for the command-line PHP too.
"Another plugin's object-cache.php drop-in is installed. Remove it (or deactivate that plugin) first."	Disable the other object cache first.
"Redis is not usable: …"	Check the address, password and that Redis runs.
"Redis 6.0 or newer is required (this server: …)."	Upgrade Redis.

Mail

Sending failed

You see: "Sending failed: …" after Send a test e-mail to me, or mail_failed in the activity log.

Cause and fix: see SMTP mail. The usual causes are a wrong host or port (465 needs 'ssl', 587 needs 'tls'), wrong credentials, or a From address on a domain the SMTP server may not send for.

Shop

The lowest price does not show next to a reduced price

Check Omnibus price history. The usual causes: Show the lowest price next to reduced prices is off; another Omnibus plugin is active ("Handled by …, skipped here."); the product is not on sale yet; or the variable product's variations have different prices, in which case the line shows for the picked variation. Run wp shouse omnibus history <id> to see what is on record.

The lowest price equals the regular price

The product was already reduced, or created on sale, when SafeHouse started recording, so no earlier price is on record. The figure becomes accurate at the product's next price change. Run wp shouse omnibus status: such products show regular in the source column.

Updates

No SafeHouse update appears

Run wp shouse update-check:

Result	Meaning
Updates are disabled by SHOUSE_DISABLE_UPDATES.	Updates are off on purpose.
This is a git checkout; updates are disabled so they cannot overwrite it.	Deploy new versions yourself.
Manifest signature is invalid.	The manifest is not signed with a key this version trusts. Check the activity log for update_rejected. If it persists, report it privately.
HTTP …	The server cannot reach updates.designhouse.me.
Up to date.	There is no newer release.

The downloaded SafeHouse package does not match the signed checksum

You see: "The downloaded SafeHouse package does not match the signed checksum. Update cancelled."

Cause: the downloaded file differs from the signed release, through corruption in transit or tampering. SafeHouse deleted it and installed nothing.

Fix: try the update again later. If it keeps failing, report it privately on the repository's Security tab. See Signed updates.

Still stuck?

Open an issue and include:

• the output of wp shouse status
• the WordPress, PHP, WooCommerce and SafeHouse versions
• the exact message, and the activity log entries from around the time it happened (wp shouse log --limit=50)
• what you expected and what happened instead

Report security problems privately on the repository's Security tab with Report a vulnerability, never in a public issue.