Lessons Learned by Stepping Outside WordPress Comfort Zone

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



This article was written by Justin Tadlock and originally published on WordPress Tavern.

Disclosure: Some of the links in this post are "affiliate links." This means if you click on the link and purchase the product, We may receive an affiliate commission.

Leave a Comment

You have to agree to the comment policy.

Scroll to Top