WordPress Application Framework

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?

Category:
Articles
Tags:

Join the conversation! 17 Comments

  1. “Does the terminology taint the experience with WordPress?”

    With themes, maybe. With plugins, definitely not—at least when it comes to developers. I think WordPress (.com AND self-hosted) has enough notoriety now that novices have heard of it, but consider it a blogging platform. So, pitching a build on it is usually met with a terrible demand to explain yourself. On top of that, plugin development seems to operate in a vacuum—usually having something to do with blogging and little to do with extending the platform. I think the terminology is probably as good as it could be, but WP’s history and reputation have guided it in a more specifically user-friendly (at the presumed cost of extensibility) direction.

    “…is there even a chance for WordPress as an application framework?”

    I believe and hope so. I’ve found more clients are open to this than you’d expect if they’ll give you the time to explain it (and the dev knows what they’re talking about). Noting the obvious plus of having your website content AND application in one administrative area can get a SMB’s attention.

    I built MusicGrid.me on WordPress to satisfy my curiosity about how easily it could be done. Come to find out, not only is it a great platform to build on, but the native functions save more time than I could have ever expected.

    • For terminology, I tend to agree with you. I think that “theme” implies more of a less a facelift or general styles than any advanced functionality even though the latter is relatively common especially in premium themes. For plugins, you’re right – you’re extending and enhancing core. I’ve often considered them “apps for WordPress.”

      And I’d like to think there’s hope for WordPress as a framework or a platform, but it’s completely contingent on developers learning the API and taking it seriously. I think the demand is there but the supply of people to provide high-quality solutions still has room to grow.

      …and btw, killer work on Music Grid :).

  2. Hey Tom, thanks for such “deep” articles about WordPress Dev. I’ve read your latest posts about framework,application dev.
    Internet is full of with WordPress articles “How to do smth”, “10 best plugins for smth” and so on. But we meet such articles rarely. So, WordPress needs you :)
    I have a lot of thoughts about this topic, it is very actual, but my english is not fluent, so i can not explain all my thoughts :)
    Sometimes i suggest to my friends-developers to try using WordPress as framework. I say it has great Codex, very rich functions library, hooks etc. But i get such critic reactions:


    Wordpress is just blog CMS, it can not be compared with any MVC framework.
    It has a lot of initial blog elements,unwanted features for our project.
    Plugin&theme development is just little part of WordPress, but we need zero-platform for developing our projects.
    We don’t want to fight with initial barriers, we don’t want to have additional clean problems.
    Wordpress has post objects in mysql databases. And it is better to create all your objects using custom-post feature. But post-postmeta logic of WordPress is eligible only for simple objects, not for difficult object models with several parent-child grades. Such models can not be managed with post objects of WordPress. So we should create absolutely new objects, new mysql tables and write code for their autonome working inside WordPress. But if we create such models from zero, then what WordPress is for? ”
    You see, there are a lot of critics from friends :) I can not answer to all of them as there is something true inside these critics. What can you say about it?

    • To the points above, I’d say the following:

      • WordPress isn’t meant to be compared to any MVC framework. MVC frameworks, although nice (and I like them), aren’t the ultimate solution to web application development. There are other design patterns that can be used successfully and WordPress provides an alternative.
      • You can easily remove unwanted elements from WordPress using proper functions. The admin menu is fully customizable and you can limit access to features by using user roles.
      • If theme and plugin development are just a little part of WordPress, what are gems in Rails development? What are controls in .NET? Every framework has its “themes and plugins.”
      • I’m not sure what initial barriers are, but again every framework has them – be it selecting which version of a language, database, or framework to use. Every single framework has its initial costs.
      • As far objects are concerned (or models, or classes, or posts – however you want to define them), WordPress can manage hierarchy and relationships just fine through the use of custom post types and taxonomies. Sometimes, it is advantageous to create new tables, but I don’t often do that. I try to let WordPress be WordPress first. If I find myself having to do too much custom work, then either I’m modeling my problem wrong or WordPress isn’t the proper framework. This same argument can be applied to any other platform: If you find the framework is limiting you, you’re either not approaching the problem correctly or the platform isn’t optimal for your application.

      Just my two cents! :)

      • Thanks for your reply.
        These ones were critics from my developers-friends, i gathered all and tried to write all in one comment. :) Of course i don’t think as they think, but as i wrote before, sometimes it is difficult to reply to all such critics, to explain that WordPress just can do it. :)
        Now i feel myself to be able to build any web application with WordPress and i am happy for this. :) Sometimes i use Codeigniter FW, which is my favourite MVC FW. But i do it only when client wants so. You know, some clients are atill sceptic about CMS-es. They just don’t rely to CMS-es.(“-What? WordPress? OMG we are a big company, don’t build our website with some blog CMS, it would be shame for us” :) ) I don’t try to persuade them about WordPress, i just choose CI 2.0 for their website.

  3. Terminology is a large part of coding and engineering. It’s the basis for communicating design patterns and such. So themeing is definitely a black eye (IMO) for WordPress developers when communicating with developers from other domains. Themeing basically means aesthetic modifications. Not even a full graphic design, just modifications at that.

    At one point in time this may have been a proper term for what WordPress hackers did back in the day but now the platform has evolved into more. I believe the term needs to change. It may sound shallow, but marketing is a big part of framework adoption. Microsoft implements marketing as a standard component when bringing languages and platforms like C# and .NET to the general professional public.

    WordPress and the Community should work and agree on a campaign to define the new model of the industry to the outside world (Clients and Other Developers) that distinguishes ‘Themed’ products from ‘Developed’ products. The way things are currently is rather ignorant and unfair to hardcore WordPress Developers. They aren’t making themes,their making applications and should be viewed as doing so.

    • I think that the word ‘theme’ doesn’t do justice to what people are building on top of WordPress anymore. At one point, sure – back when it was primarily for blogging and maybe even more as a CMS.

      But as we get more into application territory, you’re right. Personally, I’m not even a fan of the term “app themes,” but I digress for now.

      I absolutely dig your idea, too – market the platform as the ability to do more than publish and we’ll likely attract a wider audience. The thing is, WordPress is – first and foremost – for publishing so it’s a dilemma, I think.

      Regardless, that’s half of what I’m trying to do here on my site: Evangelize the platform as more, show how at can be done, and attract discussion around it :).

      Also, sorry I’m so late to responding to this comment – missed it first time around!

  4. Thank you for this article. I am researching possible solutions for a web application I am about to undertake and I wanted to know if wordpress could handle a web application. I have done very robust sites using wordpress without modifying the core of wordpress too much but rather, tweaking my templates and extending wordpress functionality. I find that for my clients and even the wider community sometimes look down on wordpress primarily because of the way it has been perceived over the years and in some ways because it is so flexible that users at almost any level can get a theme installed and running it is overlooked that a more experienced user can create powerful experiences within the wordpress framework. It often does take some convincing with my clients but I usually get them to see the light.

    After reading your article I feel more confident about using wordpress for the framework to my next project and I think I will document the process, issues, resolutions etc. and share them along with the final results in an effort to evangelize WordPress’ awesomeness. Thanks again and keep up the great work.

    • Sure thing, Duane. I love hearing that other developers are looking at WordPress as a viable platform for their project.

      I’m currently working on two applications right now both of which I’m building on WordPress. I don’t have the time that I’d like to document the entire process, so I try to do it in short articles here and there, though I’d eventually like to do a full on ‘post mortem’ of how I’ve done a couple of these.

      At any rate, I think you’ll find WordPress to be a solid solution for what you’re setting out to do. Above all else, make sure you have the API in the Codex open – it’s a fantastic reference and it’ll ensure you’re doing things properly rather than circumventing something that may already be there :).

  5. “Does the terminology taint the experience with WordPress?”

    ABSOLUTELY! I’ve only been using WordPress for 4 months and I’m becoming extremely proficient. But the terminology was a very unnecessary barrier EVEN FOR NON-SAVVY USERS!!! Just as a basic blog, WordPress terminology falls flat on its face. “Post types” WHAT??? Its a Content Type, people. Get with it. And “Sidebars” WHAT!? Its a Widget Area or Widget Container or Widget Region. This stuff really added unnecessary adjustment having to research and then constantly remind myself “Its a ‘post’ post-type and this is a ‘page’ post-type.” and “sidebar can appear anyway and take any form”

    Moreover, “themes” are definitely NOT “themes”. This has been a pitfall even for security-concerned people. When you think of a theme, you don’t think of security. But since a theme is capable of doing everything *and more* that a plugin can do, themes ought to be treated with a serious respect as full-on web programs. They should have called them “Platforms” or something more generic or used some goofy double word like “Skin&Codez”

    Seriously, these terms are archaic from the very early days of WP and Automattic would change them if they were savvy enough about making people realize how to properly use WordPress. We’ve got numerous developers who even start out using WordPress all wrong because the terms communicate the wrong ideas about how to use the platform.

    Also, I used Drupal for a while when starting out examining platforms to try. Drupal is an over-engineered heap of metal trying to be all things. And WordPress’s archaic terminology is barring people from realizing that it absolutely blows the doors off Drupal because of its simplicity and open-ended design not trying to be anything fancy. WordPress works well because it assumes you’re going to want to add on significantly or even use it in ways not intended. Its not heavy-handed.

    • Love hearing these thoughts from people who are just coming to WordPress in recent times rather than from early on.

      Personally, I started blogging using WordPress years ago – 2005, if I recall correctly – and did some minor development on it at that time but nothing like that I’m doing right now.

      Anyway, you bring up some interesting points:

      “Post types” WHAT??? Its a Content Type, people. Get with it.

      I’m with you to a certain degree. All types boil down to a value stored in a column in the wp_posts table. Considering that WordPress is a content-management system, I think it’s fair to say that it is a content type, but to the average user, it doesn’t really matter.

      And then for developers, it may be a little frustrating, but it’s nothing more than a nuance once we familiarize ourselves with it.

      And “Sidebars” WHAT!? Its a Widget Area or Widget Container or Widget Region.

      I think that this is another good point in that the terminology doesn’t map to a mental model of the functionality supports. That is, you’re spot on with it being a widget contianer and that they can reside anywhere.

      Instead, sidebar results in this design idea which is something that’s usually relegated to part of the frontend – not something that’s as involved at the development level.

      Finally, I’m on board with themes being significantly more involved that the term signifies. Early on, “themes” sounded like a combination of markup and stylesheets (with perhaps some JavaScript). It sounds too simple.

      The thing is, they are themes – we just don’t think of themes as needing to be as secure or localized or handling the various nuances that they require. And this is precisely why the marketplace is flooded with free, junk themes that end up hurting users more than helping.

      I digress on this point for now :).

      But, regardless, this is the sandbox in which we’re choosing to play so I’m fine using whatever is supplied to us. Besides, overhauling certain things – such as Post Types versus Content Types – would require a fundamental shift in the foundation on which WordPress is built, and that has signiciant potential to wreak havoc on sites using WordPress (especially considering so few people upgrade their installations after getting their site going).

      Anyway, I think it does more damage for people who think it’ “simple” to build on top of WordPress when you often have to be just as security-minded as with building for any other project.

  6. Hi Tom

    Excellent article on WordPress for people who don’t belive it can be used for web applications.

    I am a Web developer and I have experience in working with frameworks like CakePHP,CodeIgniter, Zend before I moved into WordPress. I am planning to write a book on WordPress for Web Application Development.

    So I thought I could ask for some suggestions knowing that you are a well experinced developer. Also I had the chance to get few of my posts reviewd by you in WPtuts.

    I hope you can comment on the following queries.

    1. Can we use MVC in WordPress? at least for a certain extent?

    2. Assume that we are creating forms or lists without using custom post types. How will you load these pages? Do you use custom rewrite rules?

    3. Is there any advantage or disadvantage of using templating engine like Twig instead of sticking with WordPress templates?

    Thanks in advance

    • I’ll do the best I can to offer my answers below (and try to keep them as concise as possible :)).

      You can fake it, but it’s not really an MVC framework. WordPress is more of an event-driven (or publisher-subscriber) model.
      This question is a little unclear to me, but you can use custom rewrite rules, but why not use the built in page types for something like this?
      I’ve never used Twig or any other templating system in WordPress – I’ve never had to. Everything I’ve needed to do as far as “views” are concerned can be done with WordPress templates.

      • Thanks for the prompt response.

        In my second question I meant how we can create custom functionality or layout. Assume that we have a page with a form which allows the users to submit an image, load it on browser and create tags like we do in FB.

        Whats the best method of creating such thing. Should we use a shortcode? Should we use a page template? or write a custom function and call it with custom rewrite rules?

        For the views. Do you mean using get_template_part? For example in shortcodes we use a variable to contain HTML and return the variable at the end. I would like to get the HTML as a template by passing data as we normally do with other PHP frameworks.

        Looking forward to your suggestions.

        • Custom functionality for the layout can be achieved using standards means of markup, styles, and JavaScript.

          Tag functionality can be achieved through a combination of Ajax can however you opt to store that information (tags, categories, meta data, etc).

          I’m personally not a fan of shortcodes, but th that at doesn’t mean they don’t have their place right now.

          And for views, I’m simply talking about setting up templates or template parts – it really depends on the problem you’re trying to solve.

          I feel like you’re asking several questions, but if you’re really asking:

          I would like to get the HTML as a template by passing data as we normally do with other PHP frameworks.

          This can be done by using get_template_part and having various variables already defined and accessible either through functions or through having them stored in some object or even the $_GET, $_POST, or, ew, $GLOBALS.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.