Read the WordPress tab's site checks

Under Health & checks on a hosting’s WordPress tab, each row loads on its own when you scroll to it and re-checks when you ask. The Site health row is covered in Repair a broken WordPress site. This page covers the other four. The rows appear once WordPress is installed on the hosting.

Before you start

• You can open the hosting. Changing anything in these rows needs the Edit hosting config (PHP, cache, redirects, …) permission. Administrators, Operators and Customers have it for the hostings they manage.
• The node that owns the hosting is online. All four checks run on that node.

Steps

File permissions

1. Open Hostings in the sidebar, click the hosting, and open the WordPress tab.
2. Find File permissions. The summary reads All <n> checks pass, or the number of problems with how many checks pass. Click Re-check to run it again.
3. Open the passing checks to see what was verified: nginx can reach the document root, Owned by the site user, Directories traversable by nginx, Static files readable by nginx, Nothing world-writable, No setuid/setgid files, WordPress can create directories, wp-config.php not readable by other users, PHP session directory private and Log directory private.
4. For a problem, use the matching button:
   • Repair permissions: gives the site user ownership of the whole document tree, sets directories to 0755 and files to 0644, then sets wp-config.php back to 0640. Nothing outside this site is touched and no service restarts. Confirm with Repair.
   • Tighten wp-config.php: sets wp-config.php to 0640, so only the site’s own user can read the database password.
   • Tighten logs & sessions: sets the site’s logs/ and tmp/ directories to 0750 and gives tmp/ to the site user.
5. At the bottom of the row, click Repair automatically to switch self-repair on, or Turn off to switch it off. With Auto-repair on the node fixes a tree nginx cannot read, a readable wp-config.php, and open logs/ or tmp/ every five minutes. With Report only, problems are shown and left alone. The node-wide setting [permissions] enabled in agent.toml also applies; it is on by default.

PHP runs as the site user and writes the site, and nginx runs as a different user and only reads. That is why directories need world-traverse and static files world-read, and why a blanket chmod 750 makes a site return 404.

WordPress mail

1. Find WordPress mail. The summary reads Sends from this domain, no failures recorded, or the number of problems. Click Re-check to run it again.
2. Open the row to read each check. The checks cover the sender pin (Sender is pinned to this domain, Sender pin is out of date, Hyperion does not rewrite this site's mail), the record of failed sends (No send failures recorded, Failed sends are not being recorded, WordPress could not send, PHP mail() on this server is failing, Messages from this site are too big for this server), the server’s mail path (This server's mail path is in place, This server's mail path is broken, A message was over this server's size limit, Sendmail refused this site's mail), and who sends (An SMTP plugin is handling mail, Hyperion is sending this site's mail).
3. When there are problems, each one is listed with its explanation. Two buttons may appear:
   • Configure now: installs the Hyperion mail plugin, which records every failed send and, unless rewriting is off, keeps the From address on this domain. If mail has been failing and an SMTP plugin handles it, Hyperion also takes sending back and says so. A stopped postfix, or site users who have lost the right to queue mail, are put right as well. Confirm with Configure.
   • Raise the size limit: a link to the node’s mail settings, because the size limit is shared by every site on the node. It appears when messages were refused for size, and only for users who can manage panel settings.
4. At the bottom of the row:
   • Hyperion rewrites the sender replaces a From address on another domain with the site’s own address, since a message from another domain fails SPF and is dropped without a bounce. Turn off (own SMTP server) stops that for a site that sends through its own SMTP server, and failed sends are still recorded. While it is off, the row reads Hyperion leaves mail alone and offers Rewrite the sender again.
   • Hyperion is sending instead of the SMTP plugin appears when Hyperion took sending over. Hand back to the plugin returns control once the plugin’s credentials are fixed.
   • Auto-configure on keeps the mail plugin current every five minutes. Report only shows problems and changes nothing; Configure automatically switches it on.

Public sign-ups

1. Find Public sign-ups. It reads WordPress’s own users_can_register setting: Closed — strangers can't create accounts, or Open — anyone can create an account (role <role>).
2. If the site has no member area, shop or customer zone, click Close sign-ups and confirm. Existing accounts are untouched. This is the same checkbox as Settings → General in wp-admin.
3. If the row says the default role can do more than read, treat it as a compromise: close registration, then check the user list for accounts nobody created on purpose.

Registration spam is many addresses each making one successful request, so banning addresses does not stop it. Closing sign-ups does. When a site gets far more registrations than normal, Hyperion tells the administrators once a day for that site (“Sign-up flood on a WordPress site”).

Sign-up spam guard

1. Find Sign-up spam guard. It reads Off — bot sign-ups are not filtered or On — bot sign-ups (links in names, honeypot) are blocked.
2. Switch it on with the toggle. Hyperion adds a small must-use plugin to the site. It rejects sign-ups that put a link in a name field or fill a hidden honeypot field, on native WordPress, WooCommerce and Paid Member Subscriptions, and it deletes a spam account that gets through. In wp-admin, its state shows under Tools → Hyperion.
3. If the row says On, but the plugin file is missing — re-installs on the next toggle, switch it off and on again.

Check that it worked

Each row re-renders in place after an action and shows its new summary. After Repair permissions, File permissions reads All <n> checks pass and the site loads. After Close sign-ups, Public sign-ups reads Closed.

If it fails

• Could not check — ... in any row: the owning node did not answer, or the check failed. The text after the dash is the reason.
• Could not read the registration setting — nothing was changed: wp-cli could not read the setting, for example because WordPress does not start. See Repair a broken WordPress site.
• this hosting serves no document tree of its own: the hosting is a proxy or redirect, so there are no files to check.
• <user> cannot path-resolve into <docroot>: nginx cannot reach the document root, so every request returns 404. Click Repair permissions.

Related

• Set up the outgoing mail relay
• Set up SPF and DKIM for a site’s mail