WordPress By

Oh, how easily we forget the WordPress of 10, 15 years ago.

We are spoiled. We are spoiled by the gluttony of documentation and tutorials, a wealth of knowledge created over more than a decade. We are spoiled by our own expertise, built-in our more vigorous youth, now sitting on our haunches as we have aged along with our beloved platform.

We have grown to become the proverbial grumpy old men. “Back in my day, we didn’t need all these fancy tools to help us write code. We pulled ourselves up by our bootstraps and built everything from scratch.”

I kid. Sort of. I count myself among the old-school developers who helped build the WordPress that so many are still nostalgic about — I think I have earned the right to joke about myself. They were “simpler” times but not really.

Having been in the community as long as I have, I can remember the backlash each time a new feature landed. I recall the days when there really was non-existent documentation for pretty much everything.

Lately, there has been a growing conversation around the difficulty of overcoming WordPress’s current barrier to entry for developers. This has been an ongoing discussion for a few years now, but the latest flare-up comes on the heels of a tweet by Chris Wiegman:

The deeper I get with modern WP dev the more I understand why newer devs don’t like to work on it. This is not the same project as it was in the past. The learning curve is now extremely high regardless of past experience.

I built my first block plugin in a few hours about a month ago. When writing on the experience, I said the barrier to entry was much higher than when I had built my first plugin in 2007. Having had the time to sit back and think about that, I am not sure it was a fair statement. We tend to view the past through rose-colored glasses while forgetting the real struggle.

What I had wanted was to build the plugin in 30 minutes. Had everything been in PHP, that would have been an easy feat for me. Objectively, I am an expert (or close enough) in the language. However, my JavaScript knowledge is 10 years behind.

It had been a while since I had been challenged in that way. That was a distressing experience for someone who had become comfortable in his own skills.

I griped about the docs. But, let’s be honest. WordPress has never had the sort of deep documentation that could teach a budding developer everything. I know this because I have written at least a couple hundred tutorials in my career. Nearly every time, I dug into the project’s source code to make sense of it, which allowed me to teach other developers how to work with various features. And many other developers in the space did the same.

In time, WordPress.org added more robust developer documentation, but this was not built overnight. It is a constantly evolving project.

I also built my first block type with vanilla JavaScript. No build tools. No React docs open. Just plain ol’ JS code in my editor. I needed to crawl before I could walk, and getting that first iteration of the code into a workable state was necessary before I jumped into anything more complex.

In the days after, I re-coded it all to use more modern JavaScript and compiled it with webpack. A week after that, I built a second block plugin with more advanced features.

Was it hard? Definitely. Was the barrier to entry higher than when I first developed plugins? Probably. Truthfully, I did not struggle as much, but I am also at a different point in my life. At 37, I no longer have quite as much drive and likely less capacity for picking up new skills as quickly as in my late teens and early 20s. However, I have a strong foundation and enough experience to overcome some of the hurdles I encountered.

Would a 20-year-old me struggle with this JavaScript landscape more than a strictly PHP-based WordPress? I doubt it. Both had huge learning curves for someone new.

Someone’s first introduction to Subversion or Composer can be just as scary as their initial dive into webpack and npm. For a fresh mind, an open canvas that has yet to be painted with over a decade of doing things the “WordPress way,” I am unsure if the barrier to entry is so much higher.

For us old-schoolers, our world has been flipped upside down. There is no denying that. The Gutenberg project, which is at the core of nearly every new WordPress feature, moves so fast that it is next to impossible to keep up with while also upping your skills. It is easy to get overwhelmed. When this happens to me, I usually take a step back and return when I have had a chance to rest my mind.

Contributing to the WordPress ecosystem has always had one barrier or another. Whether it be the privilege of time, knowledge of PHP, or some other skill, the project has left some people out. That is changing in some ways. Some parts are now available to users that were never accessible before. This is easiest to see from the theming side of things.

“I wish people would see that theme development is heading the opposite way,” tweeted Carolina Nymark. “The entry barrier for designers and new developers will be lower. When people get stuck saying, ‘But I can’t use my hooks in a block theme,’ it is because they are looking at what exists today, not ahead.”

Having spent more time on the theming side of the block editor than plugin development, I agree wholeheartedly. Theme authors have been given a clean slate, or at least by the time block-based themes are supported in core WordPress, this will be true.

While I could write ad nauseum on the details of how theme development itself is leaps and bounds better, the revolutionary part is how the system welcomes those who had no entryway in the past.

Alongside version 5.8, WordPress.org opened the first iteration of its pattern directory. Soon, any user will be able to contribute custom block patterns without writing a single line of code. They can simply create layouts from the editor, copy them, and share them with others.

When the site editor lands, it will once again change the game. Non-coders will have the power to essentially create entire front-end designs without any preexisting programming knowledge.

If WordPress must become more complex for developers to provide end-users this much power, I can live with that.

The highest barrier to entry — as it has always been — is contributing directly to WordPress. Or at least contributing to the block side of things via Gutenberg.

The Getting Started With Code Contribution section of the Block Editor Handbook is a dizzying list of installation notes and procedures that can be off-putting to even the most seasoned developer. Because just about everything is a third-party tool, any trouble you run into just setting up your system is likely to land you in support forums or chatrooms outside of WordPress. Even moving past setup, contributing code to Gutenberg is unlike the days of yore.

What is lacking is the history. We had a decade and a half to perfect our systems for classic WordPress. It was often ugly and brutal building the platform and the ecosystem around it to a point where it was a comfortable space for developers. We have had only three years for modern WordPress to feel as natural as in years past.

I am ever the optimist, hoping that in another 15 years’ time, we are having these same discussions about the new technology stack that WordPress 10.0 has introduced. In the meantime, I look forward to seeing our documentation evolve, our developer community expanding its skillset, and new WordPressers coming along for the journey.

Continued Reading

In this discussion, there are no right or wrong answers. The conversation matters because it enriches our knowledge and informs how we build the next version of WordPress and the web.

The following are links related to this topic that helped inform my thoughts. Each is worth a read, listen, or viewing. If I missed any that others have published, feel free to link them in the comments.