# Managing WordPress Installations

> Updates with an automatic snapshot, restore points, core integrity verification, and the maintenance, debug and indexing toggles.

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

---

Opening an instance from the WordPress list gives you its workspace: **Overview**,
**Updates**, **Security** and **Restore points**.

## Updates

The Updates view shows the full update surface of the site in one place: core version and
available core updates, every plugin and every theme with its current version, whether an
update is available, and whether auto-updates are on for it.

From here you can:

- update **core**, all plugins, all themes, or a specific selection;
- **install** a plugin or theme (optionally pinning a version, optionally activating it);
- **activate**, **deactivate** or **delete** components;
- turn each component's **auto-update** on or off.

### Core update policy

Each instance has a core update policy:

| Policy | Behaviour |
|---|---|
| `none` | No automatic core updates |
| `minor` | Security and maintenance releases only |
| `all` | Major versions too |

`minor` is the setting most sites want: security fixes arrive on their own, major
versions stay a decision you make.

> **A core update snapshots the site first**
>
> Updating core through CorePanel automatically creates a restore point — files **and**
> database — before it starts. If the update breaks the site, rolling back is one click,
> not a support ticket.
## Restore points

A restore point is a snapshot of one WordPress instance: a tarball of its document root
plus a dump of its database.

- Created automatically before a core update, and manually whenever you want one (before
  a risky plugin update, before touching a theme).
- **Three are kept per instance**; the oldest is pruned when a new one exceeds the cap.
- **Rollback** restores both files and database to that moment.

> **Restore points are not backups**
>
> They are an operation-safety net with a three-deep history, stored on the same server.
> For real backups — full accounts, on a schedule, restorable after a deletion or a disk
> failure — use [Account Backups](https://www.corepanel.net/docs/backups).
## Integrity check

**Integrity** verifies the site's core files against wordpress.org's published checksums
and reports anything modified, added or missing. `wp-content` is deliberately out of
scope: it is your content, and there is nothing to compare it against.

When core files have been tampered with, **Reinstall core** re-downloads the running
version over the installation, replacing core files while keeping `wp-content` and
`wp-config.php` untouched. That is the standard first step of a malware cleanup — after
which you still need to look at plugins, themes and uploads.

## Toggles

Three quick switches on the instance:

| Toggle | What it does |
|---|---|
| **Maintenance** | Serves a 503 maintenance page **from the web server**, not from WordPress |
| **Debug** | Turns WordPress's `WP_DEBUG` on or off |
| **Indexing** | Whether search engines are allowed to index the site (`blog_public`) |

Maintenance mode being served by the web server is the point: it keeps working when
WordPress itself is broken mid-upgrade, which is exactly when you need it.

A typical upgrade window:

```bash
corepanel wp maintenance 12 3 on
corepanel wp update 12 3 --core --all-plugins
corepanel wp maintenance 12 3 off
```

> **Indexing off is easy to forget**
>
> Turning indexing off on a staging site is right. Leaving it off when that site goes live
> is one of the most expensive small mistakes in hosting — check it at launch.
## Changing the site URL

**Set URL** updates the site's address, for a move to a new domain or from staging to
production. Run it as part of a planned move, not on a live site you have not backed up.

## Broken and missing instances

| Status | Meaning | What to do |
|---|---|---|
| **Broken** | WordPress cannot be loaded — a fatal error, a bad `wp-config.php`, a database that will not answer | Check the database credentials and the error log; the integrity check and a restore-point rollback are the usual fixes |
| **Missing** | The document root is gone (moved, renamed or deleted) | Re-scan the account: if the site moved, it is re-adopted at its new path |

Most operations are unavailable on a missing instance — there is nothing there to run
WP-CLI against.