Dynamic Content Generation – How WordPress is Like a Sushi Restaurant

(Reading time: 6 – 10 minutes)

I bet you didn’t know that WordPress works just like a sushi restaurant. Most people don’t. But you’ll see it’s true.

First a little motivation.

When someone asks you “Is WordPress static or dynamic?” what does that mean?

Do they want to know about how WordPress operates, or how information displayed by WordPress on your website changes over time?

These are both really good questions.

We’re going to answer the first question: WordPress operates by dynamically generating content using a web server and the PHP scripting language connected to a database. You probably sort of know this, even if you aren’t a web programmer. Answering the second question would add another 1000 words to this article; watch for a blog post instead.

So let’s take a look at how WordPress generates content dynamically.

But not until we get a bite to eat…

Clients, servers and sushi

Everybody loves to eat!

Imagine your stomach rumbling… you’re so hungry you’re getting cranky. Time to eat. We’re going for sushi today, because it’s my treat and I insist.

As we’re seated in your favorite sushi restaurant, let’s look around. The dining area is a busy place. Waitresses flit back and forth, orders from customers to kitchen, then sushi back to customers.

We browse the menu (client)… there’s bento boxes, nigiri, sashimi, soba, all sorts of nice things to eat (not just raw fish). Each selection is different, but every selection is assembled from a “database” of ingredients.

The waitress takes our order to the kitchen (server).

We wait…

While we’re waiting, there’s a lot of activity in the kitchen which we don’t see. Our order gets put in a queue, probably sorted in first in, first out – FIFO. (FIFO just means we have to wait out turn.)

The chef examines our order. He selects the ingredients from the sushi bar (i.e., queries the database) for the ingredients and prepares our meal. He slices, dices, garnishes, assembles, arranges, cooks, bakes, fries, nukes, sprinkles, sautes… well, you get the idea: our order sets into motion a considerable amount of invisible activity.

Once the chef is finished in the kitchen, our prepared food is given to the waitress.

She brings our sushi. Scrumptious!

All is well with the world.

Next, let’s a look at reading a blog.

Clients, servers and WordPress

Here’s what happens when you’re reading a WordPress blog.

You clicked on a link on a web page to get to the blog (or entered URL, no matter).

Your web browser, let’s say Firefox (client), opened a connection to the web server (probably Apache), and transmitted your request as a payload using HTTP (HyperText Transfer Protocol). The web server gets your request and puts in it’s queue. When it’s your turn, the server sees that the request is asking for a page rendered using PHP, so it fires up the PHP interpreter. The PHP interpreter locates WordPress according the to URL (really a collection of PHP scripts stored in a specific location on the host).

WordPress figures out which web page is being requested, queries the database for the relevant information, then delivers the web page as payloads to one or more HTTP packets.

Firefox gets the packet, extracts the payload, then displays the web page for your entertainment.

(Simple, really, but there are a lot of moving parts.)

“So how does sushi compare to WordPress?”

Good question…

Comparing sushi and WordPress

Succinctly, to run a sushi restaurant, you need a kitchen, a cook or chef, sushi, a waiter or waitress, a dining area, a menu, and hungry diners.

To run a web application, you need a platform (Apache, MySQL, PHP), a server-side application (WordPress), information or data, a network connection to the server, a client (web browser), and interested readers.

Let’s compare:

• Kitchen → Apache, PHP: Just as the kitchen provides a place for food preparation, Apache and PHP provide the environment for assembling and delivering web pages “on the fly.”
• Sushi bar → MySQL database: Your database contains the information of interest to your readers. Web pages are assembled from the database just like sushi is assembled from the sushi bar.
• Chef → WordPress: The WordPress platform is like the chef. This is where all the magic happens, all the produce and meat and noodles get turned into stirfry or spaghetti or whatever. Lots of stuff going on: chopping, boiling, grilling, etc., very dynamic.
• Waitress → HTTP (HyperText Transfer Protocol): Just as the chef is too busy to interact with a large number of diners, the web server needs a standard way to communicate with browsers. In the restaurant, the waitress carries orders and food. On the internet, HTTP carries web page requests and responses.
• Dining area → Internet: The dining area provides a common area for carrying traffic. Orders to kitchen, diners to tables, food from kitchen, the dining area is neutral. The internet is the same: neutral to the information being transmitted.
• Menu → Browser: When hold a paper menu in your hand, examining all the delicious sushi, this is exactly like examining all the links on a web page. In both cases, you must select from a large number of choices to proceed.
• Bento box → Web page: Bento boxes are assembled from various kinds of foodstuffs: tempura, sashimi, perhaps some nigiri, etc. all arranged in a standard tray. You know about what you’re going to get. WordPress delivers up a web page arranged in a standard configuration, you know about what you’re going to get.
• Diners → Readers: The person viewing your web page is like the diner. They sit in a chair, browse the menu, submit an order to the waitress, and wait for their selection to return from the kitchen.

Strip out all the fancy acronyms (HTTP, HTML, CSS, PHP, &c. &c.)… it’s not really that difficult.

Homework

Here’s the first part of your homework:

Go out to eat!

You can go for sushi, or steak or whatever your craving, it doesn’t matter that much.

When you sit at your table reading the menu, pretend you’re really surfing the web.

When you place your order, pretend your really clicking a link.

As you watch the waitress taking your order to the kitchen, pretend she is really an HTTP packet where your order is the payload. While you’re waiting for your dinner, think about Apache giving your order to WordPress, and WordPress using PHP and MySQL to assemble your tasty HTML and CSS treat.

Then just as our waitress brings us her payload of tasty packets of food, Apache returns your web page.

The second part of your homework is tell me anything you found unclear in this article. If I wrote anything confusing, ask me to clarify. If you think analogy sucks, that’s fine, just explain why you think sucks. If you hate sushi… get the soba next time!

---

Yes, I know that sushi is really just a blend of sticky rice with a dash of sugar and a sprinkle of vinegar. It’s true. I make it at home. Sushi has nothing to do with raw fish. Except that everyone thinks it’s the same.

[Update 1/1/2010] Here’s a great article explaining how GETting a cup of Starbucks coffee can be modeled using HTTP. Brilliant work.

These articles fit together as follows: everywhere there’s an interaction – customer to waitress, waitress to kitchen – in the sushi restaurant, that information can be handled using the procedure described in the Starbucks article.

Warning: the Starbucks article is technical, you may want your handy HTTP specification at hand.