Your WordPress sites

The panel keeps an eye on your WordPress installations: which ones exist, whether they are up to date, and whether any of them has a known security hole.

One thing first, because it decides everything below: nothing is installed inside your WordPress. No plugin, no extra file, no account. The panel looks in from the outside, from the server itself. That is why it keeps working when your site does not, and why you cannot switch it off by deleting a plugin in WordPress that you do not recognise.

How a site gets noticed

You do not have to register anything. The server looks through your web folders and recognises a WordPress by its files — whether you installed it from the panel or dropped it there yourself from a zip years ago. What it finds comes under management and gets a card.

It looks in your domain's main folder and one folder below it. So yoursite.com and yoursite.com/blog or yoursite.com/shop are picked up automatically. If your WordPress lives deeper than that, ask your hosting provider to add it by hand.

Bringing a site under management changes nothing about your website. It is a note beside it, not a change to it. Removing it again does nothing to your files either.

The site card

For each WordPress you see:

• Which version of WordPress is running.
• How many updates are waiting — for WordPress itself, for your plugins and for your themes.
• Which PHP version the site uses. That comes from the panel rather than from WordPress: the panel decides it, so the panel knows it for certain.
• Whether there is an SSL certificate, and how long it is still valid.
• Whether the WordPress files still match what was published (see below).
• A screenshot of the front page, if your hosting provider has that switched on.

"Measured …"

The card always says when it was last looked at. That is honesty rather than sloppiness: measuring a site takes time, so it happens periodically instead of every time you open the page. If it says 3 hours ago, that is what you are looking at — the state of three hours ago.

A site that has never been measured is listed separately as not measured yet. It is not quietly counted as "all fine": "there is nothing to do" and "we have not looked" are different answers.

The file check

WordPress publishes, for every release, a list of what each file should look like. The panel compares your installation against it. Four outcomes:

Modified is the only alarming one: it is what it looks like when somebody has put code into WordPress itself. Often it is innocent — a developer who once "just tweaked something" in a core file — but it is the one worth emailing your hosting provider about.

File set differs is usually harmless. WordPress 7.0, for instance, ships a few folders that are not in the official checklist yet, so every fresh install reports it. That is exactly why it is a separate outcome and not an alarm: a warning that is permanently on for everybody is a warning nobody reads.

Vulnerabilities

There is a public database of known security holes in plugins and themes. Your hosting provider fetches it every hour and compares it with what is installed on your sites. A badge next to a plugin means there is a known hole in exactly the version you are running.

The colour says how serious: critical, high, medium, low, or unknown when the severity has not been rated yet. That last one does not mean "unimportant" — it means the hole is so recent that nobody has scored it.

Two things that often surprise people, both deliberate:

• A deactivated plugin still counts. Its files are still on the server and in some cases are reachable even with the plugin switched off. Deactivating helps; removing helps more.
• "An update is available" is not the same as "it is fixed". A plugin can be several releases behind the one that closed the hole, so the panel shows which version actually contains the fix.

What to do about it

Two buttons, and which one you need depends:

1. Update — a version with the fix exists. Almost always the right answer.
2. Deactivate — no fix has been released yet. The plugin switches off, the files and your settings stay exactly where they are, and you can switch it back on with one click.

Once the hole is fixed, the badge disappears at the next measurement.

Are those numbers current?

Two timestamps decide how current a warning is: when your site was last measured, and when the vulnerability database was last fetched. The panel shows both. If something looks wrong, "measure it again" is the first step — ask your hosting provider.

Updating without holding your breath

Every update the panel performs for you goes through the same three steps, and the middle one is the part that matters.

1. A restore point is taken first. A copy of the files that are about to change, plus a copy of the database. It is made on the server, outside your own disk space, so it does not eat into your quota and does not end up inside your next backup.
2. The update runs. Your site is put into maintenance mode for the few seconds the files are being swapped, so nobody sees a half-updated plugin.
3. The site is checked, seven ways: does WordPress still start, does it still fully load, did new PHP errors appear in your log, does the database still check out, did the files really land, do your pages still answer, and do they still look like pages rather than error messages.

If anything is wrong, it is put back automatically. Within about a minute, without anybody watching, and you get a record saying what failed and what was restored.

Two things worth knowing about that record:

• A page that was already broken before the update is not treated as our doing. It is reported as a warning. Undoing the update would not have fixed it and would have hidden it.
• The database is only put back when it has to be. For a WordPress core update, always — core changes the database, and old files with a new database do not work. For a plugin or theme, only if the database itself was what failed. The reason is simple arithmetic: putting the database back also undoes anything that happened in the minute since the copy was made — an order, a comment, someone signing in.

Deciding what updates by itself

You choose per site:

You can also make an exception for one plugin — the shop plugin that always needs testing first, or the one you want moved the moment anything ships.

The default for a new site is security and maintenance releases for WordPress, security fixes for plugins and themes. Nothing is updated for a feature you did not ask for; things are updated when leaving them alone is the more dangerous choice.

One consequence worth naming: while the panel is looking after a component, WordPress's own automatic updates for it are switched off. Not to take something away — WordPress's updater works fine — but it cannot take a restore point first, so what it does at three in the morning cannot be undone at four.

Making a site harder to break into

The panel has a checklist of sixteen security measures. Six of them are applied automatically to any WordPress the panel installs for you; they are the ones that cannot break a working site. The other ten are yours to choose, and each one says what it costs as well as what it buys — blocking xmlrpc.php also stops the WordPress mobile app, turning away aggressive crawlers also turns away some you might be paying for.

Every measure can be switched off again, except four, which say so before you switch them on and take a restore point first:

• Renaming the admin account — the old name is not kept, and putting it back would only restore the weakness.
• Regenerating the security keys — everyone is logged out, including anyone using a stolen session. That is the point of it.
• Randomising the database table names — thorough, and a plugin that assumes the standard names will break.
• Fixing the file permissions — nothing about this breaks a site; the old permissions simply are not recorded.

The checklist always reads the real state of your site, not a note somebody made. If you edit a file back by hand, the tick disappears.

The four switches

• Maintenance mode — visitors get a "back shortly" page with your own wording instead of WordPress's default sentence, and search engines are told it is temporary.
• Debug logging — writes PHP errors to a log. Showing those errors to visitors is a separate switch and is off unless you ask, because an error message on a page tells a stranger the exact folder layout of the server.
• Search engines — asks Google and friends not to index the site. It is a request, not a lock. If it really must be private, use the next one.
• Password protection — the whole site, wp-admin included, asks for a name and password before WordPress even starts. Useful while a site is being built.

Going back

Every restore point the panel takes is listed, with what it was for and how old it is. You can put one back yourself, and take one by hand before you do something risky. Five are kept per site; the oldest is dropped as new ones arrive.

Where all of this lives

In the panel: open your account and click WordPress in the bar at the top, beside Websites, Mail and Databases. You get a card per site with its version, how many updates are waiting, how many vulnerabilities were found and whether it has a certificate. Click a site and a panel slides open with five tabs: the overview, security (the checklist and your update policy), the switches, the staging copy, and the history.

Every card also says when it was last measured. A site that has never been measured says so — it does not quietly count as clean.

Everything at once

If you have more than one WordPress, you do not have to do them one at a time. Tick some sites (or tick none, and it applies to all of them) and choose:

• Update everything — each site gets its own restore point and its own checks, and rolls itself back if anything goes wrong.
• Secure everything — the critical measures on every site. The three one-way ones never take part in a bulk run.
• Policy for every site — set what updates by itself, everywhere, once.
• Schedule for every site — see below.

You get a result per site, including the ones that were skipped and why. One site failing does not stop the rest: that is exactly why one broken site does not have to leave the other ninety-nine unsecured.

Into wp-admin without a password

On a site's overview there is Open wp-admin. It gives you a link you use once and that expires after five minutes — you do not need to know your WordPress password. The link is a key: whoever holds it is an administrator of that site until it is used. So do not share it and do not save it.

The moment you use it, it is gone. Use it a second time and there is nothing left to use.

Scheduled tasks that actually run

By default WordPress runs its scheduled tasks when somebody visits. That goes wrong in two directions: a quiet site never runs them at all (no backups, no follow-up mail, no update check), and a busy one runs them far too often.

Under Switches there is Scheduled tasks from the system. Turn it on and the server does it — every five minutes, visitors or not — and WordPress stops doing it itself. You notice nothing, except that it starts working.

What the assistant may do

If you use the panel's AI assistant, it may read everything about your WordPress sites: which sites there are, what versions they run, what updates are waiting, what vulnerabilities were found, whether the files are intact, how the switches stand, what your policy is and what the last updates did.

And since this release it may, always with your approval first, do five things:

• update through the safe path (restore point, checks, automatic rollback);
• make a staging copy of a site;
• take a restore point;
• switch maintenance mode on or off;
• switch search engines on or off.

Before anything happens you are shown a card with exactly what would change — not "I will update some plugins", but "hello-dolly 1.6 → 1.7.2, restore point first". Only when you approve that does it happen.

The rest it never does, however you ask: signing in to your WordPress admin, pushing a staging copy to production, putting a restore point back or deleting one, installing WordPress or a plugin, applying or removing the security measures, putting a password on your site, or doing anything to all your sites at once. Those are not settings somebody could get wrong — those tools simply do not exist for the assistant. The AI connection screen says why, one by one.

From the command line

If you have SSH access, you can ask for the same things:

corectl wp sites                     # your sites and their cards
corectl wp updates                   # what is waiting
corectl wp vuln                      # known vulnerabilities
corectl wp health                    # is everything running

corectl wp harden yoursite.com       # the security checklist and what is on
corectl wp toggles yoursite.com      # the four switches
corectl wp policy --site yoursite.com   # what updates by itself
corectl wp snapshots --site yoursite.com  # your restore points
corectl wp runs --site yoursite.com  # what the last updates did

Your hosting provider can also do the changing half from there:

corectl wp harden apply yoursite.com --measure xmlrpc
corectl wp maintenance  yoursite.com --state on --title 'Back shortly'
corectl wp safe-update  yoursite.com --type plugin --slug akismet
corectl wp snapshot     yoursite.com --note 'before the theme change'
corectl wp login        yoursite.com   # a one-time administrator link
corectl wp cron set     yoursite.com --state on --minutes 15

# and everything at once, with an outcome per site
corectl wp bulk secure --account youraccount --set critical
corectl wp bulk update --account youraccount --dry-run on   # look first

Trying something first

If an update or a change makes you nervous, you can make a complete second copy of the site on an address of its own, break things there, and push back only the parts you want. That is Making a test environment — including the part most tools do not tell you: a database push is an overwrite, not a merge.

Where the panel keeps your WordPress data

The panel keeps two things about your site outside your own directory: the screenshot you see on the site card, and the vulnerability feed your plugins are checked against. Both live on the server in a directory only the administrator can enter, and since round 2's final pass they are readable only by the administrator too.

Nothing in your own directory changes because of that. Everything the panel writes into your document root — an .htaccess rule, a hardening setting — keeps exactly the permissions the web server needs in order to read it. A rule the web server may not read is not a rule.

You can look, from the server:

ssh root@stck1.corecp.dev 'ls -l /var/lib/corecp/wp/'
ssh root@stck1.corecp.dev 'corectl wp card test300.nl'

There is nothing for you to do here. It is written down so you know where your data is if you ever want to check.

See also

• Making a test environment
• What you can do yourself
• Where a website is served