WordPress is a Factory: A Technical Introduction
Thinking “WordPress is a factory” is our analogy which has helped thousands of people “click” when learning WordPress development. We first used this analogy in 2015 as the first chapter of our “learn WordPress development” course Up and Running. We had such a good response that we wanted to share it more widely.
The analogy of “WordPress is a factory” works because it’s the easiest way to understand what WordPress does, and how it does it. Phrased differently, WordPress is a factory that makes webpages.
Here’s how the factory analogy breaks down:
- The WordPress factory’s raw materials are its posts, and its warehouse (where it stores its raw materials) is the MySQL database.
- The easiest way to understand what WordPress does, and how it does it, is to dig into the following analogy: WordPress is a factory that makes webpages.
- The factory’s assembly lines are the various PHP template files of the WordPress theme.
- The factory can call on specialized outside contractors for specific jobs; these are WordPress plugins.
- The finished product is the full HTML markup necessary to display a webpage; the factory ships this product to the requesting user’s browser on every page load.
This very quickly gives you an intuitive picture of how WordPress works!
As mentioned, this analogy originally comes from our excellent course on WordPress development Up and Running, which we heartily recommend for anyone looking to truly learn WordPress development in the shortest possible time.
Serious About Learning WordPress Development?Up and Running is our complete “learn WordPress development” course. Now in its updated and expanded Third Edition for 2018, it’s helped hundreds of happy buyers learn WordPress development the fast, smart, and thorough way.
Here’s what they have to say:
“Other courses I’ve tried nearly always lack clear explanations for why WordPress does things a certain way, or how things work together. Up and Running does all of this, and everything is explained clearly and in easy-to-understand language.” -Caroline, WordPress freelancer
This post itself is part of our simplified free WordPress development course. You’ll find quick links to the rest of the content below, and then the famed analogy after. Please enjoy 🙂
This is our free WordPress development course! Start with this post, and then continue your WordPress development journey with the links below:
- Introduction: Learn WordPress development
- WordPress is a Factory: A Technical Introduction
- The Four Programming Languages You Must Know To Understand WordPress.
- Local WordPress Development: A Rundown of the Options
- Becoming A Freelance WordPress Developer: How to Make a Career of It
- Ready to get to the next level? Take our excellent course on WordPress development, Up and Running.
WordPress is a Factory
WordPress is a factory that makes webpages.
WordPress is a factory that makes webpages. More specifically, it processes one or more WordPress posts stored in your database into the webpage your browser sees when you visit a URL (like
Let’s break this down into some very important key terms. We’ll first be looking at the general environment in which the WordPress “webpage factory” operates, and then at the specific technical makeup of the factory itself.
The Overall Factory Environment
This section describes general relationships between the browser and web server.
In this section, we’ll look at the key entities that either make up or interact with a WordPress site: entities such as the user, browser, and server. This section establishes general relationships, to give you a basic understanding of “What does WordPress do, for whom, and why?”
Browser: The Consumer
Factories run with a consumer in mind. For a WordPress site, that consumer is a (human running a) web browser.
The browser doesn’t really want to know what goes on at the factory; it wouldn’t understand very much of that. Most of a WordPress site’s server processing is in PHP, and browsers don’t “speak” PHP at all.
Rather, the browser is only interested in the final product that comes out of the factory: a processed HTML document that it knows how to render into a human-readable webpage. The browser requests these documents, and the server works hard to deliver them—so everything that happens at the factory is ultimately tied back to satisfying the browser’s requests.
URL: The Production Order
The consumer knows how to tell the factory what it wants. A browser tells a WordPress site which webpage to produce, by sending an HTTP request for a specific URL.
As a user, each URL you type into your browser becomes a “production order” sent from your browser to the web server that hosts the WordPress site. That production order tells the WordPress factory to chug to life, and to deliver a specific webpage back to the browser.
For example, the URL
https://wpshout.com/ is an “order”—from a browser to the server that hosts
https://wpshout.com/—to create and deliver back the WPShout homepage, which lists around a dozen of WPShout’s latest posts.
https://wpshout.com/about is an “order” to create and deliver WPShout’s About page, which provides only the contents of that single WordPress page.
Webpage: The Finished Product
Like a car factory produces finished cars for delivery to dealerships, WordPress produces finished webpages for delivery to web browsers.
Webpages are written in HTML, the language a browser understands. They have the elements you’ve come to expect from a webpage: stuff at the top (in a header); stuff at the bottom (in a footer); some amount of main content; and often content in one or more sidebars. They also have a bunch of stuff a normal user can’t see directly, like
Below is a webpage, as rendered (displayed) in a browser. The user requested
https://wpshout.com/articles, which triggered the browser to send a specific request to the server. On the server, the site’s WordPress processing—through the PHP code in the site’s themes, plugins, and the core WordPress software itself—pieced together a webpage containing a header, nav menu, and so on. In this case, the webpage’s main content is a listing of WPShout’s most recent articles displayed in reverse chronological order. The server sent this completed webpage as HTML back to the browser, which displayed it to the user as shown.
Server: The Factory Site
Every factory has to be built somewhere—on a piece of land with a specific address. That land has to be properly zoned, accessible by roads, equipped with plumbing and electricity, and so on. The factory site isn’t the machinery inside the factory, or the raw materials inside the warehouse; rather, it provides the environment for all of the above.
Just like a factory is built on a plot of land, every WordPress site is built on a web server. A server knows how to interpret orders from browsers, how to allocate resources when there are lots of computers making requests simultaneously, how to run PHP scripts and process MySQL queries, and more. It is the hardware and software environment that makes a WordPress site possible.
Inside the WordPress Factory
This section describes the inner workings of WordPress itself.
Okay, now let’s look at how the factory itself churns out product. This section describes the inner workings of WordPress itself.
Posts: The Raw Materials
Like a car is made mainly out of metal, a WordPress webpage is made mainly out of one or more posts.
The unit of WordPress content is the post.
Whatever post type a post is part of—such as Page, Post, Media Attachment, or a custom post type like Product or Recipe (or anything else!)—the unit of WordPress content is the post.
Below in the WordPress admin area, we see a new post being created. In this specific case, it’s a post of type Page.
This Page’s post contents will be the raw materials for a webpage that WordPress puts together, whenever a user visits the site’s
Database: The Warehouse
Just like a car factory’s warehouse stores its raw materials when they’re not being made into cars, the WordPress database stores posts, user information, and quite a bit else.
WordPress uses MySQL databases. MySQL is just a very common way of structuring computer databases, and isn’t a topic you need to know deeply. A MySQL database is a collection of lots of database tables (a bit like Excel spreadsheets), each with lots of rows and columns. It’s in that database that a WordPress site stores most of its data, about users and passwords, site settings, and more.
Most importantly, the database stores almost all of the site’s content. Every WordPress post you write (of any post type) gets its own row in a table called, by default,
wp_posts. And believe it or not, every WordPress post’s content—even a 10,000-word article—gets stored as a big jumble of text and HTML in a single cell of that row.
Below is the
wp_posts table of a WordPress site’s database. You can clearly see WordPress’s default “sample page” text (“Welcome to WordPress…”) stored in the
Without getting too much further into specifics on the WordPress database, the important thing to remember is that most text-based content ends up being stored as one or another type of post.
WordPress Core: The Factory Floor
As we discussed last chapter, WordPress core—the WordPress core software—is what WordPress itself is. Another term for WordPress core is just “WordPress.”
This is the “factory floor” of our WordPress factory. On this floor, WordPress accepts raw materials from the warehouse—WordPress posts and other database data—bundles them into shape, and prepares them to be shipped down one or another assembly line for final processing.
For the process of building up a particular webpage to display for a browser, WordPress core’s primary role is to fetch posts from the database. So for starters, imagine a factory floor with a single dedicated forklift, for fetching posts from the database.
WordPress core is a lot more than that, though: it also contains all the machinery that allows themes and plugins, which we’ll discuss next, to function. So in addition to our forklift, we’ve also got millions of dollars’ worth of supportive machinery—big electrical feeds, cooling systems, and so on—that together constitutes WordPress’s native APIs. And we, by writing themes and plugins, get to make the machinery that connects into those APIs.
The WordPress Theme: The Assembly Lines
A theme assembles different types of post bundles into different types of webpages.
Our factory needs one or more assembly lines: manufacturing lines that can accept bundles of raw materials and process them into consumer-ready goods. For a car factory, that would mean things like welding the doors on, upholstering the seats, and painting the car.
A properly built WordPress theme does that work for a WordPress website. It takes raw materials (fetched posts), bolts them together during their progress down a single assembly line, and styles their presentation so that they’re attractive for the end consumer.
A WordPress theme’s PHP templates make up its assortment of assembly lines. These templates—
archive.php, and more—are highly customizable and can whip up lots of different-looking products, even given the same raw materials.
How does the theme know which assembly line to send a particular post bundle down? With the WordPress template hierarchy. WordPress examines which raw materials were fetched—what kinds of posts were in the post bundle retrieved from the database—and then sends that bundle down the appropriate line according to the template hierarchy. So a complex WordPress theme is a set of parallel assembly lines: a way of automatically assembling different types of post bundles into different types of webpages.
Without assembly lines, raw material would just come in and sit on the factory floor. So every WordPress site must be running on a theme—no exceptions. Themes are the software that tells WordPress data (posts, pages, images, and lots else) how to display, as a finished product. They shouldn’t do much to actually change that data—that’s the job of plugins, and themes doing the job of plugins is a problem we call “theme creep”—but they’re in almost total control of how it displays to the user.
WordPress Plugins: Special Contractors
Imagine a car factory being asked to build rocket cars. They’re already building tires and windshields and stuff, so the environment is partly set up—but there’s a lot of machinery needed to build rocket engines that the factory simply doesn’t have on hand. If some outside contractor could come in and build the rocket engines, in a way that was able to respect and fit into the rest of the production process, then the factory’d be in business.
Sometimes WordPress needs these sorts of functionality boosts. People do all kinds of things in WordPress that aren’t available in WordPress core by default—everything from quickly and easily linking to Google Analytics, to setting up a full-fledged online store with thousands of products and multiple payment gateways.
To get these functionality boosts, WordPress relies on its vast ecosystem of plugins: pieces of standalone code that hook into the WordPress production process in specified ways, and which can fit in and do their work at any point along the factory floor’s processes.
Plugins don’t live in the factory. They live outside, and are invited in for special occasions—when it’s time to deliver a rocket engine, or something else cool and exotic. To learn how the factory incorporates their work, start with .
“WordPress is a factory” is somewhere on the border between a very apt analogy and a literal truth. “Webpage factory” is almost literally what WordPress is, at least rom the standpoint of a browser requesting webpages—just one that uses digital factory equipment (PHP files) and digital raw materials (database contents) rather than physical components.
If this all seems abstract, don’t worry about it right now. It’ll make more sense as you dive into WordPress itself. However, as you go through the book, revisit this chapter periodically: over time, you should find this analogy really useful for understanding how WordPress fits together.
To say (not in thousands of pages)
What it is in which WordPress engages:
It retrieves posts to process,
Then sends them across as
The markup that makes up webpages.
- WordPress “lives on”:
- A browser
- A server
- A database
- The primary function of WordPress core software is to:
- Process saved posts into webpages
- Simplify creating data associations on the fly, for quicker development of custom applications
- Optimize the technical performance (site speed) of an existing website
- Each of these tasks is better-suited for a WordPress theme than a plugin, except:
- Control the visual design of a site
- Extend the core functionality of WordPress
- Define what types of post data (for example, titles or featured images) appear on given webpages
Answers and Explanations
B.WordPress is a set of primarily PHP files which reside and are executed on a server.
A.WordPress exists mainly to aid in the creation and display of website content, which in WordPress is saved as posts.
B.Themes should not add functionality to a WordPress site; plugins should. Themes control the presentation of a site’s webpages.
Image credit: pickinjim