# WordPress ## What it is WordPress is an open-source content management system: PHP software that keeps a site's posts, pages, media, users and settings in a MySQL or MariaDB database and assembles each page from them when someone asks for it. Its name is often shortened to WP, the same prefix its own files and folders carry (wp-config.php, wp-content, wp-admin). It is released under the GPLv2 (or later), so the software costs nothing to download, run or change. Three layers make up a WordPress site. Core is the shared code that everyone downloads and updates. A theme controls presentation and plugins add behaviour, which is where the project's own theme handbook draws the line. Both reach into core through hooks, named points in the WordPress code where other code is allowed to run, and hooks come as actions and filters. An action runs at a moment, such as a post being saved, and returns nothing. A filter receives a value, changes it and hands it back. This one shortens automatic post excerpts from the default 55 words to 30: ```php add_filter( 'excerpt_length', function ( $length ) { return 30; } ); ``` Themes have changed shape over the years. Classic themes use the PHP template system that arrived with WordPress 1.5 in 2005, and they are still in wide use. Block themes are the current approach: their templates are HTML files built from blocks, editable in the Site Editor, with colours, fonts and spacing held in a theme.json file. Hybrid themes are classic themes that have taken on some of the block features. Content also leaves the site as JSON through the REST API, which the block editor itself is built on. A request to the site's /wp-json/ address returns a map of every route it offers, public content is readable without signing in, and anything private needs authentication. Any program can fetch the three latest posts like this: ```sh curl -s 'https://example.com/wp-json/wp/v2/posts?per_page=3' ``` To run it, the project recommends PHP 8.3 or greater, MySQL 8.0 or MariaDB 10.11 or greater, and HTTPS, preferably on Apache or Nginx. Joomla and Drupal are content management systems of the same kind, and the two other routes to weigh it against are a custom application on a framework such as Django and a static site generator. ## Why it matters The real decision behind WordPress is who changes the site after launch, and who keeps it safe while they do. WordPress hands non-technical staff a complete editor: they can publish a page, swap an image, add a user or rework a menu without opening a ticket. On a site that changes every week, the cheapest edit is the one that needs no developer. The licence is free, but the site is not. The GPL covers the software, and wordpress.org takes the view that plugins and themes are derivative works that inherit the same licence. The spending moves elsewhere: hosting that runs PHP and a database, the hours to choose, set up and test a theme, and the ongoing work of keeping core, plugins, themes and the PHP version current. That last cost runs for the life of the site, and a quote should name who carries it. The upkeep follows from WordPress being a live application. Every visit runs PHP against a database, every plugin is third-party code running with the same access as core, and the login screen sits on the open internet unless someone puts a second lock in front of it. Most sites install minor and security releases in the background, as WordPress has allowed since version 3.7, while a major release waits for someone to press Update Now and the server's PHP keeps a schedule of its own. A custom build fits data and workflows that look nothing like pages and posts, and it usually needs a developer for every change. A static build leaves nothing to patch at request time, and its editors usually work through files and a build step. WordPress fits the wide middle: a fairly standard site that its owners will run themselves, where the editing screens are worth the upkeep they bring. Lock-in stays modest, because the code is GPL, the content sits in an ordinary SQL database, and the REST API serves posts, pages and taxonomies as JSON. ## What it looks like in practice In this company's work WordPress is one answer among several, picked on purpose. [The write-up of a hundred web applications](/portfolio/developed-100-web-applications-using-html-html5-css-51/) covers 2003–2014 and states the rule behind the choice. When a client needed something custom, the build was HTML/HTML5, CSS/SCSS and Django. When a client needed a more standard site that they could also look after themselves, WordPress or Joomla got there sooner and made more sense. What that write-up values is the judgement, not the tool. Part of the work it describes was telling the two cases apart: talking a client out of a bespoke build they did not need, and into one when the need was real. Put as questions a buyer can answer before asking for any quote, the judgement looks like this: - Will people without a developer edit the site every week, or will it change a few times a year? - Does the content fit pages, posts, categories and media, or does it need its own data model and rules? - Who will keep core, plugins and PHP current for as long as the site is live? - Will the site lean on a handful of well-kept plugins, or on dozens of them stitched together to imitate an application? Weekly edits, content that fits, a named maintainer and a short plugin list point to WordPress or a CMS like it. Unusual data, or nobody to keep it current, points to a custom build or a static one. ## Where it goes wrong ### A routine update breaks the site Someone updates a plugin, and a page starts showing an error or the dashboard refuses to load. The site had gathered plugins for years, some of them abandoned by their authors, each one third-party PHP running with full access, and two of them clashed. Keep the list short, and delete every plugin the site has stopped using, as the hardening handbook asks. Take a backup before every update, try major ones on a copy first, and prefer plugins whose authors still ship releases. ### Custom changes vanish after an update or a redesign A tweak that worked for months disappears the day the theme updates, or a feature the business relies on goes missing when the site gets a new look. In the first case someone edited the files of a theme they did not write, and the update replaced them; the theme handbook warns that a function added straight into a theme's functions.php disappears with its next update. In the second, site-critical behaviour lived in the theme, so it left with the theme. Put changes to someone else's theme in a child theme, and put features in a small plugin of your own that hooks into core, so the theme carries presentation and nothing else. ### An admin password turns into code on the server Whoever steals one administrator's password can go from editing posts to running their own PHP, because the dashboard ships with an editor for theme and plugin files. One line in wp-config.php switches that editor off, which has the same effect as removing the edit_themes, edit_plugins and edit_files capabilities from every user: ```php define( 'DISALLOW_FILE_EDIT', true ); ``` It closes one route among several, and the handbook says plainly that it will not stop an attacker who can upload malicious files. Pair it with strong passwords, two-step authentication for every administrator, and as few administrator accounts as the work allows. ### The site falls behind the current release The dashboard shows a new-version banner for months while the site runs a major release, or a PHP version, well behind the current one. By default the background updates apply minor and security releases, while each major release waits for a click, so a site can keep patching itself while its major version and its PHP fall behind, until a plugin it depends on demands something newer. Put major updates on a calendar, check the PHP version against the project's requirements page at the same time, and test both on a copy before the live site. ## Further reading - [WordPress Documentation](https://wordpress.org/documentation/) — the project's manual for running a site, from publishing and media to installing and maintaining it. - [Requirements](https://wordpress.org/about/requirements/) — the PHP, MySQL and MariaDB versions the project recommends today. - [Updating WordPress](https://wordpress.org/documentation/article/updating-wordpress/) — background, one-click and manual updates, with the backup to take first. - [Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/) — file permissions, database privileges, the switch for the file editor and plugin hygiene. - [Plugin Handbook: Hooks](https://developer.wordpress.org/plugins/hooks/) — how actions and filters let code change WordPress without touching core. - [REST API Handbook](https://developer.wordpress.org/rest-api/) — routes, endpoints and authentication for the API the block editor is built on.