When using frameworks like .NET or Rails, it’s easy to demonstrate how said frameworks were used to build a piece of software. But because of the nature of WordPress, it’s far more likely that people are to treat any project as either a blog or a site powered by a CMS.
In some cases, that’s true; but it’s not a hard and fast rule. Blogs and sites are just two examples of things are can be built (and, honestly, are the most typically built) with WordPress but they aren’t the only things.
I’ve shared my thoughts on using WordPress as a framework for web application development, but this still raises the question: if WordPress is a framework, then what is the software?
Easy: Themes and Plugins. The problem is that the terminology over simplifies the amount of development, level of engineering, and complexity that exists in building them.
On Software Development
I’ve already talked about the typical architecture of web applications (that is, database, middleware, and presentation layer), but the processes that are used to build such software vary.
They consist of various methodologies, design patterns, and so on and can even be segmented more in each layer. Case in the point: The middleware may consist of a service layer as well as a domain layer. The presentation layer can be segmented into markup, behavior, and style.
You get it.
So anyway, an example:
- A team receives a requirements document that is used to generate the scope. Once scoped, the project is broken down into development cycles (using scrum, waterfall, or some other methodology). During development, programmers will come up with an architecture for the application using a variety of diagrams, design patterns, and so on. Finally, they begin writing code. Once done, it launches and then typically enters a maintenance phase.
Obviously, this doesn’t account for other nuances of maintaining a web application such as source control, hot fixes, how to load balance traffic, managing security, etc., and all of the boring stuff, but you get the idea.
Still, the point remains: This is how web applications are built and but themes and plugins aren’t typically viewed as such.
The Disadvantages of “Themes” and “Plugins”
For the most part, I think that the reasons that themes and plugins are viewed as subpar projects is this:
- Terminology. “Theme” sounds like it’s a skin – a way that a website looks – it doesn’t sound nearly as complicated as “software.” “Plugins” sounds like a simple little add-on – a sticker – that’s slapped on to make something look fancy. Granted, this is just semantics but it’s true. Think of it this way: When someone says “script” you don’t think “program” even though, at the end of the day, both are chunks of code that automate a task.
- Low Barrier of Entry. To get into the business of building software – especially in the enterprise – there’s a level of education that’s often required. Usually, it’s a degree in computer science along with experience in working with databases, various frameworks, and experience with client-side development. This doesn’t really hold true for WordPress (this is not a critique!).
- The Platform. Again, WordPress is viewed as a tool for digital publishing or for managing content, not as a framework for building applications. It’s only natural that other software developers are biased against WordPress.
I think that one thing that works against professional developers attempting to make a living off of WordPress is the range of experience of people that are working with the platform.
On one hand, you’ve got guys approaching theme development just as they would a website back in the 90’s – an mishmash of markup and styles that look pretty but offer very little unique functionality let alone offer any type of ability to maintain overtime. These guys have little experience on managing data sanitization or why certain functions need to be called to properly reset variables at the global level.
On the other hand, you’ve got teams that are spending their time loading their themes into a source control system, tracking issues, managing versions, logically segmenting their code based on server-side, client-side, applying design patterns where necessary, considering optimizations, and enhancing the WordPress platform by adding new features to core that are bundled with their theme.
To be clear: I’m not knocking beginners and I’m not praising more experienced developers. I’m stating facts. I’m absolutely an advocate for the beginner every single time (and I spend a significant amount of time writing articles for other blogs to try to help bring them along) and love the fact that anyone can start with WordPress and move up.
What I am saying is this: Because WordPress is viewed as a content management application instead of an application framework and because the range of products built on top of WordPress is so wide, the software industry doesn’t see it as a viable option for building web applications.
The WordPress Application Framework
So what now? If WordPress is to be taken more seriously by the development community (outside of the WordPress community itself, naturally), then there are several things that have to happen:
- Professional Developers Must Share. Developers who are building quality products are going to need to evangelize their work to the rest of the industry. Discuss it on Twitter, setup a GitHub account to share your work, sell a WordPress-based product, blog about the problems you’ve experienced and how to solve it, write software that’s built on top of WordPress. There are a ton of things that we can do, but we need to stop doing so solely in the context of the WordPress community.
- Segment The Market. Because the market is so saturated with people doing things with WordPress, it’s critical that we differentiate ourselves from all of the noise that exists and create more signal. Build quality into your projects, spend time on branding, and speak intelligently about the framework. Talk about WordPress like others talk about Rails or .NET. Attend meetups and educate others on how much can be really be done with WordPress.
No, we’re not going to be able to change the terminology of ‘Themes’ and ‘Plugins’ from the WordPress world – I don’t want that! But I would love to see a shift in which true developers – software engineers, even – are sharing their approach to building software for WordPress using various professional techniques.
All of that said, I’m generally curious on what you guys think. Does the terminology taint the experience with WordPress? Or, perhaps better yet, is there even a chance for WordPress as an application framework?