ohryan.ca

A Web Developer in Winnipeg

WordPress Development, Cons & Pros

in ,

About a month and a half ago The Big Webshow featured WordPress creator Matt Mullenweg, listening to the interview it became really clear that WP is trying to position itself as a website “operating system.” While there are probably other platforms much more capable of the task, WordPress’ ubiquity is sort of pushing it in that direction regardless. Since that interview I’ve been meaning to take a closer look at WordPress.

Over the weekend I finally had a chance to dive in to theme and plugin development.
Overall, I found WordPress to be very easy to work with, I didn’t find myself running into any dead-ends like I have with other platforms and CMSes. I thought I’d share my impressions in the form of a pros v cons list.

Cons

  • WP is not model-view-controller framework, as far as I can tell from first brush there’s nothing MVC about it. I’ll admit, I’m not really sure how this would improve theme/plugin development or the application as as a whole. I do think that the WordPress codebase has a lack of structure and organization; MVC is a great way to organize a project.
  • WP is not object oriented. With the exception of the database wrapper, I didn’t come across any objects. Poking around WordPress themes and plugins reveals a bunch of global wordpress functions, things like ‘add_filter() ,’ ‘wp_enqueue_script().’ Everything you’d need to do in wordpress is a function. Exposing everything as a global function leads to the potential problem of of introducing a bug by creating a function with the same name an existing wordpress function (minor annoyance) and again, leads to code that’s hard to follow and disorganized. Function names aren’t always clear, some functions accept a call back, other return a value, etc.
  • WP does not use a template engine, all template variables, functions and statements are included as inline PHP tags. Inline PHP is impossible to read, hard to follow, leads to spaghetti and generates even uglier HTML. Additionally, template engines such as Smarty add useful features like robust caching options. I did find a plugin to add smarty support, may be worth investigating.
  • I really feel like these first three issues are pretty close to PHP’s worst practices. The overall lack of structure tends to generate sloppy, hard to read, amateur-looking code; the sort of thing that RoR snobs like to make fun of.
  • Finally, I suspect WordPress might be highly inefficient (but I haven’t done the research). Specifically the way plugins are allowed to add handlers and filters to various points in the application workflow seems like a problem. If every plugin has to be scanned for on every page load…well that’s just not going to scale well. Each installed plugin (hypothetically) increases processing time.

Pros

  • In spite of, or possibly because of issues I mentioned, extending WordPress is fairly simple and easy to pick up.
  • The documentation at wordpress.org is pretty great! On par with php.net‘s own documentation.
  • With such a large userbase, almost every plugin you could possibly want is already written for you.
  • It’s stable. It doesn’t go down randomly. It’s not buggy.

Admittedly a lot of the shortcoming I found are based on a lot of assumptions and only a basic knowledge of WordPress. Also, I will concede that “your code is ugly” is a fairly superficial criticism that doesn’t inherently mean anything. So, in conclusion, I am not anti-wordpress. I like it as a very-extensible blogging platform, but I’m still a little skeptical about is pontential usefulness as a general-purpose CMS or some sort of website framework.

If you’re a wordpress guru, I’d like to hear you input. Tell me why I’m wrong.

Comments

18 responses to “WordPress Development, Cons & Pros”

  1. Tweets that mention Wordpress Development, Cons & Pros | OhRyan.ca — Topsy.com

    […] This post was mentioned on Twitter by Ryan Neudorf and Jill Lampi, Canadian Tech News. Canadian Tech News said: ohryan.ca – WordPress Development, Cons & Pros http://bit.ly/i70DgG – @ohryan […]

  2. karoumy Avatar
    karoumy

    WP is great for small companies that need a quick site and don’t want or can’t spend a lot of money. It also allows them to manage their own content with only a few minutes of training.

    I’ve hacked a few installs/themes at this point and the code is not that bad compared to what else is out there in the wild.

  3. seanwalberg Avatar
    seanwalberg

    I don’t think you’re too far off, but at the same time, I don’t think a lot of the points are as serious as you think. A lot of the limitations are (from my understanding) because of the PHP4 compatibility, which is supposed to be going out the window soon.

    It’s really easy to do things wrong. If you’re building a serious site (eg, you’re making your company’s money on the site), you take a lot more precautions that negate a lot of what you’re talking about. You vet your plugins, or you write your own. You look at what people are doing to the database and tune/cache accordingly.

    The filter/action system is quite brilliant. Right now I’m developing something that’s going to be a large content site, and I’m able to take WordPress, an off-the-shelf theme, and turn the whole thing into a CMS by hooking in to wordpress. We could switch out the theme and have the same functionality, including URL rewriting. It’s not MVC, but it makes things a lot nicer and easy to maintain.

    I go back and forth on the template thing. The loop variables are really template variables, you just don’t have an intermediate format that most template variables use. So moving to something like Smarty wouldn’t help a lot. When you understand the template hierarchy, you can separate your concerns a lot so you don’t have one gigantic index.php file.

    I’m not a guru, but I’ve been the systems administrator for a large blog network and have been called in to fix performance problems with several blogs so I’m not inexperienced. I’m only starting to get into the development side. I’ll still take Rails over WordPress in most cases, but at least for the project I’m working on now, WordPress was an easy choice over a custom RoR app.

    1. Avatar
      Anonymous

      Thanks for the input. Your point about php4 computability makes sense, I totally overlooked that.

  4. Matt Wiebe Avatar
    Matt Wiebe

    Good post Ryan. It’s always good to hear from an experienced developer new to WP.

    Many of the cons you’ve outlined above are (as your first pro admits the possibility of) by design: WP’s central goal is to empower the masses to publish, not to make developers happy.

    Using PHP functions for template tags is sloppy in one regard, but also good because there isn’t the additional processing needed for a template engine like Smarty, and using PHP gets people new to any programming to dip their toes into the programming water ever so slightly. And the fact that it isn’t MVC makes it much less intimidating to get started. This is exactly how I got started: hacking on template files.

    One other note: there’s a lot more object-y stuff going on than you’d think, just with global functions as template tag front ends. wp_enqueue_script, for instance, interfaces with a WP_Scripts (extends WP_Dependencies) object.

    Every installed plugin does increase processing time, sure. Depending on the plugin, possibly a lot. But the overhead for most is trivial, and there are ways to keep it lower.

    Once/if you get over MVC and template purity, WP can be a joy to work with. Powerful, extensible, easy to work with, and a massive breadth of plugins and resources out there. And a pretty helpful community.

  5. Bryan Watson Avatar
    Bryan Watson

    First off, excellent post with solid insight.

    I do however have a couple issues with the cons list, and even one in the pros list.

    For starters, I don’t consider the lack of a MVC pattern a con in any sense. WordPress had humble beginnings as a very simple, procedural based blogging platform. It was never designed to be a robust CMS. As the community drove WordPress to verge in the direction of opening up into a full CMS, it was still required to be that simple blogging platform that everyone knew and loved. Due to this, it’s impractical that WordPress would use a MVC pattern in terms of templates and plugins, as that’s one of the main benefits to choosing this platform.

    The interpretation of the efficacy of WordPress depends on the personal preference of design models. WordPress uses a “bottom up” approach, starting at a blog and extending itself into more CMS like functions. Other CMS’s like Joomla or EE take the opposite approach, and do things in a “top down” manner. In contrast, it takes quite some effort to emulate what the default WordPress theme does out of the box with a Joomla or EE template.

    My second point is the simplicity of WordPress’ template processing is what makes WordPress such an appealing platform. Designers and developers with little PHP and MySQL knowledge can easily create a robust WordPress theme that outputs very clean and semantic HTML. I would easily argue that a well formed WordPress theme will output much better markup than a similar Joomla or ExpressionEngine template.

    Third point is actually listed in the pros list. Saying that the WordPress.org Codex is “on par” with PHP.net’s documentation is a slap in the face to WordPress.org. PHP.net has always had terrible documentation, especially in terms of navigation and location of relevant data. I do agree that WordPress.org has excellent documentation and support, I just really didn’t like the comparison to PHP.net 😛

    1. Avatar
      Anonymous

      Good points, aside from your jab at php.net (but I’m not taking that bait:P).

      “I would easily argue that a well formed WordPress theme will output much better markup than a similar Joomla or ExpressionEngine template.”
      Wordpress doesn’t really do anything to the markup, does it? I mean, most of the WP functions are purely content output, right? The markup would be entirely dependant on the developer’s ability to write HTML.

      1. Bryan Watson Avatar
        Bryan Watson

        The majority of them let you control the specific HTML output through arguements, but some functions like wp_list_comments and wp_head can have some unexpected results if you don’t clean them up in functions.php.

        That was statement was only put in place to rebuttal this:

        “Inline PHP is impossible to read, hard to follow, leads to spaghetti and generates even uglier HTML.”

  6. Mmapes Avatar
    Mmapes

    I’m a php programmer thrust into wp development for a client. I kinda hate it. Global variables, functions that draw directly to the screen… I’d never use it from scratch on a project. That said, if you only use it as-is and don’t need to control it, it’s not half bad. I’d recommend it for clients with simple needs.

  7. Dan Bernardic Avatar
    Dan Bernardic

    I think that your impressions of WordPress are very similar to mine when I started using WordPress. And I think that also reflects what conclusions a programmer has when they first see WordPress.

    Here’s an example that might express why the WordPress way IS better than what an average programmer might think, although that might not feel intuitive to the programmer when he first sees WordPress: You know how all your database tables should be normalized? Well guess what? The default MySQL table engine does not support foreign keys at all, and MySQL is an extensively used dbms. Take that Database course…

    I’ve learned to love the fact that there is no object-orientation and no MVC structure to the system, although I probably come from a similar professional education background as you do. There is however a bit of object-orientation in the system, but it is abstracted from the theme designer/plugin developer. This abstraction layer is really beneficial, because always beats getTitle() ?> at least on the character count. How would you explain to the designer or the hobbyist why they have to use Post::getNumberOfPosts(); instead of$post->getNumberOfPosts()?

    It’s interesting also that Sean brings up the comparison between using WordPress vs. RoR, which has been a topic in my thoughts, and I will be presenting on “CMS vs. MVC” (with probably a different title) at the Winnipeg Code Camp on Feb 26th.

    Here’s my top 5 for why WordPress beats any MVC framework for building websites:
    1. Available plugins
    2. Familiarity of admin interface for in-company administrators
    3. Designers can build whole sites
    4. Hobbyists can build whole sites
    5. Content types don’t need a new table

    1. Avatar
      Anonymous

      “There is however a bit of object-orientation in the system, but it is abstracted from the theme designer/plugin developer.”

      I thought that might be the case.

      “This abstraction layer is really beneficial, because always beats getTitle() ?> at least on the character count. How would you explain to the designer or the hobbyist why they have to use Post::getNumberOfPosts(); instead of$post->getNumberOfPosts()?”

      True. But something like {$theTitle} (as it might appear in a Smarty template) would be even simpler.

      Re: your top 5
      1. This is really only due to it’s popularity, not (necessarily) it’s structure.
      2. True. but again, partially because it’s popular, partially because it’s well designed.
      3+4. True.
      5. You could do MVC with one table (though that might not “technically” be MVC).

      1. Hal Avatar
        Hal

        Sorry to be late to this but I was researching something else and hit on this. Someone needs to correct some gross mis-statements. The core of WordPress is actually totally OOP. Does anyone look at code any more, or just at some core filenames? And while its very true this is “abstracted from theme developers”, plugin developers are often pointed to extending some of the core WP classes. The abstraction is done as convenience to make life easier for designers, who typically are not programmers and don’t need to understand the lower level stuff. In fact, its quite handy to extend the core db class ($wpdb). 

        A partial list of core WP classes turned up with a quick grep:WP – This is the entry point to Wordpreswpdb – database classWP_Object_Cache – built in object cachingWP_RolesWP_UserWP_HttpWP_Http_StreamsWP_Http_CurlWP_Http_CookiePOP3SMTPWP_ErrorWP_ScriptsWP_StylesWP_WidgetWP_Widget_Factorywp_xmlrpc_serverWP_EmbedWP_Meta_QueryThat’s less than half of the core classes in WordPress. Indeed, the guts of WP is done with OOP. On another point, WordPress scales fantastically. The #18 trafficed site on the internet is WordPress.com, which is indeed … WordPress. When you need that kind of scale, you do proper caching and server deployment, but that is certainly doable. WordPress has everything built in to handle that kind of scale. To assume or imply otherwise is naive and just plain stupid.

        Lastly, WordPress is underrated as a CMS. It does this fantastically. Its sometimes takes a little more code at the theme or plugin level, but when you control the code, you have more control and makes for a better finished product.

        1. Avatar
          Anonymous

          You caught me, I hadn’t dug into the core code. 
          I like what you said about OO and the connivence functions. It’s true that not making designers learn code is probably key to wordpress’ success. Regarding scalability, the fact that wordpress.com is the #18th most popular site on the web doesn’t really speak to it’s scalability. They may be throwing a tonne of hardware at it, who knows. Could you point me to any articles about scaling wordpress? 

          I still maintain that wordpress is not a great general purpose CMS, but I should expand on that. 

          1. Hal Avatar
            Hal

            Sorry for previous post formatting, it did not survive well…

            I did read something on their architecture. I can’t find that now. Like any highly trafficed site, the more caching you do the better it is for both the client and server. You really don’t want to do sql queries on every page load just to repetitively draw the same nav menu structure. That’s a waste. WP.com uses  object caching via memcached (like Facebook does), and reverse proxying using nginx (which also caches). Looking at their source, I can see they also use CDN type delivery for a lot of the static content (css, js, etc), which is on a server optimized for static content.

            With proper caching, you are serving what is essentially static pages (no need for php calls or sql until the cache needs to be rebuilt). With nginx and memcached, you are serving those static pages direct from memory and not the file system. 

            That’s the gist of what I remember. 

            WP provides the tools to provide complex, interactive content and to build the cache (in this case), and connect it to the cache when that needs to happen. That’s all it needs to do, really. A similar scenario would apply to Drupal and Joomla, or what have you. The core system provides base functionality, but does not need to provide it raw on every page request. There are just better ways to do that.

            Does every WP install need caching? No. Would every WP install benefit from caching? Yes. In some hosting environments that are over trafficed (like godaddy), you have to use it. On my VPS, where I have plenty of CPU cycles, plenty of RAM and properly configured Apache and MySQL, my WP sites are very responsive. (I still cache because the faster, the better, IMO. There are plenty of plugins that do this all very easily.)

            WordPress.com hosts over 20 million blogs. At a certain point, you have to throw some hardware at the problem.  As to the “tonne of hardware”, sure you could do that. But would you or I do that? Or would we write better code and do best hosting practices to save a hundred servers or whatever it would be? And if you were Matt Mullenweg (http://ma.tt), the php developer that started WP and now “owns” it, would you just throw hardware it, or would you save the expense and architect around the problem? 

            My original point is that WP can and does scale to any place you want to go. But its part of a tool chain at a certain point, and not the only link. 

  8. PHP Development Avatar
    PHP Development

    WordPress is really good platform for blogging. It is seo friendly and many useful plugins available.

  9. Avatar
    Anonymous

    Simply wanted to say good weblog, that I learn it every now and then

    kingston florist
    Baltimore flower delivery

  10. php website development Avatar
    php website development

    word press is  best for open source cms website development, and it’s easy to customize many application.

  11. AllistairSimmons Avatar
    AllistairSimmons

    I have a same que here I’m a php programmer thrust into wp development for a client. I kinda
    hate it. Global variables, functions that draw directly to the screen…
    I’d never use it from scratch on a project. That said, if you only use
    it as-is and don’t need to control it, it’s not half bad. I’d recommend
    it for clients with simple needs.

Leave a Reply

Only people in my network can comment.