# What is WordPress?

WordPress is a free, open-source content management system written in PHP and backed by a MySQL or MariaDB database. You install it on a web server, and it gives you an admin dashboard for writing content, a theme layer that turns that content into HTML, and a plugin system that lets you bolt on almost anything else. It is released under the GPL (version 2 or later), and according to W3Techs it runs 39.5% of all websites and 58.2% of the sites whose CMS is known, as of 1 November 2026.

A quick disclosure before we start: I work on VeloCMS, which shows up as one of several alternatives near the end. The first two-thirds of this piece is about WordPress itself, and I've tried to describe it the way I'd explain it to a colleague who has to maintain a site on it next week.

**Last verified: 2026-11-01.** Version numbers, prices and market share below were checked against the vendors' own pages on that date. Sources are at the bottom.

## What is WordPress, technically?

Strip away the brand and WordPress is a PHP application with a very large public API. The core ships as a folder of PHP files. A `wp-config.php` file holds your database credentials and a few constants. Everything you write (posts, pages, menus, settings, users) lives in database tables, with uploaded files sitting on disk under `wp-content/uploads`.

The data model is smaller than people expect. With the default table prefix, most content is a row in `wp_posts`, whatever its type: a blog post, a page, a menu item, an attachment, a revision. Extra fields hang off it in `wp_postmeta` as key/value pairs. Site-wide settings live in `wp_options`. Users, taxonomies and comments get their own tables. That flexibility is why a "custom post type" costs a few lines of PHP. It is also why queries get ugly once a site has hundreds of thousands of meta rows, because key/value storage is hard to index well.

The current release line is WordPress 7.1 ("Mary Lou", released 19 August 2026), and 7.1.4 shipped on 28 October 2026. The 7.0 line is still being patched too (7.0.8 landed the same day). On requirements, WordPress.org recommends PHP 8.3 or newer and either MySQL 8.0+ or MariaDB 10.11+, with Apache or Nginx as the web server. The documented floor for old environments is PHP 7.4 and MySQL 5.5.5, and the requirements page itself warns that both are end-of-life and may expose you to security problems. Treat the floor as a museum piece, not a target.

One thing worth saying plainly: "WordPress" is also used loosely for the whole ecosystem, meaning the themes, the plugin directory, the agencies, the hosting companies, the conferences. When people say they "know WordPress", they usually mean the ecosystem, and that's a big part of what you're choosing or declining when you pick it.

## What happens when a request hits a WordPress site?

Every public page view goes through the same front controller. Understanding this sequence explains most of the performance and debugging advice you'll ever read.

1. The web server hands the request to `index.php`, which loads `wp-blog-header.php`, which loads `wp-load.php`.
2. `wp-load.php` loads `wp-config.php`, which in turn loads `wp-settings.php`. That file bootstraps the rest: database connection, active plugins, then the active theme's `functions.php`.
3. WordPress parses the URL against its rewrite rules and decides what is being asked for (a single post, an archive, a search, a 404). This is the "main query".
4. The template loader picks a template file from the theme, following a hierarchy (`single-recipe.php` before `single.php` before `singular.php` before `index.php`, for example).
5. The theme template calls functions like `have_posts()` and `the_content()`, and the HTML goes back to the browser.

Along the way WordPress fires hundreds of named hooks (`plugins_loaded`, `init`, `pre_get_posts`, `template_redirect`, `wp_head`, `wp_footer` and so on). That's the whole extension mechanism, and it deserves its own section.

The expensive part is that all of this runs per request, in PHP, with several database queries, unless something upstream short-circuits it. A page cache (at the server, at a CDN, or via a plugin) can skip most of steps 2 to 5 for anonymous visitors. Logged-in users, carts and previews usually bypass the cache, which is why admin screens and WooCommerce stores feel slower than the marketing site next to them.

## How do hooks, themes and plugins fit together?

WordPress extends itself through two kinds of hooks. An **action** says "something is happening, do you want to react?" and the callback returns nothing. A **filter** says "here is a value, change it if you like" and the callback must return the value. The official handbook puts it the same way: an action takes the info it receives, does something with it and returns nothing, while a filter takes the info it receives, modifies it and returns it.

Here is a small plugin-style example that registers a custom post type and shortens excerpts:

```php
<?php
/**
 * Plugin Name: Recipes
 */

add_action( 'init', function () {
    register_post_type( 'recipe', [
        'label'        => 'Recipes',
        'public'       => true,
        'show_in_rest' => true, // exposes /wp-json/wp/v2/recipe
        'supports'     => [ 'title', 'editor', 'thumbnail' ],
    ] );
} );

add_filter( 'excerpt_length', fn() => 30 );
```

`add_action( $hook_name, $callback, $priority = 10, $accepted_args = 1 )` is the full signature. Lower priority numbers run earlier, and callbacks at the same priority run in the order they were registered. That ordering rule is a common cause of "why does my plugin break my other plugin" bugs.

So what is the difference between a theme and a plugin? In principle, a theme controls presentation and a plugin controls behaviour. In practice the line blurs, and the common advice is to put anything that should survive a theme switch (custom post types, shortcodes, business logic) in a plugin, not in `functions.php`. Teams that ignore this learn the lesson when a redesign makes half the content vanish from the front end.

Licensing matters here too. WordPress states that plugins and themes are derivative works and should carry the GPL, which is why the plugin ecosystem is overwhelmingly open source or "GPL with a paid license key". It also means you can read the code of almost anything you install, which is a real advantage when you're debugging a conflict at 11pm.

## What is the block editor, and what are block themes?

Since 5.0 the default editor has been Gutenberg, the block editor. Content is a tree of blocks, but what gets stored is plain HTML in `post_content`, with blocks marked by HTML comments:

```html
<!-- wp:paragraph -->
<p>Hello, world.</p>
<!-- /wp:paragraph -->
```

That storage choice is clever and annoying in equal measure. It means old content survives an editor change, and a block's output can be rendered without JavaScript. It also means "structured content" is something you build deliberately, because the database holds markup rather than clean JSON fields.

Block themes take the idea further. According to the theme handbook, they're built entirely of blocks, with HTML templates containing block markup, and global settings and styles defined in a `theme.json` file. A minimal one looks like this:

```json
{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "ink", "name": "Ink", "color": "#111111" },
        { "slug": "paper", "name": "Paper", "color": "#fafaf7" }
      ]
    }
  }
}
```

Users can then restyle the site through the Site Editor, which edits templates and styles visually. If you're a developer, the practical effect is that design tokens (colours, spacing, typography) are now declarative JSON rather than scattered CSS, and clients can change them without calling you. Whether that's a gift or a support burden depends on your clients.

Classic PHP themes still work, and plenty of production sites run them. The split is real, though, and it's one reason "which WordPress are you using?" is now a legitimate question to ask before you accept a project.

## Can WordPress work as a headless CMS?

Yes. WordPress ships a REST API in core, with posts at `/wp-json/wp/v2/posts`. You can run WordPress purely as a content backend and render the front end with Next.js, Astro, SvelteKit or anything else. Listing posts looks like this:

```bash
curl -s "https://example.com/wp-json/wp/v2/posts?per_page=2&_fields=id,slug,title"
```

Collections are paginated, and the totals come back in the `X-WP-Total` and `X-WP-TotalPages` response headers. `per_page` is capped at 100 records. To write, you send a POST to the same collection with credentials from an Application Password, using HTTP Basic auth over HTTPS:

```bash
curl --user "editor:abcd efgh ijkl mnop qrst uvwx" \
  -X POST https://example.com/wp-json/wp/v2/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"Hello from curl","status":"draft"}'
```

(Application Passwords are only enabled by default on HTTPS sites, since Basic auth over plain HTTP leaks the password.)

The honest trade-offs of headless WordPress: you keep a familiar editor and a huge plugin catalogue, but you now run two systems. Previews, menus, shortcodes, page-builder output and SEO plugin metadata all need explicit handling in your front end. Plugins that inject markup into `wp_head` or `the_content` often assume WordPress is rendering the page, and they quietly stop working when it isn't. The risk is that a "headless" project spends more time re-implementing what the theme layer gave it for free than it saves in front-end performance.

## What is the difference between WordPress.org and WordPress.com?

Same software lineage, completely different deal.

- **WordPress.org:** the open-source project and the download. You pick a host, install it, and own everything: PHP version, plugins, backups, security, updates. Support is forums, your host and whoever you hire.
- **WordPress.com:** a hosted service run by Automattic, a commercial company. They run the servers, the updates and the backups, and you pay a subscription. WordPress.com's own comparison page says complex custom code changes "may or may not be possible" there, and that it proactively blocks potentially risky plugins.

WordPress.com's pricing page (checked 1 November 2026, US dollars) lists these plans:

- **Free:** $0. A WordPress.com subdomain, 1 GB storage, ads shown to visitors, no custom domain and no plugin installation.
- **Personal:** $4/month billed yearly, or $9 paying monthly. 6 GB storage, plugin installation, no ads.
- **Premium:** $8/month billed yearly, or $18 monthly. 13 GB storage, accepting payments, video uploads.
- **Business:** $25/month billed yearly, or $40 monthly. 50 GB storage, SFTP/SSH, WP-CLI, Git deployments, real-time backups.
- **Commerce:** $45/month billed yearly, or $70 monthly. The Business feature set plus unlimited products and selling in 60+ countries.
- **Enterprise (WP VIP):** custom pricing, not listed.

The page also lists a share taken from paid subscriptions and payments (on top of Stripe's own processing fee): 10% on Free, 8% on Personal, 4% on Premium, 2% on Business and 0% on Commerce. If you plan to sell anything, read that line before you pick a tier.

For developers the key point is the Business tier: that's where shell-level access (SSH, WP-CLI, Git) shows up. Below it, WordPress.com behaves like a managed website builder, and even on Business it isn't the place for bespoke server configuration.

## What does running WordPress actually involve?

Software that powers four in ten sites is a target, and the maintenance load follows from that. Here's the realistic list for a self-hosted site.

- **Core updates:** minor (maintenance and security) releases update automatically by default. Major releases are not automatic on existing sites unless you enable them, and fresh installs since 5.6 take them by default unless a version-control checkout is detected, so someone still has to decide how to test the result.
- **Plugin and theme updates:** these aren't updated automatically in general, though since 5.5 administrators can opt in to auto-updates plugin by plugin and theme by theme. An outdated or abandoned plugin is the usual weak point, because it's third-party code running with full access to your site.
- **Backups:** your host may offer them, but you want your own, with a tested restore.
- **Caching:** a page cache, an object cache (Redis or Memcached) for busy sites, and a CDN in front. This is a stack you assemble, and each layer has invalidation rules to learn.
- **PHP upgrades:** moving to a current PHP version regularly breaks old plugins. Staging environments exist for this reason.

WP-CLI is the command-line tool that makes all of this scriptable, and for a developer it's the most tolerable way to work with WordPress. A typical session:

```bash
wp core download
wp config create --dbname=wp --dbuser=wp --dbpass=secret
wp core install --url=https://example.test --title="Demo" \
  --admin_user=ada --admin_password='change-me' --admin_email=ada@example.test

wp plugin list --update=available
wp plugin update --all
wp db export backup.sql
wp search-replace 'https://staging.example.com' 'https://example.com' --all-tables
```

The `search-replace` command in particular is the safe way to move a database between domains, because WordPress stores serialized PHP data that a naive `sed` would corrupt.

Multisite deserves a mention as well. It lets you run several WordPress sites from one installation: each site's content gets its own tables, while the user table is shared. For a developer it means one codebase to patch, and also one shared blast radius.

## Where does WordPress shine, and where does it hurt?

It shines when the requirement is "a content site that non-developers can edit, with whatever features we need, soon". The plugin directory is described by WordPress.org as the largest directory of free and open source WordPress plugins, and for most feature requests (forms, SEO, memberships, bookings, multilingual) somebody has already built a version. Given its market share, finding developers and agencies who know it is usually easier than for smaller platforms, and hosting is a commodity.

It hurts in a handful of predictable places:

- **Plugin quality varies wildly.** Two plugins that each work alone can collide on hooks, scripts or database tables, and nobody is accountable for the combination.
- **Performance is something you build.** A fresh install is fine. A site with a page builder, twenty plugins and a slow host is not, and the fix is rarely one setting.
- **Security is a standing task.** You're patching constantly, because known-vulnerable plugin versions are an obvious target for attackers.
- **Two editing worlds.** Classic themes, block themes and page builders each want different skills, and a project can inherit all three.
- **Content as markup.** If you want clean structured data for an app or an API, you'll fight the HTML-in-the-database model.

None of that makes it a bad tool. It makes it a tool whose total cost lives mostly in operations rather than in the initial build, and that's easy to miss when the install takes five minutes.

## When should a developer pick something else?

I'd steer away from WordPress when:

- You're writing a blog or docs site yourself, in Markdown, and don't need a browser editor. A static generator is simpler, faster and has nothing to patch.
- You need strongly typed, structured content shared across several front ends. A headless CMS built for that will serve you better than retrofitting custom fields.
- Nobody on the team wants to own PHP hosting, updates and plugin vetting, and the budget doesn't cover someone who does.
- Your content team is one person who just wants to write and send a newsletter.
- You need a specific application (a SaaS dashboard, say) with a bit of content on the side. A framework plus a content layer fits better.

Conversely, pick it when you need the plugin catalogue, the hiring pool, or the editor familiarity, and you have a plan for the upkeep.

## What are the alternatives if WordPress isn't the right fit?

There's no single replacement, because "WordPress" covers several different jobs. Here are the options I'd put on a shortlist, with the trade-offs on each. Prices are from each vendor's own page on 1 November 2026.

**Ghost.** An open-source publishing platform (MIT license, Node.js) focused on writing, memberships and paid newsletters. You can self-host it or use the managed Ghost(Pro) service, whose Starter plan is listed at $18/month billed yearly for 1 staff user and 1,000 members, with Publisher at $29/month for 3 staff users. It's a focused, fast product with a clean writing experience. The trade-off is scope: it's built around publishing, so you get a much smaller extension story than WordPress and no general-purpose plugin catalogue. Official site: [ghost.org](https://ghost.org/pricing/).

**A static site generator (Astro or Hugo).** Astro is a web framework for content-driven sites that lists "Zero JS, by default" as a highlight and uses islands for interactive parts, with content collections that give your Markdown TypeScript type-safety. Hugo is an open-source generator written in Go under the Apache 2.0 license, known for very quick builds. Both are free, cheap to host and have no admin panel to attack. The cost is that editing means Git and Markdown, so non-technical collaborators need a separate editing layer, and anything dynamic (comments, search, forms) is something you wire up yourself. See [Astro](https://docs.astro.build/en/concepts/why-astro/) and [Hugo](https://gohugo.io/).

**A headless CMS (Payload, Strapi or Sanity).** These give editors a dashboard and developers an API, with your own front end on top. Payload is MIT-licensed and describes itself as a Next.js-native CMS that installs into your existing `/app` folder. Strapi's Community edition is free and MIT-licensed, with a self-hosted Growth plan at $45/month that includes 3 users. Sanity has a $0 plan (up to 20 seats, 2 public datasets, 250,000 API requests a month) and a Growth plan at $15 per seat per month. You get typed, structured content, which is a genuine upgrade over HTML blobs. What you give up is the out-of-the-box website: you build and host the front end, handle previews, and run or pay for more moving parts. See [Payload](https://github.com/payloadcms/payload), [Strapi](https://strapi.io/pricing-self-hosted) and [Sanity](https://www.sanity.io/pricing).

**A hosted builder (Wix or Squarespace).** Nothing to install, nothing to patch, visual editing from day one. Wix lists a free plan alongside its paid premium plans, while Squarespace has no free plan but starts every site with a 14-day free trial. Paid tiers on both are subscriptions, and prices are shown localized (sometimes with local taxes included), so check your own region. The compromise is control: you can't read or modify the server code, themes and data are tied to the platform, and moving a large site out later can be a manual job. They're a sensible choice for a small business site and a frustrating one for a developer who wants to go off the rails. See [Wix](https://www.wix.com/plans) and [Squarespace](https://www.squarespace.com/pricing).

**VeloCMS.** This is the one I work on, so weigh my description accordingly. It's a hosted, headless blog CMS built on Next.js and PocketBase, with an editor, themes and a public blog in one product. Plans are Pro at $9/month, Business at $29/month and Agency at $69/month, with a 14-day trial (a card is required to start it unless you have a trial code) and no free plan, and it charges a 0% VeloCMS platform fee on Stripe sales. The weaknesses are real: it's a young product, it's hosted only for now (no self-hosting), its ecosystem is small, and its plugin and theme marketplace is nowhere near WordPress scale. If you need a specific integration that already exists as a WordPress plugin, you'll probably find it there first. See [velocms.org/pricing](https://velocms.org/pricing).

## Who is each option best for?

- **WordPress:** best for teams that want the biggest plugin and talent pool, are comfortable owning updates and hosting, and need flexible content types without writing a backend.
- **WordPress.com:** best for people who want WordPress's editor without running servers, and who can live within the plan limits.
- **Ghost:** best for writers and publishers whose business is the newsletter or membership, and who don't need a store or a long tail of plugins.
- **Astro or Hugo:** best for developers who write in Markdown, want minimal attack surface and top-tier speed, and have no non-technical editors to support.
- **Payload, Strapi or Sanity:** best for teams building a custom front end who need structured content and are happy to maintain it.
- **Wix or Squarespace:** best for small businesses that want a finished site with no technical upkeep.
- **VeloCMS:** best for bloggers and small teams who want a hosted writing and publishing setup without running PHP, and who don't depend on a large third-party plugin ecosystem.

## When is VeloCMS the wrong pick?

If you need self-hosting, VeloCMS isn't an option today. If you rely on a particular WordPress plugin, a bespoke integration, or an agency's existing WordPress workflow, the migration cost will outweigh whatever you'd save. And if you want the widest talent pool and community answers on every question, WordPress wins by a distance. I'd rather you pick the tool that matches your constraints than the one I happen to work on.

## FAQ

**Is WordPress free?**
The software is free and open source under GPLv2 or later. You pay for hosting, a domain, premium themes or plugins if you want them, and your time. WordPress.com has a free plan, but it shows ads, uses a WordPress.com subdomain and doesn't allow plugins.

**What do I need to run WordPress myself?**
A web server (Apache or Nginx), PHP 8.3 or newer, and MySQL 8.0+ or MariaDB 10.11+ are the recommended baseline. HTTPS is also on the list of recommended host features.

**Is WordPress a CMS or a website builder?**
It's a CMS. Page builders and the block editor layer visual building on top of it, but the core is a content management system with a theme and plugin architecture.

**Can WordPress be used headless?**
Yes. The REST API ships in core (for example `/wp-json/wp/v2/posts`), and you can render the front end with any framework. Expect extra work for previews, menus and plugin-generated markup.

**What is the difference between WordPress.org and WordPress.com?**
.org is the downloadable open-source software you host yourself. .com is Automattic's managed hosting service, with plans from free to Commerce and a custom Enterprise tier.

**Does WordPress update itself?**
Minor core releases (maintenance and security) do by default. Major releases are not automatic on existing sites unless you enable them, and plugins and themes need to be updated (or have auto-updates switched on) separately.

**Is WordPress still a good choice in 2026?**
For many content sites, yes. It's actively developed (7.1.4 shipped on 28 October 2026) and has the largest ecosystem. Whether it's the best choice depends on how much maintenance you can take on and whether you need structured content or a very small attack surface.

## Sources

All accessed 2026-11-01.

- [WordPress.org: Requirements](https://wordpress.org/about/requirements/)
- [WordPress.org: Releases](https://wordpress.org/download/releases/) and [release news](https://wordpress.org/news/category/releases/)
- [WordPress.org: License](https://wordpress.org/about/license/)
- [WordPress.org: Plugin directory](https://wordpress.org/plugins/)
- [Developer Resources: WP-CLI commands](https://developer.wordpress.org/cli/commands/)
- [W3Techs: WordPress usage statistics](https://w3techs.com/technologies/details/cm-wordpress)
- [WordPress.com: Pricing](https://wordpress.com/pricing/)
- [WordPress.com: .com vs .org](https://wordpress.com/support/com-vs-org/)
- [Developer Resources: Hooks](https://developer.wordpress.org/plugins/hooks/)
- [Developer Resources: add_action()](https://developer.wordpress.org/reference/functions/add_action/)
- [Developer Resources: Block editor handbook](https://developer.wordpress.org/block-editor/)
- [Developer Resources: Block themes](https://developer.wordpress.org/themes/block-themes/)
- [Developer Resources: REST API, posts](https://developer.wordpress.org/rest-api/reference/posts/)
- [Developer Resources: REST API pagination](https://developer.wordpress.org/rest-api/using-the-rest-api/pagination/)
- [Make WordPress Core: Application Passwords integration guide](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/)
- [Developer Resources: Multisite](https://developer.wordpress.org/advanced-administration/multisite/)
- [Developer Resources: Upgrading and automatic updates](https://developer.wordpress.org/advanced-administration/upgrade/upgrading/)
- [Ghost: Pricing](https://ghost.org/pricing/) and [Ghost on GitHub](https://github.com/TryGhost/Ghost)
- [Astro: Why Astro](https://docs.astro.build/en/concepts/why-astro/)
- [Hugo](https://gohugo.io/)
- [Payload on GitHub](https://github.com/payloadcms/payload)
- [Strapi: Pricing](https://strapi.io/pricing-self-hosted)
- [Sanity: Pricing](https://www.sanity.io/pricing)
- [Wix: Plans](https://www.wix.com/plans)
- [Squarespace: Pricing](https://www.squarespace.com/pricing)
- [VeloCMS: Pricing](https://velocms.org/pricing)