Understanding “Server-Side” and “Client-Side” in WordPress

Distance | wordpress server and client

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.

So if you want to know what on a WordPress site is server-side and what is client-side–and what those terms themselves mean—then buckle up. And if you’ve ever wondered “is PHP server-side or client side?” (always server-side!), or “is JavaScript server-side or client-side?” (almost always client-side! go away NodeJS!), then this is for you too.

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!


 

Key Takeaways:

  • 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.
  • Key client-side elements in WordPress include: HTML markup, images and other media files, and CSS styles, which the server delivers to the client to be rendered into a human-viewable webpage; as well as JavaScripts, which program dynamic and interactive behavior into the browser.

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!

Key Terminology

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:

  1. HTML: What web browsers read to turn text into fully formatted webpages.
  2. CSS: A styling language that makes HTML styling rules more flexible and repeatable.
  3. PHP: The backbone of WordPress; the primary programming language of the WordPress software package, and of nearly all WordPress themes and plugins.
  4. JavaScript: A multipurpose language commonly used to make webpages more dynamic and interactive.
  5. 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:

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.

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 requests these resources from the server using additional HTTP requests, and by default will wait to receive them before it moves on to rendering the page.

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 (and, sometimes, JavaScript).

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.

The main client-side scripting language is JavaScript. (Some simple client-side effects, like making a button change color when you hover over it with 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 has requested.

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.

Server-Side

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.

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’re stored on the server (like all files), but it’s your browser that does anything with 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.

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.

(Three skippable notes on this section. First, a solution for “flickerlessly” retrieving additional data from the server exists, and is called Ajax. Second, building whole websites and web applications as a single page, using JavaScript frameworks, is becoming very popular; once the page is loaded, you can then navigate between different pieces of it instantly and “flickerlessly” using JavaScript itself. Third, there is such a thing as server-side JavaScript: JavaScript which takes the role of PHP, as Node.js does. All of these are fairly advanced topics and we won’t worry further about them here.)

“Client-Side” and “Front-End”

As with “server-side” and “back-end,” people sometimes use front-end as a synonym for “client-side.” For example, a “front-end developer” generally works mostly in languages like HTML, CSS, and JavaScript/jQuery, and is very concerned with the way things appear and interact in the user’s browser (that is, in the web client).

In Conclusion…

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!

Summary Limerick

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.

Quiz Time!

  1. Every WordPress post’s content is stored in:
    1. The WordPress filesystem
    2. A WordPress PHP template
    3. The WordPress database
  2. A browser does not understand:
    1. PHP
    2. JavaScript
    3. HTML
  3. A server does not understand:
    1. PHP
    2. CSS
    3. MySQL Queries
  4. The following are all server-side processes except:
    1. HTTP request generation
    2. PHP processing
    3. WordPress database queries
  5. The following are all client-side processes except:
    1. JavaScript code execution
    2. Saving changes to a post’s contents
    3. Browser rendering

Answers and Explanations

  1. C. WordPress content lives in the database.
  2. A. PHP is interpreted on servers; browsers do not speak it.
  3. B. Servers don’t make things that look good to humans—that’s a browser’s job.
  4. A. Your browser, on your computer, builds the HTTP requests that it sends to the server.
  5. 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.

Get Up and Running Now

Image credit: Ian D. Keating


9 Responses

Comments

  • I love that you have taken the time to explain this. I hope a lot of people benefit from this understanding!

  • Aqib Aurangzeb says:

    Excellent explanation! Any doubts i had are now all cleared up. Thank you 🙂

  • Dj Vsal says:

    i don’t know how to thank you.this was really a big help for beginner web programmer.

  • priyanka says:

    In thegeneral-template.phpfile, I have functions (see below – “noindex” & “no robots”) these two functions are not allowing Google bots to index the website. I am trying to find the code where these functions are used. I looked into many files but I can’t seem to find which file is using this code or where these functions are called-in. I need to remove these functions from where they are used (or called-in) in WordPress code. I have tried to remove the code from general-template.php file but then it started to give me the error. So, I am pretty sure that I can’t just delete here; I need to remove the functions where they are used in other files of the WordPress code.

    Any idea ?how I can do this ?

    I sincerely Thankyou you for your help ! See the code below.

    /**

    * Display a noindexmeta tag if required by the blog configuration.

    *

    * If a blog is marked as not being public then the noindexmeta tag will be

    * output to tell web robots not to index the page content. Add this to the wp_head action.

    * Typical usage is as a wp_head callback. add_action( ‘wp_head’, ‘noindex’ );

    *

    * @see wp_no_robots

    *

    * @since 2.1.0

    */

    function noindex() {

    // If the blog is not public, tell robots to go away.

    if ( ‘0’ == get_option(‘blog_public’) )

    wp_no_robots();

    }

    /**

    * Display a noindexmeta tag.

    *

  • priyanka says:

    my website is not index by google costalpavers.com please help me .

  • gary miller says:

    Please i would love to know if WordPress can be categorized as a web designing tool just like Dreamweaver. And how can i use WordPress offline as in on a local host just like Dreamweaver. Thank you.

Pingbacks

Add a Comment

Your email address will not be published. Required fields are marked *