WordPress Development for Beginners: “Does the User See It?”

Getting started with WordPress development can be disorienting. As I’ve written, software development (including WordPress development) is a lot like caving, and trying to do your first WordPress development project can be like waking up somewhere in the middle of a dark cave and trying to figure it out from there.

What we need to get started in WordPress development is to get oriented. In a cave, we’d want to start by knowing one very simple thing: “Does this lead toward the entrance, or further into the cave?”

For a beginner WordPress developer, we can get oriented by asking, “Does the user see it?”

From my start as a beginner WordPress developer until now, I’ve found that WordPress has a similar orienting principle, which can help us get a rough sense of where we are even if there’s lots around us we don’t understand.

That principle is: “Does the user see it?”

WordPress Development for Beginners: “Does the User See It?”

There are two options in answer to this question:

  1. Yes, the user sees it. Things like text, HTML, images, and JavaScript can be directly interacted with by the user on his or her browser, screen reader, or other device.
  2. No, the user doesn’t see it. Things like PHP files (which are the basis of themes, plugins, and WordPress itself) and MySQL databases aren’t ever visible to users, but they build most everything that is.

Understanding intuitively the answer to “Does the user see it?” is a super-helpful element of my own skillset as a WordPress developer. So this WordPress developer guide takes that approach to introducing much of the same material covered in our core free WordPress development course, and in our other courses and articles. It’s a new way to cover WordPress development for beginners, and if you understand how to get oriented this way, you’ll have a huge head start on your WordPress caving journey.

What the User Sees

Ultimately, what a user sees is limited to what a browser can interpret. That narrows it down to just a few elements:

  1. Text content (words, numbers, and other symbols).
  2. HTML tags that mark up text content, doing things like “italicize this text” or “put this text inside a paragraph.”
  3. Media files (such as images and videos), included using HTML.
  4. CSS styles that tell HTML how to look, like “make all paragraphs have a 16-px font size and a dark gray color.”
  5. JavaScript code that provides special interactivity, like playing or pausing a media file on a button click.

And that’s it: that’s the sum total of what your users see when they visit your WordPress site.

What the User Doesn’t See

What’s left out of this list? An awful lot:

  1. Anything written in PHP, which is the core language of WordPress, and which browsers don’t read.
  2. Most of WordPress’s core code itself, which is written in PHP.
  3. Most of the code of any theme or plugin, which is written in PHP.
  4. All the details about how your site’s data is stored—your filesystem (the files and folders on your server), and your WordPress database (the MySQL tables that hold most of your site data, also on your server).
  5. Any other details about the LAMP stack, the “under-the-hood” technical environment needed to make WordPress run properly.

Everything on this list has one thing in common: the user doesn’t see it, but it’s what generates what the user sees.

The user doesn’t see PHP and other back-end technologies, but they generate what the user sees.

In other words, WordPress’s entire underyling PHP system—consisting of WordPress core itself, plus the PHP component of any themes and plugins that are running—exists to create what the user sees, although it’s never what the user sees himself or herself. The same with Linux, Apache, and the WordPress database: they’re all underlying structure that’s indispensable but ultimately invisible to the user.

This distinction between “user-facing” and “non-user-facing” is better known as the “front-end” and “back-end” distinction. We’ll explore that distinction now.

Understanding the WordPress Front-End and Back-End: User-Facing, Or Not

“Front-end/back-end” is a paired term that actually has at least two meanings in WordPress—both of which are based on the fundamental question, “Does the end user see it?”

“Front-end/back-end” can mean at least two things in WordPress—both based on the basic question, “Does the end user see it?”

Let’s start with the technical meaning of “front-end” and “back-end.” This isn’t just a WordPress thing—it’s at the heart of job descriptions like “back-end developer” or “designer and front-end dev” that exist across the tech world.

What Technical People Mean by “Front-End” and “Back-End”

In general, the front end is “anything the user sees.” This is why front-end web developers are generally very focused on user-facing technologies such as JavaScript and CSS.

The back end is what the user doesn’t see directly. The back end is very much about more computer-sciencey tasks like storing and retrieving data or doing intensive computations. In WordPress, back-end development is done primarily PHP, along with the other pieces of the LAMP stack.

This meaning of “back-end” and “front-end” is almost interchangeable with “server-side” and “client-side,” respectively, so we heartily recommend reading our explanation of those terms:

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

In a nutshell, the server is where all the back-end computation takes place; it’s done on the server side. That results in data being sent to the client (the user’s web browser, screen reader, RSS feed program, etc.), which consumes that data into a form that humans can use and interact with—all on the front end, the user’s device itself.

So in WordPress as elsewhere, “Does the user see it?” is the dividing line between two distinct (although overlapping) areas of web development.

There’s also “Front-End” (User-Facing Website) and “Back-End” (WordPress Admin Area)

WordPress specifically is also host to a second, more informal use of “front-end” and “back-end.”

A WordPress website’s “front-end” can mean the part of the site a user sees—that is, its webpages, like mysite.com/blog or mysite.com/about.

Conversely, the “back-end” can mean a WordPress site’s admin area—mysite.com/wp-admin—where a WordPress site is managed.

But why would you call the /wp-admin/ section a “back-end,” when it’s actually a set of human-usable web pages viewed in a browser? That’s as “front-end” as it gets, by our other definition.

The WordPress admin is sometimes called the “WordPress back-end,” because end users generally don’t see it directly.

Notice that, as in the other use of these terms, “front-end” connotes “user-facing,” and “back-end” connotes “where you assemble the user-facing stuff.”

So the answer, once again, is because of the basic intuition that the front end is “what users see,” and the back end is “where we set things up so users see the right things.”

WordPress Development for Beginners: Some Things “Does the User See It?” Explains

As you’re getting started with WordPress development, “Does the user see it?” is one core question that explains a huge array of seemingly unrelated technical topics in WordPress.

Here are just a few of many:

1. Which Languages Handle Which Problems

WordPress’s four core languages are PHP, JavaScript, HTML, and CSS. Which of these languages do which things?

It’s a lot easier if you realize that JavaScript, HTML, and CSS are all front-end languages—the user sees them—and that PHP is a back-end language that the user never sees (and that web browsers don’t even understand).

Want to track a user’s mouse clicks? You’re definitely not using PHP, as PHP has no place on the front end. This is a JavaScript project.

Want to retrieve a list of posts and post authors from the WordPress database? You definitely are using PHP, the core language of all back-end processing in WordPress.

The Four Languages You Must Know to Understand WordPress

2. PHP’s echo and return

A core distinction in PHP is between echo and return. What is that distinction? The user sees echo—it gets printed out as HTML—while return doesn’t get printed out yet.

For more, see our articles on both statements in PHP:

Learning PHP for WordPress Development: Understanding PHP’s echo

Learning PHP for WordPress Development: Understanding PHP’s return

3. the_ and get_the_ Template Tags

These two types of template tags—specialized WordPress PHP functions—are, again, divided by whether they print out something user-viewable. the_ tags like the_title() do, and get_the_ tags like get_the_title() don’t.

At bottom, this is simply the difference between echo and return—and at more bottom, it’s two sets of functions depending on whether we’re ready to show our work to the end user or not.

WordPress Template Tags: How They Show Post Content & More

4. The Proper Role of WordPress Themes and Plugins

In general, a WordPress theme should control only display. What does “display” mean? It means “What the user sees.”

Plugins can affect display (social share button or contact form plugins would be two of many examples), but what they’re really there for is to add underlying functionality: things that are invisible for users, but that you need to build the right user-visible things. Many of the best WordPress plugins—Yoast, WooCommerce, Advanced Custom Fields, MemberPress, and countless others—fit exactly this mold of creating underlying data structures that are invisible to users, and that ultimately enhance and empower the user experience.

If you mess this up, you get into the gross problem of theme creep:

The Menace of WordPress Theme Creep

And the core way not to mess it up is, again, simply to ask “Does the user see this?” If the answer is no, it’s likely not a great choice for your theme.

WordPress Development for Beginners: Where to Go From Here

It’s not just the examples above. Lots of other crucial distinctions in WordPress boil down to understanding whether we’re—in any given file on any given line of code—building underlying infrastructure, or actually using that infrastructure to display things to users. What other examples can you think of?

If you want to understand WordPress development in-depth, start with our free courses on the topic, perhaps starting with this one:

Learn WordPress Development: The Basic Course

And if you’re in a hurry and want to learn WordPress development in the quickest, deepest, and most logical way possible, we highly recommend our premium course Up and Running:

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!

Thanks for reading!

Image credit: Alex Barth


0 Comments
Inline Feedbacks
View all comments