WordPress is software that powers a remarkable share of the web. As of 2026, WordPress powers roughly 43% of all websites, making it the most widely used CMS on the web.

For developers, WordPress is not just a tool for building blogs. It is a PHP application with a mature API surface, a large ecosystem of plugins and themes, and growing support for modern JavaScript development through the block editor. Understanding what WordPress is and how it works is the first step to building on it productively.

This article covers:

  • What WordPress is at a technical level
  • The WordPress.org vs WordPress.com distinction
  • How WordPress is structured as a platform
  • When WordPress is and is not the right choice

What WordPress Is

WordPress is an open-source content management system (CMS) written in PHP. It stores all content — posts, pages, settings, and more — in a MySQL database. When someone requests a page on your site, WordPress queries the database, applies your theme, and returns HTML.

As a developer, it helps to think of WordPress in layers:

The application layer is WordPress core — the PHP code that handles routing, querying the database, loading themes and plugins, and rendering output.

The data layer is a MySQL database with a standardised schema. A standard single-site installation ships with a set of core database tables that store posts, users, comments, options, taxonomies, and related metadata.

The extension layer is the theme and plugin system. Themes control how your content looks. Plugins add new functionality. Both hook into WordPress through a system of actions and filters.

The editor layer is the block editor (Gutenberg), which is now the primary editing interface. It lets editors build pages visually using blocks — structured units of content like paragraphs, images, buttons, and custom components you build yourself.

WordPress started as a blogging platform in 2003. Today it powers news sites, e-commerce stores, membership sites, portfolios, SaaS marketing pages, and headless applications. The platform has grown well beyond its blogging origins.

WordPress.org vs WordPress.com: A Distinction Every Developer Must Know

This is the single most confusing thing for people new to WordPress. The names look almost identical, but they refer to fundamentally different things.

WordPress.org

WordPress.org is the home of the open-source WordPress software. You download WordPress for free from WordPress.org and install it on any server that runs PHP and MySQL.

When developers say “WordPress”, they almost always mean this version — self-hosted, fully customisable, with no restrictions on what you install.

With WordPress.org:

  • You own the database
  • You control the server
  • You can install any plugin from the WordPress.org directory, from a third party, or from your own code
  • You can modify the core files (though you should not)
  • You manage your own updates, backups, and security

This is the version used by agencies, freelancers, and anyone building client sites or custom applications.

WordPress.com

WordPress.com is a commercial hosting service owned by Automattic — the company founded by one of WordPress’s original creators. It runs on the same open-source software, but Automattic manages the server infrastructure for you.

With WordPress.com:

  • Automattic handles hosting, updates, and backups
  • Plans range from a free tier up to paid plans
  • Plugin installation is available on paid plans
  • WordPress.com remains a managed platform, so some server-level customisation options available on self-hosted WordPress are not available

WordPress.com works for users who want a managed experience without server responsibility. For developers building custom sites or products, self-hosted WordPress.org gives the most control.

The rule of thumb: if you are building for a client or developing a theme or plugin, you are almost always working with self-hosted WordPress.org software.

How WordPress Loads a Page

Understanding a rough outline of how WordPress handles a request helps you make sense of everything else in the platform.

When a visitor requests a URL on a WordPress site:

  1. The web server (Apache or Nginx) routes the request to index.php
  2. WordPress loads its configuration from wp-config.php
  3. WordPress parses the URL to determine what content is being requested — a post, a page, an archive, and so on
  4. WordPress runs a database query via WP_Query to fetch the relevant content
  5. WordPress loads the active theme and finds the correct template file using the template hierarchy
  6. The template renders HTML using template tags and the Loop
  7. The rendered page is sent back to the browser

Hooks fire throughout this process. Plugins and themes use actions and filters to modify behaviour at specific points — before the query runs, after content is fetched, before output is sent. This hook-based architecture is central to how WordPress is extended. You will encounter it constantly as a WordPress developer.

Themes and Plugins: How WordPress Is Extended

Themes

A theme controls the visual presentation of your site. It defines templates for different page types — the home page, single posts, archive pages, search results, and more. It also enqueues CSS and JavaScript, registers navigation menus, and optionally sets up widget areas.

WordPress uses a template hierarchy to decide which template file to load for a given request. If you are viewing a single post, WordPress looks for single.php. If that does not exist, it falls back to index.php. This hierarchy gives you granular control over templates without requiring you to define every possible case.

There are two types of themes:

Classic themes use PHP template files. They are the traditional way of building WordPress themes, well-supported, widely understood, and still actively used.

Block themes are the modern approach, introduced alongside Full Site Editing. Instead of PHP templates, block themes use HTML template files built from blocks. They support the Site Editor — a visual interface for editing templates, headers, footers, and global styles.

Plugins

A plugin is PHP code — and often JavaScript and CSS — that adds functionality to WordPress without modifying core files. Plugins can do almost anything: add a contact form, create an e-commerce store, add custom post types, extend the block editor, or expose a REST API.

The WordPress plugin directory at WordPress.org lists tens of thousands of free plugins. There are also thousands of premium plugins available commercially.

Plugins hook into WordPress using actions and filters — the same system the core uses internally. This makes the platform highly extensible without touching core code.

The Hook System

The hook system is how WordPress connects everything. There are two types of hooks:

Actions let you run code at specific points in the WordPress execution process. For example, the wp_enqueue_scripts action is where you load your CSS and JavaScript.

Filters let you modify data before it is used. For example, the the_content filter lets you transform post content before it is displayed.

You will use both constantly. They are covered in depth in the Hooks and Filters cluster of this guide.

The Block Editor and Full Site Editing

The block editor, introduced in WordPress 5.0, replaced the classic TinyMCE editor as the default content editing interface. It lets editors compose content using blocks — structured pieces of content like paragraphs, images, headings, columns, and custom blocks you create yourself.

For developers, the block editor is a React application. Custom blocks are typically built with JavaScript (React and JSX), registered through a block.json metadata file, and may be rendered either client-side or server-side using PHP for dynamic output.

It helps to separate two files that are easy to confuse. block.json defines and registers an individual block. theme.json configures global editor settings for a theme — styles, spacing, typography, colours, and block supports — but it does not register blocks.

Full Site Editing (FSE) extends the block editor beyond content to cover templates, template parts, and global styles. With a block theme and FSE, everything on the site — header, footer, sidebar, page templates — is editable through the block editor.

This is a significant shift from classic theme development. The block editor and FSE are where WordPress development is heading, and they are covered in depth in the Gutenberg and Block Themes clusters of this guide.

WordPress as a Platform

WordPress is not just a blog tool.

WooCommerce extends WordPress into a full e-commerce platform. Built as a plugin, it adds product management, cart, checkout, payment processing, and order management on top of WordPress, and it powers a large share of online stores worldwide.

The REST API exposes WordPress content as JSON. This makes it possible to consume WordPress data from any frontend — React, Vue, a mobile app, or a third-party system. It also makes WordPress a viable backend for headless applications.

Custom post types let you model arbitrary content beyond posts and pages. A real estate site might have a property post type. A recipe site might have a recipe post type. These integrate with the admin, the query system, the REST API, and templates automatically.

These capabilities mean WordPress works well beyond its original use case. Whether you are building a content site, an e-commerce store, or a decoupled application, WordPress has mature support for it.

Headless WordPress

WordPress can run as a headless CMS. In a headless setup, WordPress manages and stores the content, but a separate application handles how that content is displayed.

The REST API exposes WordPress content as structured data that an external frontend can consume (a GraphQL layer is also available through a plugin if you prefer that query style).

Modern frameworks such as React, Next.js, Nuxt, and Astro — as well as native mobile applications — commonly consume WordPress content this way.

In this model, WordPress is the content layer while another framework handles presentation. This suits teams that want WordPress’s editing experience paired with a custom or highly interactive frontend.

The trade-off is real. Going headless means giving up WordPress’s themes, the front-end page building of the block editor, and the many plugins that output HTML directly — in exchange for full control of the frontend. Choose it when the frontend experience justifies rebuilding what a standard WordPress theme would give you for free; otherwise, traditional WordPress is usually the faster path.

WordPress Security in Practice

WordPress core has a strong security track record. The core software is actively maintained, and serious vulnerabilities in core itself are relatively uncommon.

Most WordPress security problems do not originate in core. They come from outdated, abandoned, or poorly maintained plugins and themes. The third-party code you add is where most of the real risk lives.

A few practical habits keep a WordPress site secure from day one:

  • Keep plugins and themes updated. Many exploited vulnerabilities already have a fix available that was simply never applied.
  • Remove plugins and themes you do not use. Inactive code can still be exploited, so delete what you are not running rather than just deactivating it.
  • Follow the principle of least privilege. Give each user the minimum role and capabilities they need to do their job, and no more.

Security is covered in depth in its own cluster later in this guide, but these habits matter from the very first project.

When to Use WordPress (and When Not To)

Understanding the trade-offs helps you make better decisions about when to reach for WordPress.

WordPress works well for:

  • Content-heavy websites where editors need a user-friendly admin
  • Sites that benefit from a plugin ecosystem — forms, SEO, e-commerce, membership
  • Client projects where the client will manage content themselves
  • Sites that may grow and need extensibility over time
  • E-commerce with WooCommerce

WordPress may not be the right choice for:

  • Highly interactive single-page applications (a dedicated React or Next.js app is often a better fit)
  • Very simple static sites that do not need a database or CMS
  • Environments where PHP is not available or not preferred
  • Applications with highly custom data models that do not map well to WordPress content structure

The key question is: does the project benefit from a CMS with a content editing interface and a plugin ecosystem? If yes, WordPress is worth considering seriously.

Best Practices

A few principles that apply from your very first WordPress project:

Always use the self-hosted version for development work. WordPress.org gives you full control. Most custom WordPress development work is done on self-hosted WordPress.org installations rather than WordPress.com.

Build through hooks, child themes, and plugins. Make this your default way of working: add and change functionality through WordPress’s extension points rather than editing core, so your code stays clean and survives every update.

Understand the hook system early. Actions and filters are how everything in WordPress is extended and customised. The sooner you understand them, the faster you will move.

Use a local development environment. Build and test on your own machine before touching anything live. The modern approach uses Docker with wp-env, though desktop apps like Local also work — both are covered in the next articles in this series.

Common Mistakes

Confusing WordPress.org and WordPress.com. Clients and beginners do this constantly. Be explicit when discussing which one you mean — especially with clients.

Editing core files directly. Any change you make to WordPress core is lost on the next update. Always use hooks, child themes, or plugins instead.

Installing too many plugins. Each plugin is additional code running on every request. More plugins means more maintenance, more potential conflicts, and more attack surface. Install plugins deliberately.

Treating WordPress as just a blog tool. Developers who write off WordPress because it started as a blogging platform miss how much the ecosystem has matured. WooCommerce, the REST API, the block editor, and FSE make it a serious platform for many project types.

Not using version control. WordPress projects should be in Git like any other codebase. Themes, plugins, and configuration all benefit from version control.

FAQ

What language is WordPress written in?

WordPress is primarily written in PHP. The block editor and other modern features are written in JavaScript (React). Themes and plugins use PHP, JavaScript, CSS, and HTML.

What database does WordPress use?

WordPress uses MySQL or MariaDB. The database stores all content — posts, pages, users, settings, and more.

Is WordPress free?

The WordPress software from WordPress.org is free and open-source under the GPL licence. You pay for hosting, premium themes, and premium plugins you choose to purchase. WordPress.com offers both free and paid hosting plans.

What is the block editor?

The block editor (also called Gutenberg) is the modern editing interface for WordPress, introduced in WordPress 5.0. Content is built from blocks, and the editor is built on React.

Do I need to know how to code to use WordPress?

No. You can build and run a WordPress site with themes and plugins without writing any code, which is why non-developers use it every day. Knowing PHP, JavaScript, and CSS is what lets you go further — building custom themes, plugins, and blocks instead of relying only on what already exists. This guide is written for that second path.

Conclusion

WordPress is an open-source CMS built in PHP, backed by MySQL, and extended through themes, plugins, and hooks. It powers roughly 43% of the web and supports everything from simple blogs to large e-commerce stores and headless applications.

The most important things to carry into the rest of this series:

  • WordPress.org is the software you install and host yourself. That is what you will use as a developer.
  • WordPress.com is a managed hosting service; most custom development work happens on self-hosted WordPress.org instead.
  • WordPress extends through hooks, themes, and plugins — never by modifying core files.
  • The block editor and Full Site Editing are where modern WordPress development is heading.

The next article in this series covers every common WordPress installation method — manual, one-click, and local — so you can get a development environment running.