WordPress

The WordPress section gathers everything a fast and safe WordPress site needs: one-click installation, three cache levels, safe updates with automatic rollback, protections, a staging copy and tools. It is in the menu of administrators, resellers and users; every site also has a WordPress tab on its page. Everyone sees only their own sites.

The first time, an administrator presses Prepare the server: the panel installs WP-CLI (pinned version, verified against the official checksum), Redis (the global service stays off: every site gets its own), the PHP Redis extensions and the shared nginx settings. panel-agent setup wordpress, run by install.sh and upgrade.sh, does the same.

When the panel finds WordPress in a site you already have, it tells you: press Manage with the panel. Nothing changes until you turn something on.

Installation

Press New WordPress and choose:

• In an existing site (only empty, just created sites) or Create the site too: the new site follows the package limits like a normal site;
• language (Italian by default), title, administrator user (avoid “admin”: it is the first name bots try) and email;
• password: generated by the panel (shown only once, copy it right away) or chosen by you (at least 12 characters).

The panel creates a dedicated database linked to the site, downloads WordPress from wordpress.org, writes wp-config.php with fresh security keys, sets /post-name/ permalinks, removes Hello Dolly and Akismet (if left selected), turns on page cache, Redis and protections, moves WP-Cron to the system cron and checks that the site answers. You follow the progress step by step. Passwords never appear on a command line: WP-CLI reads them from standard input.

Every WordPress command runs as the system user of the site, never as root: a site cannot touch the other sites nor the server.

Cache

Three cache levels, already configured:

1. Page cache (nginx): ready-made pages are served without PHP. POST requests, addresses with parameters, logged-in users, cart, checkout, account (WooCommerce too), admin area, REST API, feeds and sitemaps are never cached. The default lifetime is 60 seconds: safe for dynamic sites too, and a big win under load. Purge all empties the cache of the site. The percentage shown is computed from the access log of the last 24 hours.
2. Object cache · Redis: a private Redis for each site, reachable only by the site on a local socket (no network port), with limited memory (64 MB by default) and no disk persistence. The panel installs and enables the Redis Object Cache plugin.
3. OPcache: PHP code stays in memory already compiled. It is on for the whole server; the numbers shown (hit rate, memory) are those of the PHP version of the site, shared by all the sites using it. The panel reads them straight from PHP-FPM with a small script that is not reachable from the web.

The dark card measures the home page response time (TTFB, median of 5 samples) with the cache and without it (standard WordPress) and shows how many times faster it is. Press Measure again whenever you want: measurements stay in the history.

Safe updates

Update everything safely runs in order:

1. check that the site answers and list of the updates;
2. local backup of files and database (plus a remote backup when backups are configured);
3. update of WordPress and of its database, then plugins and themes;
4. check of the WordPress files against the official checksums;
5. check that the home page answers (status 200, no PHP error, complete page).

If a step fails, the panel restores by itself files and database as they were a moment before and emails you. Administrators can press Test the automatic rollback to verify it on a site.

Automatic updates: Off, Security and minor only (minor releases of WordPress and plugins) or Everything. They run at night between 2 and 5 am, every site at its own time, always with the same safe procedure; the outcome is emailed to the account (and its reseller). The database of the site must be linked to the site in the panel.

Backup

The Backup card, below the updates, gathers the copies of the site:

• Back up now immediately takes a local copy of files and database (and a remote backup, if backups are configured). You follow the progress step by step.
• Local copies stay on the server in a folder the site can neither read nor change, and are restored in seconds. Besides those made by hand, the panel takes one by itself before every update, before publishing the staging copy, before Search and replace and before repairing the WordPress files. For each one you see date, reason, content and disk space. The last 3 made by hand and the last 2 automatic ones are kept.
• Restore puts the chosen copy back. First the panel copies the site as it is now (listed as Before a restore): if the restore fails or the site stops answering, it puts it back by itself; and if you change your mind, you can restore that copy.
• Remote backups: the latest backups of the site in the remote repository, also restored in one click (files, database or both). All backups opens the Backups tab of the site.

Protections

Every protection has its own switch:

• Limited sign-in attempts: at most 10 attempts per minute per address on wp-login.php;
• Blocking of persistent attacks: fail2ban blocks for an hour whoever keeps trying to sign in or on XML-RPC;
• XML-RPC closed;
• PHP blocked in the uploads folder: a PHP file uploaded behind your back cannot run;
• File editor disabled (DISALLOW_FILE_EDIT);
• Sensitive files hidden: wp-config.php, readme, SQL dumps and log files can never be downloaded (the debug log never can);
• WordPress files intact: every night the files are compared with the official checksums; if something changed you get an email;
• WordPress version hidden: the version does not appear in pages, feeds and the addresses of styles and scripts (which are still refreshed with every new version);
• User names cannot be discovered: visitors cannot find out user names with ?author=1, the REST API (/wp-json/wp/v2/users) or the sitemap. Whoever is signed in to WordPress, and so the block editor, is not affected.

The last two protections live in a small must-use plugin (wp-content/mu-plugins/panel-protections.php) that the panel writes and updates by itself: do not edit it by hand. They are already on for sites installed or imported from version 0.49.0; on older sites you turn them on with the switches.

Directory listing is always off and every site runs isolated in its own user.

Known vulnerabilities

Every night the panel compares the version of WordPress and of every plugin and theme with the public list of known vulnerabilities of Wordfence Intelligence. Outdated plugins are the most common way a WordPress site gets hacked.

To turn it on an administrator opens WordPress › Known vulnerabilities, enters the Wordfence Intelligence API key (free, also for commercial use: a Wordfence.com account is enough) and switches on the nightly check. The panel downloads the list once a day and checks every site at its own night time, together with the other checks. The key stays encrypted on the server and is never shown.

The Known vulnerabilities card of each site shows, for every affected plugin, theme or WordPress version, the vulnerability (with the link to its Wordfence page) and the version that fixes it. Update what has a fix starts the safe update of only those components; Check now runs the check again. When the nightly check finds new vulnerabilities, the account (and its reseller) gets an email with the list.

With the automatic fix on (an administrator setting, for every site) the panel updates at once, with the same safe procedure and automatic rollback, only the plugin, theme or WordPress that have a fix; the outcome arrives by email. When a vulnerability has no fix yet, deactivate or replace the plugin until its author publishes a safe version.

Must-use plugins and drop-ins are not checked: they have no public name to compare with the list. Staging copies are not checked at night.

Staging copy

Create staging copy copies files and database into a separate site of the same account (staging.<domain> by default: point that name to the server in the DNS). Addresses are rewritten in the serialized data of plugins too; the copy is protected by a password (user anteprima, the password is on the card) and is not indexed by search engines.

The copy does not count against the site limit of the package (one per site; its disk space counts) but it does count against the site limit of the server license.

Publish to production brings the copy to the real site: files, database or both. The live site is backed up first; if it does not respond correctly afterwards, it goes back as it was by itself. Careful: publishing the database loses the orders and comments received by the live site after the copy. Delete copy removes the staging site and its database.

Tools

• Enter wp-admin without a password: opens wp-admin already signed in as an administrator. The link is valid for 60 seconds and works once; the panel stores only a fingerprint of the code.
• Search and replace: first counts the replacements, then backs up the database and applies them (serialized data included). Useful for a domain change.
• WP-CLI in the browser: users get a list of safe commands (flush the cache, list and activate plugins, read the site address...); administrators may use full WP-CLI. Commands always run as the site user.
• WP-Cron on the system cron: scheduled events run every 5 minutes even without visits.
• Debug mode: errors go to wp-content/debug.log (never shown to visitors); the last 200 lines can be read from the panel.
• Maintenance mode: visitors see a notice while you work.
• Stop managing: the site stays as it is, the panel removes cache, Redis, protections and cron.

Import

Import an existing site brings a WordPress from another host into an empty site: upload the files archive (.zip, .tar.gz or .tar) and the database dump (.sql). The panel extracts the archive and imports the database as the site user (never as root), creates the database, updates wp-config.php keeping the table prefix, rewrites the old address with the new one and turns on cache and protections. File size follows the upload limit of the file manager. Direct import from another server over SFTP/SSH will come in a future version.