# WordPress Manager

> Install WordPress in one click, adopt sites that are already there, and manage every installation on the server from one place.

Source: https://www.corepanel.net/docs/wordpress/
Last updated: 2026-08-12
Part of the CorePanel documentation — https://www.corepanel.net/docs

---

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

**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

**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:

1. **Creates the database and its user**, with credentials wired into `wp-config.php`.
2. **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.
3. **Creates a real cron job** running the WordPress queue every 5 minutes.
4. **Sets the domain's serving mode to `cms`**, so permalinks work immediately.
5. **Applies the default hardening set** — see [Security and Hardening](https://www.corepanel.net/docs/wordpress/security).

> **The generated password is shown once**
>
> If you let CorePanel generate the administrator password, copy it before closing the
> dialog. It is not stored in a form that can be shown again — use a one-time login link or
> WordPress's own reset if you lose it.
### 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

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. Adoption changes nothing about how the site behaves — it just becomes
manageable.

You rarely have to press it after a migration: a [cPanel import](https://www.corepanel.net/docs/cpanel-import) and
a [restore from backup](https://www.corepanel.net/docs/backups#restoring) both end by scanning the account they
just created, so the sites they bring in are listed as soon as the job finishes. Neither
archive carries a WordPress catalog — the installations are found on disk. Scan by hand
for sites that arrived some other way (uploaded over FTP or SSH, moved between accounts),
or when a job's report says its scan could not run.

**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

**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.

## Your customers see this screen too

On **Business**, an account that can sign into the [client panel](https://www.corepanel.net/docs/client-panel) gets
this same manager for its own installs, under **WordPress** in its own rail — the full
screen, not a reduced one. The account picker is the only thing missing, because a
customer has exactly one account and may not ask which others exist.

Everything below applies to them as it does to you, including the ceilings: a fixed
maximum of installs per account, and of stored restore points per account. Which account a
request may name is decided by the server, so a customer cannot address an installation
that is not theirs — see [what a customer can never
reach](https://www.corepanel.net/docs/client-panel#what-a-customer-can-never-reach).

## Next

- [Managing Installations](https://www.corepanel.net/docs/wordpress/managing) — updates, restore points, integrity
  checks and the maintenance/debug toggles
- [Speed Optimizations](https://www.corepanel.net/docs/wordpress/speed) — WebP, minification and the dynamic page
  cache: how to enable them, verify them and diagnose them
- [Security and Hardening](https://www.corepanel.net/docs/wordpress/security) — the hardening switches and how they
  relate to the WAF