in Web Development

3 CMS’s: WordPress, Expression Engine and PyroCMS (the 100,000 foot view)

For my day job, that pays the bills I’ve been looking at a few content management systems (CMS).  Our current CMS provider, in my opinion, has lost their way. So we’ve been looking at other options.  In doing so I have been looking at three CMS’s that I’m most familiar with by name.  There are a ton of CMS’s out there, it’s big business theses days, but here are my thoughts on these three.



WordPress – This is the big dog in the room. It’s also what this blog runs on! WordPress is, in my opinion, the de facto blogging platform.  Over time they have been transitioning to becoming more of a framework so that it’s possible for people to build web sites upon their framework.  Automattic that parent company of WordPress is making a ton of money off of doing this by hosting the likes of CNN and Sports Illustrated and many other’s that I’m not familiar with.  As part of my evaluation I’ve been trying to build a simple plugin/widget that displays a JSON feed from Rotten Tomatoe’s API.  I’ve ‘hacked’ a few things on WordPress from the plugin aspect, but I wanted to do it correctly.  I found a tutorial here,  here and here and read through it a couple of times.  Things were going well up until I hit part 2 and 3 and I gave up.  I will be going back to this as I think there’s a huge opportunities on WordPress, but compared to what I have programmed with before it’s quite the mind bending trick.

ExpressionEngine (EE) – I’m not exactly sure where I first became familiar with this CMS, but I suspect it was about the time that I discovered CodeIgniter.  I haven’t had the opportunity to write a plugin for this so from that aspect I can’t comment.  But from the aspect of setting this up for a news like site, I think it’s pretty straight forward.  Creating a new section, is done fairly quickly, but also allows for some custom page settings.  My one thing about this is that the company behind EE as of late hasn’t been all that forthcoming with their changes and when they do come they just happen.  I think the latest go around has finally settled down, but it makes me a bit nervous when things like this happen and the community goes into an uproar!

2/4/2013 – Please see the comments/conversation below from Phil and myself.  Phil has brought up some information that I was not aware of and makes a very good point that merits further consideration.  As I stated above this is a business decision that I’ll be involved in and will have to make for the business that employs me.  Taking that perspective out of the equation, so on a personal aspect, I feel PyroCMS is worth considering as it sounds like Phil has a plan in place that will lead this product forward with as little inconvenience as possible.

For now I’ll leave the original post in contact, which you see below, but I may remove this as some of my opinions have changed with information Phil has kindly commented on below.  Please perform your own evaluations and get to know the products as much as possible. 

This is a CMS that got it’s start as Phil Sturgeon’s personal CMS for his customers.  However as the need grew he released it to the public.  It’s a great little CMS. It is currently mostly built on CodeIgniter, which I like, but is making it’s way to Laravel.  Which brings me to my main concerns on this platform. It’s actually not the platform it’s Phil.  This is nothing against Phil, in the few conversations I’ve had with him, he’s been incredibly gracious if a bit abrasive at times.  Any how my biggest concern with this CMS is that in my opinion Phil tends to chase the shiny and new things.  While this isn’t entirely a bad thing, I don’t think it pays in the long run to make such dramatic shifts in the foundation of the CMS every couple of years.  I’ve asked this to the team and as of yet have not gotten a response.  Despite all of that when I did my plugin/widget/module test, it was quick and easy to write.  A lot of that has to do with my knowledge of CodeIgniter, but I think someone who’s remotely familar with MVC structure would get it fairly quickly.

This is a very high level over view of three CMS’s that I think are all worth considering. Some good, some bad.  No decision has been made at my place of work and I’m not sure when it will be made.  Right now, if the decision were up to me, it would come down to WordPress for the fact that there is so much already built but would take a TON of hacking to get into a news site (beyond a blog).  And ExpressionEngine is the other one.  I need to explore it more, but it just feels right and something that could be put into play very easily.

Do you have another CMS that you’d recommend?



  1. A massive thank you for including PyroCMS in y our write-up.

    I hope this doesn’t sound defensive or aggressive, but I feel that I have been misrepresented in this article, which in turn is detrimental to the reputation of PyroCMS.

    I don’t think that at any point in my career I have said or done anything that would suggest I “chase the shiny new things”. I was developing for and with CodeIgniter a LONG time after it stopped being “cool” because it was a useful product and the low portability meant PyroCMS could be installed on a large number of servers.

    The move to Laravel 4 is a difficult one, but we have amazing backing from our community for doing this. Changing the framework flippantly would be ridiculous, but sticking with an aging framework which is incapable of allowing us to hit critical goals for the development of PyroCMS would be even more ridiculous.

    The change to Laravel 4 gives us not only a Composer-built base, but makes us PSR-1 compliant (which as PyroCMS is a voting member on the PHP-FIG is rather important), but also allows us to add some amazing features which just aren’t possible in CodeIgniter. CodeIgniter has its flaws, which I have explained in this blog.

    Each change that happens to the codebase moving us towards Laravel (which is spread over multiple versions) gives us a huge benefit. We’re replacing the old Ion Auth system with Sentry 2.0 – which gives us Bcrypt passwords, multiple groups for users and a lot of other security features. That and because Sentry 2.0 is entirely framework agnostic, we can expect to see PyroCMS integrations with other systems that use Sentry 2.0 – which will be AMAZING. Imagine out of the box integration with something like FluxBB without even trying?

    Switching from CI’s ActiveRecord to Eloquent and Fluent gives us a much less bug ridden DB abstraction layer (trust me, PDO was broken as hell) and of course adds an amazingly lightweight ORM to the base.

    By the time we get to 3.0 and we’re using Laravel in general we have an IoC container, not only meaning we can stop the old-style “tightly coupled” approach to CodeIgniter loading and use proper Dependency Injection, but we can write unit tests for every part of the codebase – even the controllers!

    We made the choice to move to a framework over multiple versions, recoding parts at a time in a manageable way over time, and it’s entirely reasonable and achievable. We’re not just throwing the baby out with the bathwater and starting from scratch, we’re making changes over various mile-stones that help achieve goals that we cannot achieve otherwise.

    CodeIgniter WAS great, but it’s aged badly and has no real future next to modern component-based packages. If we stick with it for the sake of sticking with it our codebase will stagnate and the project will die. EE and WordPress are too big to change and eventually they will die out too if they cannot keep up with PHP versions. PyroCMS is obviously smaller and has the chance to make these changes, which in the long run are much better for the community than the other option: doing nothing.

    It’s a shame this was the focus of your review, as I think PyroCMS is a quality CMS in its own merits, and is not just a product that happens to sit on CodeIgniter. The change is supported by the developer community, and the end-users (non-developers) will never notice a difference – so this really should not be seen as such a big issue for the product.

    • Phil – Thanks for stopping by my little piece of the internet. I’m not sure what my words here will do, but I’m going to put them down anyways. They may help, they may not. I hope that they do help.

      I think a lot of it tends towards view point/perspective. I have the utmost respect for you and what you’ve done for the PHP community/CI and various other areas I’m probably not aware of!!! I understand the move away from CI and the move to Laravel. Didn’t at first, but I learned more from the post that you put up both on your site and the PyroCMS site. (I haven’t gotten deep into Laravel as my code base is in CI). My concern is this. What happens if Laravel is no longer maintained or falls behind the ‘schedule’ (basically the reason’s for why you’re moving away from CI)? Taylor, if I’m not mistaken, does this on his own/extra time (I’m guessing money from this project only comes in the form of donations?)? I’m not saying it will, but lets say it does hit this stage? What then? Everyone who has switched from CI to Laravel is now rebuilding everything again to new framework 3 (there was another comment along these lines on the blog post about moving to Laravel that wasn’t addressed. Comment by Alexander Cogneau on 2012-12-02)? I unfortunately don’t work in a business where I can, over time I realize, go about learning a new framework every time it’s thought of as not keeping up (I understand the concerns about being behind etc.)?

      For me personally and from a development aspect, I like PyroCMS the best of these three frameworks ( most of that has to do with my knowledge of CI ). I think it’s got some growing up to do, but it will get there. From a business aspect, which is where I’m coming at this from in this post, I feel there may need to be some more introspect on the direction of the product so others can get on board (granted many have already gotten on board). If I could sum it up I’d say this: Less tech talk and more leadership in what’s going to happen should the above happen and other things. I think this is what the blog/podcast needs to convey. I know this is a lot of looking into the crystal ball of the future, but that’s what I’m looking at when I’m deciding on a CMS for a business. Additionally I’m one person.

      Again these are just my opinions/thoughts/mumblings. And lastly FWIW, I’ve still not recommended or made a decision on a CMS to use for my company.


  2. What happens if Laravel is no longer maintained or falls behind the ‘schedule’ (basically the reason’s for why you’re moving away from CI)?

    Laravel 4 is a series of PSR-1 components. We’ll be using Laravel mainly as a wrapper, and we’ll use their Validation, ORM, DB abstraction layers. If they vanish those components do not just disappear, they will live on. We’ll also be using Symfony components, Zend components, and components from 3rd parties like Cartalyst who make Sentry 2.

    This is how open-source works. If Cartalyst stop developing Sentry 2 then I’ll fork it, or switch the user system to another user provider. If Taylor stops working on Laravel then I’d assume that UserScape and the community will continue to maintain it, or a fork will happen. None of these are problems.

    Right now CodeIgniter is NOT progressing and hasn’t done much of anything in the last few years. CI 3.0 is a nice improvement on 2.x, but EllisLab have not put any work whatsoever into CI and even EE is using 2.0.x, which is… ridiculous.

    Taylor, if I’m not mistaken, does this on his own/extra time (I’m guessing money from this project only comes in the form of donations?)?

    Taylor works for UserScape, who sponsor the development of Laravel as they use it for their core products. Unlike EllisLab who do not want to spend any money on CodeIgniter and have no interest in their framework progressing for fear of it breaking their core product, UserScape are very keen to continue making Laravel better.

    But saying Laravel development comes only from donations is wildly inaccurate.

    Less tech talk and more leadership in what’s going to happen should the above happen and other things.

    We have a very clear vision of where we are taking things, and the switch to Laravel is just one step in making that happen. We don’t want to be a bunch of nerds talking about tech gibberish, but without a stable foundation for our product we cannot expect to make the improvements we need to make.

    Commercial support, improved documentation, enticing more theme developers, and the rest are all being worked on by the rest of the team while I spearhead the 2.3 Eloquent conversion with a few smart developers in the community.

    We’re getting better every week, and the reason I keep saying “we” is because we’re a strong team with a great community, who know what we’re up to to make PyroCMS excellent. The CI -> Laravel move is unfortunate, but the conversion is so staggered that it’s not the “major issue” a lot of people think it is.

    I speak very “matter-of-fact”ly which im sure is why I am often considered abrasive, but I appreciate the open and honest discussion we’re having. I am explaining respectfully, and not “arguing on the internet”.

    • Phil – I appreciate the frank discussion and you’ve given me some thoughts that I should take into further consideration. I’m nearing the final stages of my evaluation on these CMS’s. I’m not sure where it’s going to come down but you do bring up some things in regards to proceeding with EE that I hadn’t considered (this is where I was initially headed in our decision).

      I didn’t know some of the things about Laravel that you pointed out and that has definetly helped.

      Thanks again for your thoughts and sharing.

Comments are closed.