It was late summer in 2018. I was an aging developer who wasn’t quite sure where I fit into the WordPress world anymore. I had spent over a decade learning the ins and outs of the platform that launched my career and also served as a hobby for other pet projects I wanted to tackle.
In part, I was bored. I needed a new challenge.
I love WordPress. More than that, I appreciate what WordPress has allowed me to accomplish over the years. However, I was no longer happy with it for my personal blog. It was suitable for the job, but I often found it had a lot more gadgets and gizmos than I needed. I had also been writing blog posts in Markdown for many years rather than the classic editor. WordPress was simply no longer a part of my workflow for my blog. At times, it was a hindrance.
Challenge accepted.
Over a weekend, I built a working custom blog system. I am hesitant to call it a Content Manage System (CMS) because it lacked crucial features, such as an administrative interface, that are at the heart of any CMS. Nevertheless, I built a working system from scratch in two days.
I had no idea I could accomplish such a feat without relying on the useful functions and tools that WordPress had so generously provided for most of my programming career. I cannot count the number of times I accidentally typed out esc_attr() or esc_html() only to remember those were WordPress functions. My WordPress muscle memory was strong. Without knowing it, everything I had learned through building on top of WordPress pushed me to become a more well-rounded PHP developer. There are few APIs I had not worked with from core WordPress. I understood much of the source code and knew the reasons for a lot of the legacy gunk.
My personal project paled in comparison to WordPress’ power and still does to this day. However, it moved me outside my comfort zone. It allowed me to explore old ideas in new ways.
One example was understanding how rewrite rules and routing worked. Some of my friends and I recently joked that no one really understands the WordPress Rewrite API. You just tinker with it until something works and the new code no longer breaks your site. There are many existing libraries out there, but I wanted to understand how this worked for my own edification. Therefore, I set out to build an HTTP request, router, and controller class. The end result was an elegant solution, which borrowed heavily from other PHP frameworks.
With a simple line of code, as shown below for setting up a “book” content type, I could handle incoming requests for a book page, map it to the correct resource, and output the template on the front end. I began to wonder why I had shied away from this foundational website concept for so many years as a developer.
// Create 'example.com/books/book-name'.
$this->router->get( 'books/{name}', Controller::class );There were many other areas where I began to question the “WordPress way” of doing things. During this journey of discovery, I was able to learn things that I could bring back for use in my WordPress projects. By stepping out into the larger world of website development, I was able to better see the flaws in the platform that helped me fall in love with programming. However, I was also better able to see the beauty in the system that thousands of developers have kept running for the preceding 15 years.
It Is Not All About Code
I had the opportunity to study and learn large frameworks like Laravel and Symfony. However, I also studied how other platforms worked from a pure user-experience perspective.
The one thing I knew for certain is that I wanted to test platforms created for people who wrote in Markdown. I wasn’t looking for huge platforms to compete with WordPress’ power, such as Joomla or Drupal. Instead, I was looking at lighter-weight solutions like Grav, Jekyll, and Hugo. I wanted to understand how the user experience fit in with my workflow.
Of all the solutions I tested, each had its advantages. Each also had features or methods of doing things that wasn’t to my taste. The good thing about the experience was that I was able to identify how I wanted my blogging platform to work for me. Reading thoughts from others in those communities also allowed me to hear from users outside of the WordPress community about why they loved their preferred blogging system.
I soldiered forward. Using what I learned from those platforms, I built something that I was happy to use. It wasn’t perfect and would likely never be. Room for growth is not a bad thing.
During this time, I rekindled my love of blogging with WordPress. While not always the popular opinion, the block editor felt leaps and bounds better than the classic editor. It was something I could see myself using regularly. Aside from my personal blog, I began using it on other projects. I still write in Markdown every day. However, I find myself enjoying writing within WordPress’ editor for the first time in years.
Why You Should Try New Platforms
From a developer perspective, it is not a good idea to become complacent and rely on a single system. Instead of calling yourself a “WordPress developer,” think beyond that terminology. Instead, you should be a PHP programmer or JavaScript programmer. Or, better yet, simply call yourself a programmer. Programmers solve problems. The tools or languages are what you use to get from Point A to Point B.
On the job market, being a more well-rounded programmer opens up more opportunities. While most of us can only hope that WordPress will be the leading platform for the next 10, 20, or 50 years, you should be prepared for any future.
Another benefit of working with other platforms from time to time is that you learn ideas that you can bring back into the WordPress ecosystem. For example, it is interesting to see how the Sage starter theme implements Laravel Blade’s templating engine. These ideas can help shape WordPress’ future.
Some ideas can be pushed into core WordPress. Others can improve team workflows within agencies.
Continuing education benefits the WordPress community as a whole. Don’t limit that education to WordPress-specific ideas. Learn from the outside and bring it back.
I completely agree with you Justin. That is my own experience too. The lessons I have learnt from stepping a bit outside WordPress and experimenting with other frameworks are mainly two (which I wrote about here and here):
Rely on Composer to set-up the management of your project, and treat WordPress just as another dependency (then, if you want to use Laravel’s Blade, it’s just a line of configuration code to import it)
Interact with the CMS exclusively through interfaces (“Code against interfaces, not implementations”). Then, the logic of your application can be reused for other frameworks with minimal effort. I’d say that around 90% of the application code is business logic, and only 10% is CMS-specific logic… so only that 10% needs be re-implemented to port the application to Laravel or Symfony or whichever other.
Being guided by these 2 items, I feel I’m a much better developer, even while I’m still coding for WordPress: through Composer my project codebase is always coherent and manageable, and coding against interfaces makes me think what my application needs in an abstract way, without being limited by the CMS’s own opinionatedness (or however you say this).
Btw, to implement routing in WordPress as done by Laravel or Symfony, you can also use Cortex, I’m using this library and it works great