// you’re reading...

featured

Expression Engine 2.0 Powered by CodeIgniter Coming Soon

At South by Southwest a few weeks ago, Ellislab gave a preview of the new ExpressionEngine 2.0.
The demo shows the beautiful new backend in action, with some top-notch new features (I particularly like the full-screen editing).

However, the main announcement that stood out to me was this:

The big news of the day in my mind, is that ExpressionEngine is now built on CodeIgniter. The implications here, whether you are a CodeIgntier-er, or an ExpressionEngine-er are substantial, and I will write a bit more about these in the upcoming weeks, but sufficed to say that this is very good news for everyone involved; EllisLab, and end-users.
- Derek Allard

At this point, most of the CodeIgniter community were very curious as to what that actually meant. Some of us (including myself) even thought that Ellislab had produced a new version of CodeIgniter (possibly 2.0) to give them the flexibility required to build ExpressionEngine.
However, to many people’s suprise, Rick Ellis posted in the CI Forums:

I’m amused by these threads. Our dev version of EE 2.0 is running on basically a stock version of CI.

This shocked me in particular. By standard, CodeIgniter doesn’t have a very nice way of rendering partials, or running another Controller’s method.
For example:

<h1>This is the homepage</h1>
<div><?php run_controller('blog/latest'); ?></div>
<div><?php run_controller('store/featured'); ?></div>

I thought that this kind of functionality would have been key to allowing ‘blocks’ in the front-end templates.
I guess we’ll just have to wait and see.

What do we know about EE 2.0?

  1. ExpressionEngine 2.0 will be built with CodeIgniter as its new underlying architecture.
  2. It may cost more: “While our final pricing decisions have not been made, we expect that there will be a modest price increase”
  3. ExpressionEngine 1.x addons will need change to make them 2.0 compatible:
    “Although third-party add-ons for the 1.x version of ExpressionEngine will not work with 2.0, the changes necessary to make them work are minimal. We will provide a list of add-ons that have been updated for 2.0″
  4. “ExpressionEngine 2.0 will be released in the summer of 2008.”

Derek Allard - Very much the CI’s community go-to guy at EllisLab posted a very comprehensive entry on the ExpressionEngine Blog explaining what EE 2.0 and CI Integration means for us all.

It’s a great post, and worth reading. From this, we can see that CodeIgniter will be updated inline with ExpressionEngine, and will finally contain a default javascript/AJAX library (using jQuery).

There are also exciting things in the works for CodeIgniter that aren’t yet in the public repository (because they aren’t done yet, not because we won’t share). The most exciting of which is probably the brand new javascript and jQuery libraries, which will provide simple, programatic ways to write complex javascript code. It means you’ll have a simple, CodeIgniter way of creating rich javascript functions. You don’t need to be a javascript guru, but you can be.

Oh, and we understand that some people may have their own preferred javascript libraries. The new JavaScript library in CodeIgniter allows you to extend it to use your own. Its all abstracted. You like Scriptaculous, there’s room for a scriptaculous driver. You like Mootools? You can build a driver. Think of it like the database library. You say “hey CodeIgniter, do this… here’s what I’m using - you figure it out”, and CodeIgniter does. It’s smart like that.

Sounds exciting right? - Abstracted javascript within the framework is always going to get my motor running!

The Business Logic

The idea of building 2 separate products which naturally have a great deal of shared functionality has always seemed strange to me. But I think the main reason this situation came about is because of the history of Ellislab’s products.
ExpressionEngine has always been their core product, and has evolved over several years from the previous versions of pMachine.
Then, CodeIgniter was released, which used many of the components of ExpressionEngine, but was very different in terms of its application flow and structure. Over time CodeIgniter grew more and more popular, with new features being released in every version.
I think it was at this point that Ellislab realized that now is the time to give this framework some serious attention and use it to power their core product.

This move makes sense for so many reasons. And, I believe it will actually increase sales of ExpressionEngine by a substantial amount.

Another huge issue is the community that flocks to Ellislab’s products. Over the last 6 months especially, the CodeIgniter has seen a real boost in community contributions and dedicated community members. Many of us practically live, breath, eat, and sleep CodeIgniter.
Merging their 2 flagship products will also allow both the ExpressionEngine and CodeIgniter communities to benefit from a greater sense of social cohesion. Bound together by their passion for what is essentially the same product.

There are some excellent CodeIgniter developers around, and I mean, they are amazing at what they do. But many of them, including myself, have not really had a great interest in ExpressionEngine. There are a number of reasons why this happens. But mainly, it’s down to the differences between CI development and EE development.
With both products now seamlessly linked, CI developers are much more likely to turn to ExpressionEngine for a commercial CMS.
After all, ExpressionEngine development will now be ‘natural’ to their current way of doing things.

The Deciding Factor

ExpressionEngine has always been a commercial content management system. But, they do have a ‘free’ version for non-commercial use.
I have downloaded and installed this free version, but for me it didn’t do enough to warrant migrating this, a wordpress site, over to EE.
One of the things that was lacking in the free version was the lack of ‘page’ management, which is included in the paid version.

I will always pay for a product that does a really good job. But, with my site here, I do not advertise, all the content is free, and I make no money from this site. So $100 is a little steep considering wordpress does many of the things that the ‘personal’ paid EE version does.
And then there’s a $20/year subscription fee to get updates (which is quite reasonable).

We already know that ExpressionEngine may see a slight rise in price, which is expected when one considers the wealth of new features we’ve seen. But, I think that Ellislab will attract more users if it expands their free version to contain just a few more features.

This may seem like flawed logic: Making your free version even more feature-rich. But, marketting guru’s all agree that the more people you can get using your product for free, the more will convert and ‘upgrade’ to a paid version.
If I started using ExpressionEngine for free, and it did most of the things I wanted it to, then I’m more likely to shell out the cash for the paid version to expand the functionality of my system. But, to get me to use the free version in the first place, it must compete with other free products that exist in the open-source world.

Don’t get me wrong, if I was building a site for a client, and had a budget for it, ExpressionEngine would be top of my list. But I think that Ellislab could see real growth by competing on a free level with other open-source projects with the goal of generating more paid conversions.

So, there it is: ExpressionEngine 2.0 - How it works and what it means for us.

Edit: You can also watch the Ellislab SXSW 2008 Session if you missed it

Discussion

3 comments for “Expression Engine 2.0 Powered by CodeIgniter Coming Soon”

  1. I don’t think that this functionality is desirable, let alone needed.
    From my point of view, controllers use models to assemble information/data; modify it (if necessary) and then call a view to do all things related to presentation.

    Using run_controller() you’re calling a controller to fetch specific information (e.g. sidebar-content) to fill a part of the view. This breaks the MVC-pattern because the view is assembling information (which is the primary job of controllers; not views)

    Don’t get it? :p watch the scheme @ http://www.cubiso.nl/pr/haughin_runcontroller.png

    Posted by Jakob Buis | March 23, 2008, 9:57 am
  2. I see what you’re saying.
    But I tend to keep a controller to a specific set of tasks.

    So, in an ‘Account’ controller, you still may wish to display a list of blog items, which should really be controlled by the blog controller.

    This is where things get a little awkward if you stick to strict MVC.

    Posted by Elliot | March 23, 2008, 10:32 am
  3. Definitely true, why didn’t I think of that factor?
    *slams head on keyboard*
    Controllers should organise information, but not every bit of information needed: that would make a controller a dynamic extension of one view…

    I’m totally convinced that we need run_controller() now :P

    Posted by Jakob Buis | March 24, 2008, 6:29 am

Post a comment