WordPress

Installing

klyrn site create example.com --type wordpress \
  --title "Example" --admin-user editor --admin-email you@example.com

One job creates:

• The database and its own user, granted on that database only, from localhost.
• wp-config.php with fresh salts and a wp_ table prefix.
• The admin user. Credentials are stored encrypted, and revealing them is audited.
• Permalinks and the HTTPS site address.
• DISABLE_WP_CRON, replaced by a real cron entry running every five minutes as the account user.
• FS_METHOD set to direct, so WordPress never asks for FTP credentials to update itself.
• A Let's Encrypt certificate, if DNS points here.

Everything WordPress-facing runs through WP-CLI 2.12.0, pinned by SHA-512 and executed as the site's Unix user, never as root. KLYRN never splices PHP into wp-config.php.

Health signals

klyrn wp health example.com

Ten deterministic signals, each either fine or specific. There is no score out of a hundred.

The report reads exactly six constants out of wp-config.php. The rest of that file is the database password and eight authentication salts.

Plugins, themes and known vulnerabilities

Plugins and themes can be found and installed from wordpress.org on a site's WordPress tab. Installed ones are checked every day against published vulnerabilities, and a match is shown on that tab.

Hardening

klyrn wp harden example.com disable-file-editor
klyrn wp harden example.com disable-debug
klyrn wp harden example.com fix-wp-config-permissions
klyrn wp harden example.com repair-file-permissions

Four actions, and nothing else is accepted:

disable-file-editor

Sets DISALLOW_FILE_EDIT.

disable-debug

Sets WP_DEBUG, WP_DEBUG_DISPLAY and WP_DEBUG_LOG to false. An existing debug.log is left where it is.

fix-wp-config-permissions

Mode 0640, owned by the account, and inherited POSIX ACL entries stripped. Reports that nothing changed when nothing needed to.

repair-file-permissions

Clears the other-write bit under the document root. Nothing becomes more readable and no owner changes.

Updates and the policy

klyrn site wp example.com status
klyrn site wp example.com update all           # backs up first
klyrn site wp example.com update core --no-backup

klyrn wp policy example.com --core minor --plugins all --themes manual
klyrn wp policy example.com --plugins selected --select-plugins woocommerce,akismet
klyrn wp policy run example.com

Core takes manual, minor or all. Plugins and themes take manual, selected or all. selected with an empty list is refused. The default for a new site is core minor, plugins and themes manual.

The automatic pass runs at most once every 24 hours per site, and only between 02:00 and 06:00 server local time. It backs the site up first unless you turn that off, then applies what is due. Then it fetches the site through nginx and reads the status code. Anything that is not a 2xx or 3xx fails the job.

KLYRN does not roll a WordPress update back. The database may already have been migrated. When the verify step fails, the message names the pre-update backup. If you turned the backup off, it says that none was taken.

Cloning and search-replace

klyrn wp clone example.com copy.example.com
klyrn wp clone example.com copy.example.com --account otheraccount

A clone is an independent site with its own files, database, database user, password and certificate. It cannot be pushed back to the original. For that, use staging.

Cloning across accounts is done by root with an explicit ownership change, because /home/<account> is 0710 and hosting accounts share no group.

klyrn wp replace example.com http://old.example.com https://example.com
klyrn wp replace example.com http://old.example.com https://example.com --apply

Search and replace is a dry run by default. Applying requires typing the site's own domain to confirm. It runs through WP-CLI with --precise and --all-tables, so serialised PHP survives. It skips post GUIDs unless you pass --include-guids. Rewriting those makes every feed reader treat every post as new.

The search term must be at least 3 and at most 2000 characters, and may not equal the replacement. It may not start with -, which WP-CLI would read as one of its own options.