WordPress

WordPress is an open source content management system that runs on PHP and a MySQL or MariaDB database under the GPLv2 licence. It is a server side application, and the project documentation recommends PHP 8.3 or newer, MariaDB 10.11 or MySQL 8.0 or newer, HTTPS support, and Apache or nginx as the web server.

An installation consists of a few distinct parts: the core files, the wp-content directory, wp-config.php and the database. The theme provides the presentation, plugins provide the functionality, and content is edited in the block editor, which is itself built on the REST API.

Core, themes, plugins

A theme is either a classic theme built on PHP, JavaScript and CSS, or a block theme made mostly of HTML and a theme configuration file. Plugins attach to the core through hooks and filters, so a plugin does not only add a feature: its code also adds to the attack surface.

• Plugins and themes are best taken from the WordPress.org directory or a well known source; the documentation notes that packages from untrusted sources can compromise a site.
• Shortcodes and blocks are assembled at runtime in PHP, so the rendered output always depends on the installation and the active plugins.
• Under Docker the same layer appears in a container, but the database and uploads still need separate handling.

The REST API

The REST API exposes site data as JSON objects, with endpoints for posts, pages, taxonomies and the other built in content types. Access restrictions match the site itself: content that is public is generally publicly accessible through the API, while private or password protected content requires authentication. Any language that can send an HTTP request and interpret JSON can use it, and list endpoints are paginated, so a larger archive can be read out in full.

• Our own migration worked this way: we pulled 31 posts out of the old installation over the REST API.
• The same layer serves the block editor and modern admin interfaces, so it is part of the core.
• The JSON carries no presentation: templates, shortcodes and plugin fields must be resolved again.

Moving to a static build

• Content: beyond posts and pages, categories, tags and the media library come across, and internal links must point at the new paths.
• Redirects: every old URL needs a permanent redirect to its new address, otherwise the links accumulated in search engines are lost.
• Plugin dependency: shortcodes and custom post types do not run on a static site, so they have to be replaced at build time.
• Operations: a WordPress installation needs PHP, a database, version updates and backups; a static build takes that layer out of production serving, behind Astro and nginx.

Maintenance and security

The documentation is direct about priorities: the most important thing for WordPress security is to keep WordPress itself and every installed plugin and theme up to date.

• Since WordPress 3.7 most installations apply minor and security releases automatically in the background, while major releases still need a click.
• A manual upgrade requires a backup of the database and of all files, and plugins are deactivated first; wp-config.php, wp-content and a customised .htaccess must not be deleted.
• The server and the network are the host’s responsibility, while the application, the plugins and the permissions are the operator’s.
• Hardening is about reducing risk: narrowing access, keeping backups and knowing the state of the installation.

Further reading

• WordPress documentation
• REST API Handbook
• Hardening WordPress

At CyberElectro WordPress is not a theoretical tool: this platform is what we migrated the site off, and the content read out through the REST API is what we carry forward.