Lessons Learned by Stepping Outside WordPress Comfort Zone

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.


18 responses to “Lessons Learned by Stepping Outside WordPress Comfort Zone”

  1. 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

    • Great thoughts. Learning and using Composer has been a game-changer for me. Going with an interface-first approach to development has also helped me clean up my code and reuse things across platforms. I’m not quite at a 90/10 split, but I could see getting there in time.

      Thanks for sharing the links. I’m bookmarking them for later reading.

  2. Agreed.

    Unfortunately, the day to day reality within the broader community is much different, at least for a fair number of us. Put it this way, if I had $20 for every time I said “what if…” and that idea was shot down – sometimes with anger – because it was not “the WordPress way”, I could buy Automattic.

    WordPress isn’t a CMS. It’s a cult.

  3. I love WordPress when I’m trying to create a variation of what everyone else has created before. If there are plugins or core functionally that do exactly what I want, then WordPress is a breeze.
    Where is gets frustrating is when you have to spend hours hunting through a poorly documented plugin to figure out why the interface is displaying incorrectly or is not working right.
    When creating something different than everyone else (different functionally, different structure, different appearance, etc.), it’s usually easier just to code it yourself than try to figure out how to force WordPress or a plugin to do something different.
    So for me, WordPress is appropriate for many projects and inappropriate for others.

  4. The only quibble I have with this article is the use of the word “aging.” Based on your LinkedIn profile, you are 18 years younger than I am. That means you’re just about old enough to be hitting your stride, one part of which is recognizing that breadth of experience can be as important as depth.

    • Yeah, I went back and forth on whether I should use that term. I’ve technically been developing/programming for nearly 17 years in some form. In that sense, I feel like a dinosaur at times. :)

      On the other hand, I’m a youngster in comparison to others. I suppose it’s all relative. The point I don’t think I really made clear is that I felt like I was aging at that specific time while watching newcomers pass me by, regardless of the actual truth of the matter. It was more a state-of-mind type of thing.

      • It’s entirely possible to start to feel stale at any age, no matter how enthusiastic you were about something when you started. We start out getting a generalized education and then sink deeper and deeper into specializing. Too much of that and we not only burn out, we end up with the “When all you have is a hammer, everything looks like a nail” problem.

        • Neither of you are dinosaurs. I am that person. And I started out specializing in a different field and splashed around, wider and wider, as I generalized more and more. Even that can bring burn-out but at least the menu is large enough to have on it options for that restless feeling. But I digress from the topic, as both of you got my fingers typing. Darn this internet thing. :-)

          BTW, good article. I’ve been around long enough that I’ve been everywhere man. Started when CMS was not a word. As a result, WP is not the end-all, be-all for me. Thing is, humans like to be comfy on couches and in CMSs. But getting off the dang couch is when the adventures begin.

  5. I tried Drupal several times only to come back to WordPress. Even though there are many advantages Drupal has in core such as internationalization, views and more there are so many disadvantages where Drupal is so complicated compared to WordPress. I gave up searching for a better CMS ;)

  6. This is an interesting piece. But, to think that one platform can be in existence and still striving years to come is not that bad. Is it?

    I mean WordPress can’t easily go extinct considering it’s coverage. However developers should work towards making the CMS more vast, that no feature is lacking, not even one

  7. Thank you for this. We’ve been using WordPress for a very long time already, and we haven’t even think of stepping out of our comfort zones and try new stuff and scale things up. But maybe, now we can consider leaving it for a moment and learn new things. Thanks!

  8. Using WordPress is good, but i feel that you build a website on coding you can entirely customize it by your choice. You can add or remove CSS or any other unwanted script that you wouldn’t want to use in future


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.