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.
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 unique role of the different technical languages used in WordPress, and it’s an easy answer to a lot of the most common questions you might have as a WordPress learner: “Can I use JavaScript to retrieve the next post?” or “Can I use PHP to track the user’s mouse?” or “Can I view another post without that reloading flicker?”
It’s also embedded deeply in any discussion of the Loop and the other processes WordPress uses to generate webpages.
More generally, you simply can’t understand WordPress without it. So let’s take a look!
Key terminology
I made a big diagram in PowerPoint and had a lot of fun doing it; I’ll be dropping that on you in a minute. But before that, we’ll need a few key pieces of terminology, which I’ve stripped down to their bare essentials:
- 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—which could be 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; what most of the WordPress software package, as well as WordPress themes and plugins, are written in.
- JavaScript: A multipurpose language commonly used to make webpages more dynamic and interactive.
- MySQL: The system that structures all WordPress databases. The way to talk to a MySQL database is through MySQL queries, although WordPress developers can usually use premade PHP functions bundled with WordPress itself in lieu of writing queries directly.
Okay, now for the big diagram:
Big diagram
Simple, right? Don’t worry, we’ll spend the rest of this post explaining how the diagram works.
The steps involved in loading a WordPress page
The diagram shows the flow required to generate any page in WordPress. That flow works as follows:
1. HTTP REQUEST
Your browser asks the server to give back the webpage you’ve requested.
When you enter a URL, this tells the client—your browser—what site you want to view, and what page or post on that site. Through a convoluted process, your browser sends a request, called an HTTP request, to the server where the site is stored. (HTTP is just the language computers use to transfer webpages to each other; you don’t need to know the details here.) This request is basically your client asking the server to give back the webpage you’ve requested.
2. INITIAL WORDPRESS PHP PROCESSING
When the server receives your client’s HTTP request, it does some initial PHP processing to engage its internal environment.
WordPress’s voluminous PHP code is mostly written to turn HTTP requests into different types of webpages. For example, your WordPress theme is a bunch of PHP templates that form the skeleton of your site’s various layouts, which vary depending on the nature of the post or page being requested.
When the server receives your client’s HTTP request, it does some initial PHP processing to engage its own internal environment and interpret the client’s HTTP request to understand what the client is asking for.
3. DATABASE QUERYING
WordPress uses MySQL queries to retrieve post contents and other needed information from the database.
However, to know which template to use for a given webpage—and to actually get your posts themselves!—WordPress must tell the server to make a trip to the WordPress database, where posts, post metadata, 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. (If you use an FTP client, you won’t find it in a “database” folder next to “themes” and “plugins,” for example.)
Using MySQL queries, WordPress’s PHP scripts get the database information they need to generate the webpage you requested—including the post contents (text and HTML markup) that will be the main content of the webpage you’ve requested.
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 your theme and most plugins come into play.
This step in the process consists of using your theme templates, plugins, and the rest of the WordPress PHP codebase to process the retrieved post data into pure HTML markup.
Why is this 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
The server sends a clean HTML document back to your browser using HTTP.
This whole time, you and your browser have just been sitting there while the server ground away on itself. Now, finally—having made its journey to the database and fed the resulting posts through the PHP files that make up the site’s theme and various plugins—the server is ready to send a clean HTML document back to your browser. It sends the HTML back to your browser. It does this using a response written in HTTP, the same language as the initial request.
6. BROWSER RENDERING
Now that the client (your browser) has gotten the HTML-containing HTTP response it requested, it can start to build the result into a webpage.
For most sites, the browser will notice that it needs additional resources associated with the page, like CSS stylesheets, JavaScript files, images, sound files, and web fonts. It will request these resources from the server via separate HTTP requests, and by default will wait to receive them before it moves on to finish building the 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.
Now the browser can do its main job: rendering HTML and related resources (images, etc.) into something that looks to humans like a webpage. Every webpage, as interpreted by your browser, is a combination of plain text and associated resources, visually organized according to various rules given to the browser by HTML and CSS.
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 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 hover over an object, it changes color. And some pages actually know what you’re doing as you interact with a page—for example, when you enter your password twice to sign up for something, the page will give you an error message the moment the two passwords don’t match.
None of this involves the server—it 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.
The main client-side scripting language is JavaScript. (Some simple client-side effects, like making text change color when you hover your mouse, can be handled through CSS using pseudo-selectors.)
So JavaScript is sort of the opposite of PHP: the server doesn’t bother to understand it, but just sends it along to your browser, which runs it as part of the process of loading the page it’s requested.
So what is server-side and what is client-side?
In term 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.
SERVER-SIDE
PHP and MySQL are alwaysserver-side.
For WordPress sites, server-side means: “Happening during the internal machinations a server goes through as it tries to serve a page back to a client who’s requested it.”
PHP can’t track your mouse: by the time your browser is tracking mouse activity, the server is no longer involved.
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 track your mouse. By the time your browser is tracking mouse activity, the server is no longer involved.
CLIENT-SIDE
HTML, CSS, and JavaScript/jQuery are all client-side.
Client-side means “happening inside your browser, once the server has sent back the necessary resources.” So HTML, CSS, and JavaScript/jQuery are all client-side: they live on the server, but it’s your browser that does anything with them.
Client-side scripts are stuck with what the server has given 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 can’t navigate to another page on the 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.
However, you’ll notice that homepage sliders usually transition seamlessly from one photo to the next. This is because the server sent them all at once as part of the same page load, and they’re being displayed and hidden on the client side using JavaScript.
(Two very minor notes on this section: a solution for flicker-less refreshing exists for certain needs and is called Ajax. Also, there is such a thing as server-side JavaScript—JavaScript which takes the role of PHP. Both of these are fancy programmer tools and we won’t worry about them here.)
In conclusion…
Understanding Server-side vs. Client-side is crucial to understanding how WordPress works.
Image credit: Ian D. Keating
No comments:
Post a Comment