Understanding “Server-Side” and “Client-Side” in WordPress
This article explains “server-side vs. client side” in WordPress development. This distinction, and how the server side and client side interact, is at the core of not only WordPress development, but of any real understanding of how the web works.
We’ve jam-packed this article with a helpful overview video, key points, a detailed infographic, a quiz, and even a summary limerick(!). That’s because it’s not just one of our normal articles: It’s a sample chapter from our “learn WordPress development” course Up and Running, now in its revised and expanded 3rd Edition.
If you like this article, be sure check out Up and Running. There’s about 40 more chapters where this one came from. We stand behind it as the single best guide to WordPress development out there.
Serious About Learning WordPress Development?
Get Up and Running Today
Up and Running is our complete “learn WordPress development” course. Now in its updated and expanded Third Edition, it’s helped hundreds of happy buyers learn WordPress development the fast, smart, and thorough way.
“I think anyone interested in learning WordPress development NEEDS this course.
Before I purchased Up and Running, I had taught myself some WordPress code, but lacked direction. Watching the course’s videos was like a bunch of lights being turned on.
I went from being vaguely familiar with how themes, functions and WordPress itself worked to mastering these. Everything became much clearer.
I very happily recommend this course to anyone willing to listen.”
–Jason Robie, WordPress developer
Take the next step in your WordPress development journey!
- WordPress lives on a web server, and delivers web content to a user’s web client (his or her browser).
- Processes that occur on the server are called “server-side,” as is the server environment itself.
- Processes that occur in the web client (browser), and the general environment of the user’s browser and device, are called “client-side.”
- Key server-side elements in WordPress include: PHP scripts, which run only on servers and are a WordPress site’s main ingredient; and the WordPress database, which stores all WordPress posts, post data, and user data (among other things), and which exchanges data with the server’s PHP scripts via a special language called SQL.
If you’re looking to understand the inner workings of WordPress, one of the most important things you’ll need to understand is the distinction between server-side and client-side languages, environments, and processes.
Perhaps more than any other single piece of knowledge, understanding this distinction has helped me make sense of how WordPress does its magic. It’s the key to understanding the “guts” of any WordPress site, as well as the unique role of the different technical languages used in WordPress. It’s also embedded deeply in any discussion of themes, plugins, the Loop, and the other structures upon which WordPress is built.
In other words, you simply can’t understand WordPress without it. So let’s take a look!
We lay out the relationship between server-side and client-side in a big diagram, which we’ll introduce in a minute. But before that, we’ll need a few pieces of essential terminology:
- User: a person who wants to view and interact with webpages using an internet-capable device, like a computer or smartphone.
- Client: the User’s internet browser, running on his or her device.
- Server: the computer, located anywhere in the world, where the desired website is hosted (stored).
- Local: stored on, happening in, or otherwise pertaining to the environment of the User’s device.
- Remote: stored on, happening in, or otherwise pertaining to the environment of the server.
Also, for a refresher, we’ll be looking at the role played by each of the following languages that constitute the core of WordPress:
- HTML: What web browsers read to turn text into fully formatted webpages.
- CSS: A styling language that makes HTML styling rules more flexible and repeatable.
- PHP: The backbone of WordPress; the primary programming language of the WordPress software package, and of nearly all WordPress themes and plugins.
- MySQL: The software that structures WordPress databases. The way to talk to a MySQL database is through SQL queries. However, because WordPress developers can almost always use premade PHP functions bundled with WordPress itself instead of writing queries directly, you don’t need to know MySQL deeply to be a basically competent WordPress developer.
Okay, now for the big diagram:
Don’t worry, we’ll spend the rest of this post explaining how the diagram works. You can also view it full-sized as Server-Side and Client-Side in Resources.
The Steps Involved in Loading a WordPress Page
The diagram shows the flow required to generate any page in WordPress. Since what WordPress does is generate webpages for clients (browsers) who request them, understanding this flow is the same as understanding the guts of WordPress itself.
The flow works as follows:
1. HTTP Request from Client to Server
Your browser asks the server to give back the webpage you’ve requested.
When you enter a URL into your browser, this tells your browser which site you want to view, and which specific page or post on that site. Your browser (the client) then sends a request, called an HTTP request, to the server where the site is stored, asking the server for the webpage you’ve requested.
HTTP, for HyperText Transfer Protocol, is the main way computers talk to each other on the web: it’s a standardized type of “handshake” between two computers that lets them exchange information. You don’t need to know the details here, but we do cover them in more depth in Working with HTTP APIs in WordPress.
2. Initial WordPress PHP Processing on Server
When the server receives your client’s HTTP request, it does some initial PHP processing to engage its internal environment.
The fundamental purpose of WordPress’s PHP code is to serve different types of webpages based on different HTTP requests. When the server receives your client’s HTTP request, it does some initial PHP processing to engage its own internal environment, and to interpret the client’s request to understand what the client is asking for.
3. Querying the Database
WordPress uses SQL queries to MySQL to retrieve post contents and other needed information from the database.
To retrieve the post or posts that form the backbone of any WordPress webpage, WordPress must tell the server to make a trip to the WordPress database, where posts, post metadata (such as a post’s author and publication date), and permalink information are stored.
This database usually lives on the same server as the WordPress site itself, but it’s not directly accessible except through MySQL. (For example, if you use an FTP client to view your site’s files on your server, you won’t find the site’s database among those files.)
Using SQL queries, WordPress’s PHP scripts retrieve the database information from MySQL they need to generate the webpage the client has requested—including the post contents (text and HTML markup) that will be the page’s main content.
4. More WordPress PHP Processing to Generate an HTML Page
This step in the process consists of using PHP to process the retrieved post data into pure HTML markup.
After its trip to the database, WordPress knows what PHP template to use, and has actual post content that it can write to the page. This is where the PHP code written in your theme and plugins comes into play.
This step in the process consists of using your theme, plugins, and the rest of the WordPress PHP codebase to process the retrieved post data into pure HTML markup. It’s the “main” step—most chapters in this book fall inside it—since it’s the step that involves most of the theme and plugin code that a WordPress developer writes.
Why is this processing necessary? Because your browser can’t understand PHP—only a server can. Put differently, PHP outputs HTML to send back to a browser, because HTML is what a browser can understand.
5. HTTP Response from Server to Client
The server sends a clean HTML document back to your browser using HTTP.
During this whole time (maybe one second), you and your browser have just been sitting there while the server chugged away. Now, finally—having made its journey to the database, retrieved posts, and fed those posts through the PHP files that make up the site’s theme and plugins—the server is ready to send a clean HTML document back to your browser. It does this using an HTTP response: a piece of communication using the same HTTP protocol as the initial request, but containing the HTML that satisfies the request.
6. Browser Rendering and Fetching Additional Resources
Now that the client (your browser) has gotten the HTML-containing HTTP response it requested, it can start to build the results into a webpage.
Once the browser has received the HTML and all the associated resources it requested, we’re finally done with the server. If the server blew up now, you and your browser would still have the webpage and everything on it—at least until you closed the window.
Now the browser can do its main job: rendering HTML and related resources into something that looks like a webpage.
When your browser has finished rendering all the resources that were sent to it, you can finally see the WordPress page that you requested when you initially typed an address into the URL bar.
7. Interactivity Through Client-Side Scripts
Your browser can generate interactive effects through client-side scripting.
But sometimes there’s more! On some sites, when you click on an object, something highly interactive happens: for example, when you click a menu tab on an “accordion”-like element, it folds out to display the full body of that piece of the accordion. And some pages actually know what you’re doing as you interact with them: for example, when you enter your password twice to sign up for something, the page may show an error message for as long as the two passwords don’t match, even before you click “Submit.”
None of this involves the server—which could still be a smoking crater as far as we know. Rather, these effects are handled through client-side scripting: pieces of code that were sent to your client (your browser) by the server as part of its HTTP response, but which run in the client itself.
So What is Server-Side and What is Client-Side?
In terms of the flow above, steps 2 though 5 are server-side, and 1, 6, and 7 are client-side. Let’s look at those terms and you should understand why this is the case.
PHP and MySQL are always server-side.
For WordPress sites, server-side means: “Happening during the internal processing a server performs as it tries to serve a page back to a client who’s requested it.”
As a rule of thumb, PHP and MySQL are always server-side—they only run in a server environment. A web browser doesn’t understand them.
This is why PHP can’t, for example, track your mouse. By the time your browser is tracking mouse activity, the server is no longer involved.
“Server-Side” and “Back-End”
As a note, people often use back-end as a synonym for “server-side”: a back-end developer, for example, works mostly with languages like PHP (instead of languages like HTML, CSS or jQuery). “Back-end” is used to mean other things, too, but this is one of them.
So client-side scripts are stuck with what the server has given them: by the time client-side scripts are able to run, the server has already finished its transfer.
This is why, for example, you usually can’t navigate to another page on a WordPress site without experiencing a “reload” flicker: getting the contents of a new page requires a new HTTP request, a trip back to the server and the WordPress database, and an entirely new HTTP response (followed by numerous other HTTP requests and responses for resources like CSS stylesheets and images). Your browser must then build this new set of HTTP responses into a page.
“Client-Side” and “Front-End”
Well, that’s a lot about server-side and client-side—but it was well worth the effort if you’re starting to grasp this crucial distinction. WordPress will make a hundred times more sense to you if you understand it than if you don’t.
As a final note: Don’t worry if this all seems rather technical and confusing. You’ll start to get a much better feel as you program in WordPress itself—just like you’d understand the layout of a town better by living there for a while. So do your best to understand this chapter, but don’t stop here!
The web is a strange sort of science:
We now have our phones as our “clients”—
And by “server,” we mean
A distant machine
That’s probably some guy in Rhode Island’s.
- Every WordPress post’s content is stored in:
- The WordPress filesystem
- A WordPress PHP template
- The WordPress database
- A browser does not understand:
- A server does not understand:
- MySQL Queries
- The following are all server-side processes except:
- HTTP request generation
- PHP processing
- WordPress database queries
- The following are all client-side processes except:
- Saving changes to a post’s contents
- Browser rendering
Answers and Explanations
C.WordPress content lives in the database.
A.PHP is interpreted on servers; browsers do not speak it.
B.Servers don’t make things that look good to humans—that’s a browser’s job.
A.Your browser, on your computer, builds the HTTP requests that it sends to the server.
B.Communication with the database happens only on the server side.
If you liked this chapter on understanding server-side and client-side in WordPress, you’ll love our full guide to WordPress development: Up and Running! From the fundamental understanding presented here, it goes in-depth into WordPress’s core technical systems. You’ll learn way quicker than you could otherwise—clearly, logically, and without sidetracks.
Image credit: Ian D. Keating