I think it's fair to say that most PHP developers have had to, at some point, work with WordPress in some capacity. Whether you're working in a development firm that specializes in WordPress solutions or picking up the pieces, WordPress is a common occurrence. I've talked with folks that swear by WordPress and love it unconditionally and I've talked with folks that hate it. To me, it's a tool and like all tools, it's meant to handle a specific job. In our environment, we use WordPress as an authoring platform for faculty, staff, and students to produce and maintain web presence. It's worked just fine for us, but there is definitely a tendency to paint yourself into a corner.
I've had a lot of interesting conversations with members of the tribe against WordPress. Honestly, I enjoy academic argument as it brings problems out into the open for discussion. Some of the arguments I've heard are:
- WordPress is built for users, not developers. (I agree)
- Programmers that only work in WordPress will be professionally stunted. (I agree)
- The WordPress API is “old and busted” and is “so annoying to work with”. (Haha, again I agree)
- Here's the thing.
WordPress derives competitive advantage in providing a service to end-users that they would otherwise have to go to great expense to receive. I am all for making lives easier so I'll take the hit that Automattic isn't catering to every one of my personal needs as a developer because I understand the core value of the system.
Programmers that only work with “insert any system” will be professionally stunted. The fact of the matter is that if you focus your professional development in any one place, you're doing yourself a disservice in the long-term. It isn't in WordPress' core domain to teach programmers proper object-oriented design patterns. We can just accept that as a reality. If one day they achieve that (and it looks like there's honest effort in that direction), then all the better.
The web itself is “old and busted”. I'm reminded of comments Robert Martin made during a presentation that (and this is my translation) an application is nothing more than a “take garbage in, hope to do something useful, and send garbage out”. Your “enterprise” applications:
- Listen for HTTP messages built on a great specification, that include some jumbled convention-based payload.
- Hopefully translate it to something sane to do some work.
- And finally, decides what it's going to output and in most cases decides to vomit HTML, JS, and CSS to the user's browser.
- My long-winded point is that we shouldn't be allowing any platform to reach its grubby hands into the software we derive value from. I'm not here to argue tribalism. Again, WordPress is “a spade vs. a hand-shovel” in my mind. For the members of the “anti-wordpress-hate-crew” tribe, the complaints above might lead into a holy-war against the platform. I don't draw the same conclusion and here's why:
What if I told you that we can write WordPress plugins without WordPress?
A Clean Architecture is built in layers. It isolates concerns. By striving towards A Clean Architecture, software can be written such that it is independent of the environment it is placed in. This means that we can write WordPress plugins without WordPress! We can focus most of our resources on the primary reason why we thought we needed a plugin to begin with, not the CMS of the day and all the “headaches” related. We can focus on the problems so we may more accurately architect sound solutions. A Clean Architecture allows for plugins that:
- Don't require a WordPress installation.
- Are testable. Have you ever attempted to unit test a WordPress plugin where you're making calls directly to WP's function APIs? It doesn't buy you much.
- Are independent from user interface. No more echoing out random markup mid-logic. No more side-effect-ridden actions.
- Don't require a database. This series of posts are going to focus on a specific user story I've wanted to fulfill with a WordPress plugin for a while. I will be blogging as I develop to help guide the decision-making process; weighing pros and cons and deciding on trade-offs.
In this series, my goal is to shine a light on how we can write clean and maintainable software that just so happens to be running in a WordPress shell. I want this series to display some of the decision-making process when it comes to writing flexible applications. As such, next time we'll investigate a problem area I've faced trying to get into blogging with WordPress. This case-study will be the focus of development for the series. See you next time!