Series: Rethinking PHP Development in WordPress

My web development career began in earnest in January 2013 when I took on an internship at a small agency in the Twin Cities during the last semester of my degree program at my local community college. There, I was first introduced to WordPress, Shopify, and CakePHP, the framework that the owner of the company used to create a custom CMS that many of his clients used.

Because I was brand new to development and the agency world, the ins-and-outs of a custom application framework didn’t really resonate with me right away. And, since I was the only employee, my boss didn’t really have time to teach me how to support it. Instead, I took on many of the theme build projects that came through the door where we chose WordPress as the platform. It was at that agency job where I first familiarized myself with everything WordPress had to offer, from hooks and taxonomies and custom post types to the theme and plugin APIs, and everything in between.

The current version of WordPress in January 2013 was version 3.5. Just two-and-a-half years prior, version 3 was released with an updated dashboard, improved custom post types and taxonomies, custom menu management, multisite(!), and more. I wasn’t in anywhere near the beginning, but by the time version 3.5 was released, it was slowly becoming evident of just how much I could achieve as a developer atop this platform.

Change is Slow to Come

Naturally, as with all things tech, a lot has changed in the subsequent years. Useful parts of the WordPress ecosystem like WP-CLI, the REST API, the Customizer, and the Gutenberg editor didn’t exist when I started. Many of these features had been hugely controversial at the time they were released; some, perhaps, haven’t lived up to their promise. But, over time, we generally come to accept the quirks that are there and make our best effort to improve upon the parts we don’t like.

The features of WordPress that have thrived have been a result of passionate developers contributing their time and effort to propose new ideas, advocate for their necessity, and work through a somewhat bureaucratic process that requires lots of coding, discussion, testing, documentation, and – with a little luck – ultimate approval and inclusion in core.

This is the double-edged sword that comes with contributing to a legacy platform that powers such a significant part of the web. “Democratize publishing” has long been the mission of the WordPress project, and what that means is having a platform that’s not only easy to set up and start using quickly, but it also means having one that is intuitive to extend and modify as one sees fit, regardless of their skill set. It’s the latter part that causes some friction within the development community, because there are those (like me) who wish to be able to include the latest and greatest language features into their projects, but when contributing to parts of the platform that can affect a lot of people, we have to be mindful about how much we push the envelope.

Then Along Came Gutenberg

In many ways, the Gutenberg editor project has turned the WordPress mission on its head. This is due to a number of reasons, not least of which I think are enthusiasm around advancements in the JavaScript community in the past 7 years, and with the rise of burgeoning competitors like Squarespace, Medium, and Wix, which were providing more intuitive interfaces with which to build websites than WordPress had been offering in recent years.

In my view, the changes on the JavaScript side of the WordPress sphere have been a great advancement, though they come at a cost. Developers who aren’t as familiar with JavaScript may find it more difficult to build on top of the platform. And, as my friend Michelle Schulp astutely put it, compiled JavaScript makes it more difficult to discover readable code, something many new and aspiring developers use to learn and grow.

As a community, I think we can do better. And, as an engineer, I think we can and should take the learnings from advancements on the JavaScript side and apply them to PHP. What that means to me is that we should be more willing to revisit how PHP code is structured in the WordPress environment, but that we should do so in a way to help educate and elevate developers to learn how to write cleaner, more organized, and more reusable code.

Doing My Part

Since those early days of cutting my teeth at my first agency job, I’ve tried to stay current with developments in the broader web language communities. Like JavaScript, PHP has advanced a lot in the time since WordPress was first written, but the community hasn’t necessarily been able to take advantage of these advancements due to the intense dedication to backward compatibility. Gutenberg, in many ways, has shown us that we can start to take risks, that we can iterate, try new things, and occasionally make a few mistakes with the goal of coming out with a stronger product in the long term.

I’ve started jotting down notes about the various things I’ve learned and observed from working on personal projects, large agency clients, and most recently in my role on the product team at Rocketgenius. My aim over the next several months is to start writing more about these various topics, with the goal of sharing what I know (or think I know) about software development. Additionally, I hope to get us thinking about how we might apply some of these concepts within the WordPress ecosystem, with the longer-term goal of helping level up other engineers build more robust, scalable, easier-to-understand systems.

Topics

As of right now, my list of topics in this series will include the following:

• Using objects instead of arrays for data structures
• PHP namespaces
• Type-hinting method parameters and return values
• Reducing the number of different return types within methods
• Reducing conditional code complexity
• Creating more (and more descriptive) methods in place of clarifying comments
• The first five principles of S.O.L.I.D., with an emphasis on single-responsibility
• Class file organizational hierarchies
• How to spot code smells
• Abstracting shared and repeated behavior

It’s likely that going through the process of distilling my thoughts in these areas and how they specifically apply to the way things are frequently done in the WordPress ecosystem will lead to even more thoughts worth exploring. I hope you’ll join me on this journey, and that it will spark some additional online discussion. I’m looking forward to it.