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.

Protections

Every protection has its own switch:

• Limited login attempts: at most 10 attempts per minute per address on wp-login.php;
• Blocking of persistent attacks: fail2ban blocks for an hour whoever insists on the login 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.

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

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 answer 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 logged 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.