WordPress Manager
Most of what runs on a hosting server is WordPress. CorePanel treats it as a first-class citizen: a WordPress Manager that installs sites, adopts the ones already on the server, keeps them updated, hardens them, verifies their integrity and rolls them back when an update goes wrong.
Every operation runs WP-CLI as the account’s user — never as root — with that account’s PHP version. Nothing CorePanel does to a site is something the account could not have done itself.
The instance list
Section titled “The instance list”WordPress in the panel lists every installation CorePanel knows about, across all accounts:
| Column | Meaning |
|---|---|
| Status | Healthy, Broken (WordPress cannot be loaded) or Missing (the document root is gone) |
| Site | Title and URL |
| Version | Core version, with available updates flagged |
| Path | Where it lives inside the account |
| Origin | Installed (by CorePanel), Detected (found by a scan) or Imported (came in with a cPanel migration) |
From there: Log in, Manage (the instance workspace) and Detach.
Installing WordPress
Section titled “Installing WordPress”Install WordPress, pick the account, and fill in:
| Field | Notes |
|---|---|
| Domain | Any domain or subdomain of the account |
| Subdirectory | Optional — leave empty to install on the document root |
| Site title | |
| Admin username / email | The first administrator |
| Admin password | Optional; leave empty and a strong one is generated and shown once |
| Locale | Optional, e.g. es_ES |
| Version | Optional; defaults to the latest |
What the installer does, beyond downloading WordPress:
- Creates the database and its user, with credentials wired into
wp-config.php. - Writes a hardened
wp-config.php— fresh salts, direct filesystem access (so updates do not ask for FTP credentials), and WordPress’s pseudo-cron disabled. - Creates a real cron job running the WordPress queue every 5 minutes.
- Sets the domain’s serving mode to
cms, so permalinks work immediately. - Applies the default hardening set — see Security and Hardening.
Why the cron takeover matters
Section titled “Why the cron takeover matters”WordPress’s built-in cron only runs when somebody visits the site, and it makes that visitor pay for the work. On a quiet site, scheduled posts, backups and update checks simply do not happen; on a busy one, every visitor is taxed.
CorePanel replaces it with a system cron job every five minutes. This is on by default for sites it installs — and it is the single most common reason a migrated site suddenly behaves better.
Adopting sites that are already there
Section titled “Adopting sites that are already there”You do not have to install through CorePanel to manage a site with it.
Scan searches an account’s home directory for WordPress installations and adds what it finds. Sites brought over by the cPanel importer are picked up the same way. Adoption changes nothing about how the site behaves — it just becomes manageable.
Detach stops managing a site and leaves a .corepanel-wp-ignore marker in its
document root so later scans do not adopt it again. Re-attaching removes the marker.
One-time login links
Section titled “One-time login links”Log in opens the site’s dashboard without a password. The link is single-use, expires in about a minute, and the token is minted inside WordPress itself — CorePanel never sees or stores a WordPress password.
This is what makes supporting a customer’s site practical: you never have to ask for their credentials, and you never have to create a second administrator that outlives the support session.
- Managing Installations — updates, restore points, integrity checks and the maintenance/debug toggles
- Security and Hardening — the hardening switches and how they relate to the WAF