I suspect that being a WordPress developer isn’t especially fashionable these days. You’re not a rat fink or a fool if you’re a WP developer, but you’re not the it kid. At least not in the developer crowd. WordPress has just been around too long to be the thing.
That said, developing software in the WordPress ecosystem can be just as interesting as being that on-the-edge dev who codes React components that interact on the fly with distributed network microservices. (In fact, these days you can be that guy coding in React right within WP, though it’s too early to say if that’s a good thing or not).
Toward the end of this piece, I’m going to provide links to resources that a person would need to have under their belt to enter confidently into WordPress development. How to become a WordPress dev? Learn the things on the far end of the links I’ve put into that list.
The Age-and-Complexity Factor
Today’s WordPress is the result of a gazillion revisions, and even the first pass of the code, almost twenty years ago, was a fork of an existing blog-creation utility. Lots of rethinking, lots of code changes. It’s complex as a result. People say it’s easy to use but I’m not really so sure about that.
You can switch back and forth among thousands of pre-created looks and feels (that is, themes), so it’s powerful in that respect, but it’s also true that this works because the underlying presumption remains that we are dealing with something that is or is very like a blog. We’re just switching the colors around on a page that reliably has a bunch of stock components (the text, the header, the footer, a search bar, etc).
You can’t pick a random website out there and tell immediately whether it’s running on a WordPress installation. But then again, If you looked at the last thousand new WordPress launches, you’d find a high percentage of sites that had a recognizable “WordPress” look.
The look is a header with a horizontal menu, a hero image, a title, text paragraphs, and a sidebar down the right rail. Like this:
So, big hero image. There’s also a very characteristic WordPress effect that zooms out the photo as the page is loaded. (It’s a CSS effect, really, nothing to do with WordPress from a technical view, but way overused in pre-developed themes and page builders for WP.
What’s below the image, further down that same page? This:
Click on a story link and you get a header, a text section, and, well actually, the text pages on the site are considerably simpler and cleaner than one is used to seeing. So, this:
Rather than something like this:
I should emphasize that I’m not knocking Martha’s basic format (can I be honest, though? I can’t believe Martha’s site isn’t better looking than this). When it’s the right approach, center content and sidebars is the way to go. And you can design horrible versions of this or fantastic ones.
But while I think a perceived frumpiness may being weighing on WordPress (use of WordPress from increasing every year, notwithstanding), design isn’t really the direct purview of the WP developer, and it’s the developer aspect that I want to turn to.
The Language Problem
When the internet decided that browsers should be capable of doing more things than displaying text, the language used for adding some programming to web pages was JavaScript, so PHP found no role in client-side, front-end programming. PHP runs on servers. PHP makes you put a frigging dollar sign in front of all your variable names. (Actually, these days, there are usages where you wind up with dollar signs in JavaScript, too. And what’s wrong with dollar signs, anyway?)
[et_bloom_inline optin_id=”optin_2″]
WordPress Developers: Three Different Kinds
WordPress developers, as opposed to theme designers, fall into what I think of as three categories.
The first is people writing the code for WordPress itself. Anyone can throw their hat into this ring, because WordPress is an open-source project. But when I talk about WP developers in this article, I’m not really talking about WordPress Core developers.
The second sort of WordPress developer is someone who knows their way around WordPress, knows how web style sheets work, knows good themes from junk themes, has experience with the most widely used plugins that extend WordPress’s capabilities, and knows how to take all these things and craft a solution. This is someone who probably does some coding, can write a plugin in PHP in order to smooth over a bump in the works, and who can absolutely help you avoid those early mistakes that take a lot of time to correct later.
There’s a huge ecosystem out there for this sort of WordPress developer, and rightfully so. For all its surface calm and order, the internal workings of WordPress are the result of years of tweaking and extension while trying to maintain backward compatibility. There’s a whole universe of craziness and detail lurking there. People who really understand how the parts fit together and can control things without blowing your site up are people who provide extremely valuable services.
My heart’s with the third group, though. These are the folks who write more complex plugins. They write shopping cart plugins, newsletter plugins, calendar management plugins, and so on. Historically, they have done their programming in PHP. That’s shifting, but most WP custom coding still happens in PHP.
I started my coding with the C programming language. As I’ve mentioned elsewhere, many languages out there look a whole hell of a lot like C, or its C++ descendant. PHP, for instance, looks like C, just with annoying dollar signs pasted in front of variable names (and a few dozen other annoying changes that I think were thrown in spitefully). JavaScript is C thrown into browsers, with a bunch of stuff stripped out for simplicity’s sake, then gradually added back in over the years.
C made it trivially easy to screw up memory management and mistake pointers to variables for the variables themselves. The later languages made it very hard to make these basic mistakes, so I’m not sorry to have moved on from C. But my point is that PHP is like C which is like JavaScript.
JavaScript is on trend
Now, JavaScript is undeniably trendy. It would have to be, because it’s what’s built into all the browsers in the world. People who didn’t want to code in PHP on the server anymore made a server-side setup for JavaScript, in the form of Node.js. And it’s pretty sweet, I’m not gonna lie.
Yeah, JavaScript is sweet. On the client side, all sorts of wildly capable libraries and frameworks have been created, of which the one that really grabs me is React. It grabs everybody who dips a toe into it. I’m restraining myself from taking a big detour to talk about why React is cool.
You know how you can tell JavaScript is absolutely the height of fashion just now? Because people using it are ready to look past all sorts of “extra step” things you have to put into the mix to really play ball with JavaScript. I’m talking about Babel, Webpack, and the way you can’t code for the front end without running Node.js (a backend piece) and its toolset. Oh, probably include React in that list, though React brings more benefit than extra learning curve.
React
I’m not the only person out there who thinks that React is the cat’s meow. WordPress used it to build their new Gutenberg editor system as well, and multiple facets of the future of WordPress are written in React.js.
Yeah, yeah, the server-side core is still written in PHP, but the move to JavaScript within the fortress walls was the death knell for PHP. Even WordPress has given up on it (sort of).
And you can take a step back and just maybe worry that WordPress itself looks less than brand new and exciting. I mean, you know that company Culture Trip? OK, it’s entirely possible that you don’t because I at least am not aware of them being a household word. But they did get funded to the tune of $80 million (on top of a $20 million Series A round).
In a Medium blog post about changing tech stacks, note the implicit world-weary sigh in the first sentence:
Culture Trip’s website used to be a WordPress site. Now it’s a flexible, universal (isomorphic) JavaScript App powered by Next.js, React, MobX and Styled-Components on the front-end that uses WordPress as a semi-headless CMS.
I mean, holy freaking cow! You want to waste your life in WordPress after you’ve read about what Culture Trip did? I mean, 2019 was probably not a great year to invest in a travel-related web business, what with the pandemic arriving and all, but this puppy is universal (isomorphic). You heard anyone describing their WordPress site that way lately?
Yes, do note that they are still running WP on the back end for this ass-kicking site of theirs. This time around, we’ll skip getting sidestepped on WP as a headless CMS, but it’s a huge, interesting topic.
But here’s my point (and yes, I do have one, though it’s taken me long enough to get to it): WordPress is a fascinating development environment, PHP is basically the same as JavaScript, so who cares if we’re writing PHP, and a tremendous amount of junk that you’d have to go off and find a library for if you were coding in JavaScript are already turned up and running in WordPress, so you only write the code that does something new and different.
If you wind up as a WP developer it will not have the adverse effect of stunting your growth, either as a developer or as a human being.
Coding within the WordPress universe can be pretty interesting. There’s a whole world in there, largely driven by callbacks to functions you’ve written (though, in fact, pretty much everything in WordPress itself is implemented as callback functions, so it’s not just you.
Each time a page is served up by WordPress, there’s a sequence of events that has roughly the complexity of whatever list NASA put together to launch a Saturn V rocket. At each point in the sequence, WordPress checks to see if a some process has registered a callback function for that point, then calls each function in turn (based on a priority ranking that you can manipulate to increase or lower the priority of your own functions).
You kind of have to stub your toes as you learn the quirks of this process, but it’s incredible how much nuanced control this enables you to have when creating a plugin.
To take an important instance of this up for a moment, there’s an action (those points in the sequence I mentioned above are referred to as actions and filters—they are slightly different from each other, but they each call back to a registered function that “hooks” the action or filter) that gives you a chance to create new post types.
Custom Post Types
Content posts are the primary elements of WordPress as a content management system. WordPress began life with the assumption that it was going to store blog entries, and that each blog entry would be several things (the title, the publication date, the text itself, and so on) stored together. But lots of other things (non-blogpost pages, to take the next post type that WordPress added, but also stored media, site navigation menus, and any behind-the-scenes prior revisions of posts) can be stored as “several things stored together.”
What makes WordPress more of an application framework than you might think is that you, as developer, can decide that you want other sorts of things to be stored this way, and thus you can create new Custom Post Types (CPTs). You might decide that your web site will have “sections” that you can treat as grouped into multisection publications, along the lines of an ebook.
In this example, “sections” will be more or less the same thing as regular old blog posts, but they’ll be grouped differently, can be sorted in some other way than the reverse chronological order that blogs generally use, and can have different layout and styling.
Or if you built a site for selling event tickets, you might have a CPT with entries for each event (event description, date, time, venue, and so on).
Layout and styling are in the “theme” category rather than the “plugin” category, but when you’re creating applications that organize themselves by using CPTs, the look and behavior of pages within this CPT becomes an important part of overall development. And, indeed, the template for a given type of page is, in fact, a PHP file. It’s a template, yes, with baseline text and HTML tags and so on, but in some situations a great deal of actual code winds up in those template files.
If you’re a hip cat and you’re working with Gatsby, you are doing largely the same thing when creating React components that will render portions of the various pages on your site. If you like doing it in Gatsby and React, there’s really no reason not to think you won’t like doing the same basic stuff in PHP files inside WordPress.
It’s real development, rewards your increasing understanding of WordPress internals in that ‘instant-gratification’ reward system that is such an addictive part of learning new things in programming, and lets you build surprisingly complex applications all by yourself, because you’re able to operate at a high level of abstraction in a system that has a huge range of capabilities.
A huge amount of the world’s online business is for small things and mid-sized audiences. People using highly tailored applications—things that run low-volume ecommerce sites or that manage architect offices or manage bids for roofing contractors—get more than enough performance from WordPress.
If you’ve got content that needs to slaughter PageSpeed scores, sure, maybe you need a statically generated site (like something done in Gatsby, as per the above). But in point of fact it’s entirely possible to generate static pages from plugins within WordPress (if you’re curious, here’s more about how I do this).
You can also get better performance from nothing fancier than a well-tuned cache for your static pages and elements.
Given the modest traffic and transaction rates that most custom-programmed WP sites get and the ability to make static versions of posts and pages, WP is mature, sure, but also still pretty limber. It’s still the popular choice for most business websites and, it’s going to be dominant for years.
There’s work to do, the programming tasks can be subtle, demanding, and rewarding.
What to Learn
As long as we’re here, we should talk about the skill set. It’s straightforward, but not necessarily easy to get everything into your head that you’ll need to be a successful developer in this environment.
First, you need to know your way around setting up and running a WordPress site. I think the best way to get started is to get a cheap web hosting account at a place that offers users the Cpanel interface for loading software on their account. Get into Cpanel and install WP. Figure out how to make a site that looks like Martha’s. Then figure out how to make one that looks even better.
You want to know how to create new posts, how to create “pages” that aren’t posts and how to manage access to these pages using menus. How to install and swap out WP themes. Then find some basic tweaks that you can handle with one of the tens of thousands of existing plugins out there.
Everything about everything in WP is described, sometimes quite cryptically, in the WP Codex. For elucidation in bite-sized pieces, there are sites like WPBeginner.com. There’s a good video tutorial from FreeCodeCamp.
Beyond baseline WP admin mechanics, you should know a reasonable amount about HTML and CSS. There’s really no way to work on the web without understanding these two fundamental pieces. HTML is no big deal (though make sure you’re clear on what the DOM is within a browser, along with the subtle ways in which it represents but isn’t the same thing as the HTML for a page). CSS can be a complex beast, alas. People tend to give it short shrift and then they live in fear of it for the rest of their coding careers.
A good resource for both HTML and CSS is W3Schools.com. PHP and JavaScript, too.
I haven’t taken it myself, but Josh W. Comeau is on the cusp of the general release of an online course that covers CSS soup to nuts. I’ve seen bits and pieces and they are interactive and engaging. He’s not giving it away, by any means, but it’s probably worth the ticket price.
The Actual Development Part
After that, you’ve got to know how to program. Server-side pieces like plugins continue to be written primarily in PHP. Client-side stuff is JavaScript. If you are comfortable in one you can get coding with the other in relatively short order (add or remove the dollar sign in front of variable names).
While PHP is the core of WordPress, if I were starting from scratch, I’d learn JavaScript first. You’ll find more resources, and generally better ones, than you’ll find for PHP. And though I’ll annoy some folks by saying this, you’ll find more of the resources pushing you toward a better grade of programming. PHP is capable of all the elegance and cutting-edge techniques you can throw at it, but it has a history of people writing (and sharing) fairly messy hacks. When you look for “how to do this or that” in WordPress, it will help if you can distinguish clean, well-coded examples from solutions that have edge-case bugs and are insecure.
As you learn to code, you should start looking at how themes and plugins are built in WordPress. Build minimal versions of each, then try tackling increasingly demanding tasks, especially on the plugin side of the equation.
Ultimately, you should figure out the workings of Gutenberg “blocks,” which are the emerging new paradigm for building things in WordPress. Since new blocks are coded and the whole block thing is still very much in process, there’s going to be a lot of work on this front over the next couple of years. See here for a quick introduction to the development side of Gutenberg. The tutorial at Delicious Brains is more hands on and has some good insights.
Are you thinking about jumping into WP development? If so, what are you hoping to do with it?
Leave a Reply