EE Insider

Brandon — 23:23 on 01.17.2012

Their reasons don’t really make a whole lot of sense. What sort of innovation are they referring to that EE can’t handle, and handle easier?

Steven Hambleton — 23:28 on 01.17.2012

I wonder what hosting and uptime issues they had as well as infrastructure?

Did they speak to EllisLab first?

What does EllisLab think about this? Do they plan to speak to Grist so they can address any issues going forward?

Tom Stoecklein — 00:06 on 01.18.2012

Their reasoning is kind of nuts, to be perfectly frank.

Wordpress and EE are, and keep in mind I’m speaking rather simplistically here, are effectively equivalent in terms of one’s infrastructure needs. If there was a problem, without actually taking a peek under the hood, I’d put my money on it being one with their setup and not the application running on top of it.

And at risk of offending the legion of WP fanatics, it sure as hell isn’t at the cutting edge of web technology. If that’s what they were aiming for, they should have built it on top of Node.js with a super awesome NoSQL backend and a killer REST api that serves the dual function of giving you a good ‘ol fashioned reach around whenever the mood is right along with handling all sorts of data goodness.

All kidding aside (and as much as I am absolutely in love with Node… please don’t assume I was mocking it), the idea of basing your decisions off of what’s “hip” seems counter-intuitive to me. Figure out your needs, and then determine what works best from there.

My guess? They had troubles dealing with their hosting infrastructure, were sold on the Wordpress VIP package (if I recall from an article I read last year, they have quite the sales team assembled) as the solution thanks to some super secret magic hosting juju baked inside, and then justified the need to switch to WP based on marketshare. I don’t really think it was an issue with EE per se.

Steven Hambleton — 00:11 on 01.18.2012

This should be an opportunity for EllisLab to learn something and educate current and potential switchers on how most of these reasons can either be overcome or prove they simply don’t exist at all.

Microsoft seem to be drumming up a lot of PR with their on the spot comparison of the speed of a Win Mobile 7 and other phones to show that they can hack it in terms of speed.

Why not take the top 10 objections of people who have considered EE but lean more towards WP and use it as a PR/Educational exercise?

Then throw a few extras the other way

Natetronn — 01:46 on 01.18.2012

Tom Stoecklein cracks me up!

Tom Stoecklein — 02:08 on 01.18.2012

I’m here all night. Not my fault those WP people are using a database setup built on an idea first dreamed up by some weird computer science professor with bell-bottom pants while watching the freaking Love Boat in the seventies. Totally not cutting edge.

Granted, we use it too but at least the EE community is cool.

holger — 05:29 on 01.18.2012

I’m working with EE and WP (5 resp. 3 years). EE isn’t perfect but in my opinion WP is a pile of junk with a messy API. Good luck for the guys…

Matt Perry — 06:16 on 01.18.2012

Hey guys,  It’s Matt here from Grist.  I appreciate your comments on our switch from EE to WP, so I thought I’d add my 2 cents, and maybe issue a bit of an apology.

First the apology.  We’ve loved being a part of the EE community over the past few years, and plan on staying active as both EE/CI users and coders—we still have CodeIgniter apps in production.  So—if our announcement sounded overly-brusque or dismissive of Ellis Labs or the community in any way, please know that it certainly wasn’t meant that way.

And now the 2 cents: 

I can tell you that our decision was not guided (in the least!) by the desire to be “cool” or cutting edge (we are so not!)  And while it’s undeniable that there is a large amount of news innovation (which, as opposed to platform innovation is the sort of innovation I was really talking about in my post) going on in the WP community, it does happen elsewhere too.  Rather,  I think the second of our two reasons above is really closest to the heart of why we made this decision.  We are very very small, and our audience is ever-increasingly large.  So in a way (minus the implication that WordPress has much of a sales team) Tom Stoecklein is right—but only to a point.

Two things ended up tipping the scales in the end for us.  These were:

- the availability (or not) of highly managed, platform-specific enterprise hosting. EE does not yet have a comparable, truly enterprise-scale hosting solution for media companies in particular (see http:vip.wordpress.com)

- Weaknesses in EE’s caching layer and scaling.  This is where Tom and I part ways.  In my experience,  EE’s caching layer is immature relative to the competition.  Its built-in caching mechanisms are inefficient in enterprise settings, including in load-balanced environments in which it is highly wasteful. Most of its built-in caching is duplicative or harmful in the presence of a properly configured DB-layer, or a good reverse proxy.  We know this by occasionally-bitter experience, and have really actually come a along way in scaling EE to a at-times extreme extent.  We even wrote the only memcached caching add-on for EE (http://gristlabs.com/ironcache).  Tellingly, its a port of a wordpress plugin called BatCache.  Thanks to this, and reverse proxies, Grist under EE had good uptime and snappy response, but that’s because we’ve invested heavily in scaling.  This is something we can no longer afford to do, and something that I’d argue it’s in the best interests of the EE community to solve for its high-traffic users—particularly those with the sort of high-spike, slashdot-prone, wide-spectrum traffic typical of large media sites with many years of archives.

Were we a larger organization we may have been able to commit the resources needed to continue to think about these things (hosting/scaling, caching.)  ProPublica, who you mentioned Ryan, is a great example of a media shop that’s been able to grow successfully on ExpressionEngine for years now—and we have much admiration for those guys (Al Shaw shout-out!)  So every situation is different.

I’ll add one final thing—and perhaps I’ll do so at the risk of opening a bit of an endless, tired debate, but here goes:  WordPress is open source software.  As an EE developer, and someone who at this point is very familiar with large parts of the core, I would have been very happy (I still would!) to contribute code to help the team address some of the caching and scaling weaknesses we’ve encountered with EE.  Needless to say, I can’t suggest or submit patches to EE’s core, (and I know about EE reactor, etc etc …)  In any case, for me personally this aspect of the business model/culture was also a factor.

I want to end this note with more of the love—EE is still the CMS I know the most about.  We are very proud to have powered Grist on EE from April 2009 until two days ago, and we have nothing but great things to say about the community of developers and designers that surround Ellis Labs and its products.  So please keep building a great product and an even better community … one in which we fully intend to remain active.

Steven Hambleton — 06:43 on 01.18.2012

Thanks for replying Matt. I’m curious, what was EllisLab’s response when you suggested areas of improvement or let them know of your potential code improvements?

I know that Lisa and Leslie are very receptive to new ideas (witness the Reactor team as you mentioned).

Lastly, can you make permanent patches to WordPress’s core without Automattic’s authority? How is this different to making your own changes to ExpressionEngine?

Isaac — 11:21 on 01.18.2012

“- the availability (or not) of highly managed, platform-specific enterprise hosting. EE does not yet have a comparable, truly enterprise-scale hosting solution for media companies in particular (see http:vip.wordpress.com)”

Enterprises have their own data centers and admins. vip.wordpress.com is not a replacement for real admins who actually know what they’re doing.

“- Its built-in caching mechanisms are inefficient in enterprise settings, including in load-balanced environments in which it is highly wasteful.”

I’m going tohave to disagree with you here too - I have tuned ExpressionEngine sites that host in the area of 100k entries, on multiple web heads, with a large amount of traffic without any significant issues. Simple modifications to the core make EE scream in comparison to WordPress.

I’ve been working with a member of the reactor team to get my patch for this functionality submitted - we aren’t quite ready yet but it will make you take back this bullet point. IronCache is a heavy handed way to do what takes about a dozen lines of code in EE to do, no need to “port” anything from WordPress.

“Were we a larger organization we may have been able to commit the resources needed to continue to think about these things (hosting/scaling, caching.)”

That means you aren’t enterprise. You’re a small company.

“WordPress is open source software. “

So is ExpressionEngine. Don’t buy into the rhetoric of the OSI - the original open source software was UNIX and everyone knows it. When you purchased UNIX you got two things: a perpetual license to use the software, as well as all of it’s source code and permission to modify it as you saw fit. That’s open source, everything else on top of that is something else. You can modify ExpressionEngine and you get a real company behind it for support. In my eyes - that beats out any GPL garbage any day.

Finally the thing that I find most upsetting about this is the brazenness of the anoucnement you are damaging the ExpressionEngine community by making this announcement and saying in your own comments that WordPress is “more innovative” and a great “CMS” - which is just factually inaccurate, WordPress does what they have to get by, they have terrible architecture (“the_loop()” - WTF), and it isn’t a CMS at all - and all this after you have stood on the backs of the community for a long time.

André — 11:41 on 01.18.2012

“...and is the locus for a whole lot of journalism innovation and experimentation.”

People seem to read into this that Grist is saying that Wordpress is innovative technology (re Tom: “..it sure as hell isn’t at the cutting edge of web technology.” and Isaac: “saying in your own comments that WordPress is “more innovative”“).

Innovation in journalism don’t necessarily have anything to do with technology as such.

Marcus Neto — 11:56 on 01.18.2012

@steven, to my knowledge no one on the EllisLab team was contacted about any concerns that Matt or the team at Grist may have had. We would have listened. And I still welcome any discussion they may want to have.

As for EE’s capabilities we know of several websites getting over 3-5 Millions visitors per month. I can think of 1-2 specifically that get anywhere from 15-25 Million users per month. And a couple others that have 500k entries in the DB. And lest you think these are all hosted with EH some of them are and some of them are not.

While we hate to see Matt and the Grist team go we do understand that these things happen and often it is for reasons that others would disagree with. If 8-10 months from now they change their minds we will welcome them back to our community with open arms.

Stephen McIver — 12:55 on 01.18.2012

Some very interesting comments here.

I’m keen to see EE develop on the efficiency/speed/scaling front, so from that point of view, I’m quite excited about the modifications that Isaac has mentioned (plus anything else that’s being done by EllisLab), and look forward to seeing them if they make it into the core version.

Matt Perry — 13:38 on 01.18.2012

Hey guys,

Thanks for the candid discussion. 

@Marucs—thanks for the good wishes   There are indeed very large EE sites, and I have no doubt that running EE to that scale makes sense in many contexts.  We will continue to stay connected.

@Isaac—there are probably many ways in which we disagree.  I’m not sure if it’s constructive to go back and forth here (except to say that we ourselves have spent the last 3 years tuning a high-demand EE site so I’m fairly confident in my experience, and my code [have you tried IronCache?  If not please do and let me know how it can be improved!]) 

More importantly, I think you misunderstand me regarding “innovation” and certainly about any disrespect to the EE community.  It’s a simple fact that more media/journalism development is being done on WordPress than anywhere else right now (see major projects like Automattic’s EditFlow, NPR’s Project Argo, etc etc..)  There’s really no debate about that—just go to an ONA meeting and ask around.  Also,  Andre (above) is exactly right about what I meant by innovation—it doesn’t refer to the quality of the underlying CMS, the_loop() etc ... just to developers building new products for media/journalism.

Isaac - by the way - is what you’re saying then that you have a core modification to EE that supports memcached whole-page caching?  If so, that would be great—I’d love to see how you did it ... or any suggested core-mods to modify EE’s scaling.  I have quite a wish-list in that dept. so perhaps we should talk.

Finally to reply to Steven Hambleton above, I have had nothing but very positive interactions with Leslie and the whole Ellis Labs team.  While we only had sporadic opportunity to talk to them about scaling, and at one point we were talking about collaborating on a white-paper on the subject, I’ve found Ellis Labs to be responsive from the top down.  The difference in general philosophy between EE and WP, however, is that sure I can—and have—hacked EE’s core to facilitate scaling.  In fact, we maintained a log of the 5-10 or so core mods we made for scaling purposes so that we could re-create them when we upgraded EE.  (we did everything we possibly could by writing extensions, but in some cases mods were necessary.)  But the point is that there was no well-defined, efficient way to contribute core modifications as patches to the core product, nor is this central to the culture in the same way it is in the WordPress world.  And that’s okay—there are many ways to develop a product.

Thanks for the lively discussion!

Eli Van Zoeren — 15:36 on 01.18.2012

Interesting discussion! I work with both EE and WordPress nearly every day. In most ways, I greatly prefer working with EE: the templating is better, the add-on api is better, the custom fields system is 1000x better, & the community is more helpful. If I had to pick one CMS to use for all my projects, EE would be it in a heartbeat.

But let’s be honest. WordPress has EE beat by a long shot when it comes to deployment. With a standard Nginx config file and the W3 Total Cache plugin, I can have WP caching static pages that are served directly from disk (or memcached) without touching PHP or the the database, and I can have that configured and running foolproofly in under 5 minutes. To get anything from EE to the browser with less than a couple dozen DB queries requires serious template optimization and the built-in cache system tends to break even moderately-complex templates. (Maybe Solspace’s Cache module is equally as easy as W3TC, I haven’t had a chance to use it yet….) And let’s not even get started on WP’s automatic upgrade system.

Now, I have never had a serious performance problem with Expression Engine that I couldn’t overcome through creative optimization or add-on usage, but I’m just saying that these things are both simpler and less prone to breakage in WordPress.

I decide on a project-by-project basis whether EE (complex sites with multiple sections, membership, or e-commerce) or WP (high-traffic blogs or simple, low-budget sites) is the best choice. Obviously, Grist did the same thing and concluded that WordPress was a better fit for their needs.

Isaac — 17:35 on 01.18.2012

“It’s a simple fact that more media/journalism development is being done on WordPress than anywhere else right now”

The factual accuracy of this is probably debatable (you seem to be using a fairly narrow definition of journalism, although widening the definition may very well make WP more of a leader, I don’t have the data). I don’t think anyone actually has these numbers.

More to the point however, I don’t see why this would get anyone to abandon a working platform for something else. Who cared if the entire world was using Quark? That didn’t mean that it was the only way to make printed pages. And the same logic doesn’t mean that WordPress is the only way to make “journalism” sites. The argument here just doesn’t make any sense to me at all.

Also, with a wink I’ll say that dropping names of organization’s meetings you go to won’t get you very far with me. I really couldn’t care less who you rub shoulders with, your decision is still wrong from a technical basis, and that’s all I can speak to - I am an engineer, not a journalist. I do however apologize for not taking the innovation comment in the way it was meant.

“Isaac - by the way - is what you’re saying then that you have a core modification to EE that supports memcached whole-page caching?”

Yes, as well as database level memcachd integration - which in my experience basically eliminates the need for whole-page caching. It is not exactly rock solid and I haven’t gotten it working on the latest version of EE yet but it is a sound theory and it will work.

“But the point is that there was no well-defined, efficient way to contribute core modifications as patches to the core product”

This would have been a great excuse last year. However, we have Reactor now and you made your decision (presumably) and your announcement (certainly) after that team had started. So this isn’t really an excuse.

Honestly it sounds like you guys have some WP fans over there who get to call the shots and they called the shot. That’s what it sounds like. If that’s what’s going on, I feel for you. It’s not a fun place to be.

Isaac — 17:38 on 01.18.2012

@Matt Oh, and if you go to EECI2012, find me and I’ll buy you a beer to make up for being a bit of a jerk here.

Matt — 19:06 on 01.18.2012

@Isaac —sounds good to me

Tom Stoecklein — 19:19 on 01.18.2012

(I’ve been told I like to hear myself speak, so feel free to skip this long-winded reply)

I hope you guys (Grist) realize I was just being sarcastic last night. As the night wears on and each passing hour comes and goes, I generally tend to become more and more sarcastic. Not because I’m an EE fanatic dedicated to the cause and willing to slash down infidels who would dare walk back from the altar of EllisLab, but because I’m like a bloodhound in that I always want to dig deeper into things. I really hope I didn’t come off too brash last night (though I still hope my jokes were semi-funny).

Particularly, I’m interested in learning more about some of the factors behind your choice. Not because I want to fight you over them, but because it could be immensely helpful for a large project we’re currently in the early stages of (not to mention the community in general, EllisLab, & even my own future work).

My comments about WP & EE being basically the same were in terms of how each functions in a general sense (and how that functioning then relates to server infrastructure).

***

- Caching is something I’ll definitely agree with you; EE could be significantly stronger.    Things like memcache support should be baked into the core (and I’m a huge believer in small, highly functional cores without any fluff or waste).

Beyond that, even simple template caching is limited. A plethora of add-ons (CE Cached, the Solspace Stuff, your IronCache, etc.) exist to help make up the difference but each still has significant limitations by way of the nature of add-ons in general (along with individual differences).

The biggest problem, however, plagues both WP & EE in that it’s difficult (if not impossible) to create a generic caching mechanism applicable to even just a simple majority of installations a simple majority of the time

Part of the problem there is an infrastructure one (and this is largely where my original comment was coming from): say what you will about some of more, uh, adamant supporters of NoSQL, but there’s a fundamental issue at the base of WP, EE, and to be honest, most other systems out there. SQL and relational DBs have their use cases (and in many instances, are the perfect tools for the job), but when you get right down to it, we’re building our applications on a DB solution that is far from optimal.

Regardless of whether it’s EE or WP, when you start to consider the database, the word “scale” brings to mind the feelings of angst that are generally paired with a lengthy description in the DSM-IV that’s on every psychiatrist’s bookshelf (criticisms of the DSM aside). There’s a reason that when it comes to scaling a site’s infrastructure the order of operations is almost *always* the following (caching excluded): split the web & db tiers, load balance web servers, vertically scale your DB box as best you can, down a few shots of something strong (anything strong enough to leave you on the floor slobbering, but thankfully divorced from the reality of the task you’re about to embark on next), and then figure out how you’re going to scale out your database horizontally.

In short, it’s a bitch. And to be perfectly frank, I wonder what our systems would look like today had document-oriented databases been available, say, a decade ago. ExpressionEngine is the absolute perfect example given how custom fields are, quite literally, at the heart of EE. It practically begs you for some sweet Mongo lovin’.

But that’s really just an unimaginably unlikely wish, right up there alongside the ability to drive down the interstate as fast as you want without some idiot mucking about in the fast lane up ahead of you every few miles.

Anyhow, as of late I’ve been working on figuring out a sturdy solution for better integrating a Varnish cache layer fronting EE. Chiefly, the three big obstacles are handling proper cache purges (by allowing Varnish to better differentiate particular objects from EE), allowing for proper ESI (edge side includes) with EE to allow for the caching of dynamic pages/content (at least to a certain extent), and naturally, making sure everything is able to smoothly scale horizontally.

(If anyone wants to talk about Varnish, ESI, etc. with EE feel free to shoot me an email - tom [at] vexea [dot] com)

- On infrastructure, I definitely feel for you. But DbaaS (database as a service) & polyglot IaaS solutions ala Heroku are opening doors for the little guy that never really existed before.

That said, I’m not sure why you chose WP’s VIP services in particular: they seem kind of like a glorified shared host with a single authentication system and a ridiculous premium to boot. Have you looked at solutions from companies like Heroku or phpfog (phpfog.com - really neat company, and they run their documentation through EE to boot)? Actually, strike Heroku - can’t write temp files if I recall.

@wesrice — 20:21 on 01.18.2012

I’ve had a blog post in mind about this for weeks, but I just haven’t had time to get around to it.

In short: For most projects I work on, WordPress is now my default publishing system of choice.

I think there are a lot of misconceptions about WP, particularly due to outdated code throughout the web and even in WP plugins. I’ll get more into this in my blog post WP and EE, which will be fairly detailed and draw several 1 to 1 comparisons between the two.

Ultimately, I believe that the best publishing platform is whichever you are most comfortable with and whichever you can make your clients feel comfortable with.

Matt Perry — 23:25 on 01.18.2012

Who knew this would be such an interesting thread. 

@Tom

I really appreciate your thoughts here—you expressed a bunch of stuff really well, even tho I’m not that familiar with some of the newer database technologies you mentioned.  (Like many people I know more or less what they are, but haven’t worked much with them, nor considered trying to back EE or WP with them)  Plus (just for the record)  ... I like your jokes!

In terms of how people generally scale I think you’re right on when you say:

There’s a reason that when it comes to scaling a site’s infrastructure the order of operations is almost *always* the following (caching excluded): split the web & db tiers, load balance web servers, vertically scale your DB box as best you can, down a few shots of something strong (anything strong enough to leave you on the floor slobbering, but thankfully divorced from the reality of the task you’re about to embark on next), and then figure out how you’re going to scale out your database horizontally.

You’re totally right that the LAST thing people want to have to worry about is horizontally scaling a database.  Things get pretty tricky pretty fast.  Master/slave, clustering and sharding are all possibilities that we considered but there are a great many problems (and costs!)  EE and WP were both engineered without any thought of these scaling methods in mind.  Poor read/write segregation makes master/slave difficult, assumption of immediate INSERT replication is a problem too etc etc ... it just isn’t part of how this software is engineered—sounds like you and I agree on that.

EE, for example (not to pick on it!) does not have a stable DB schema, so some of these methods are probably not possible, at least not in the case of a large table like exp_channel_data, which changes schema every time a custom field is added.  Anyway, we’ve gone down these various roads, though not to their ends—more like far enough to see that we didn’t like where they were going.  We usually turned around and doubled down on scaling efforts.

I’d love to hear how your work with Varnish goes—we used squid as a reverse proxy, but if I had to do it over again it would be Varnish.  Maybe post your ideal configuration somewhere when you’ve figured out the best way to front EE with Varnish?

And just a note about WP VIP—your impression was my first impression too.  However, the WP VIP service turns out to be worth the money, at least for us—maybe not for others!  It’s definitely more than just shared hosting in any case.  You can go to their site to see all the big media properties that host there ... my favorite is probably the LolCats empire of sites.  Apparently it gets more traffic than CNN, which is also on VIP.  Anyway, we have full control over our theme and add-ons (we commit to a particular SVN repo to change our deployed code) and aside from a few ground rules, we can do whatever we want.  The fee is almost the same as our former hostng and sysadmin costs, and it’s going to be worth it to not ever having to worry about going down ... really ever.  (Well, except if ALL of wordpress.com goes down, then I guess we’re down too.)

Anyway thanks for the cool comments.  I enjoyed reading them.

@wesrice please post a link—would love to read your article.  I agree w/ you—use whatever feels right and works in the situation.  Also, WP (being a huge community of thousands of developers) has a HUGE amount of crap add-on code written for it.  The community seems to be struggling with this right now, especially after this incident:  http://wpcandy.com/reports/timthumb-security-vulnerability-discovered.

Tom Stoecklein — 03:15 on 01.19.2012

Matt,

I don’t think we can reasonably pin responsibility for such issues on either WP or EE. It’s tough enough to bake a system capable of delivering the sort of friendliness towards scaling techniques you need when you’re the only person/company who will ever use it. Trying to do the same with an application that will be used in pretty much every imaginable infrastructure variation (and some not-so-imaginable ones) is impossible. Out of the box, any PHP/MySQL solution is pretty much unable to do it. Even a basic master/slave replication setup can have unforeseen issues - and that’s well before you’ve even started to think about splitting off reads to the various slaves.

At the risk of sounding like a NoSQL dork who thinks everything can be rewritten in Mongo or CouchDB (lord, I’m surprised some of those people haven’t come up with toilet paper inventory systems for their bathrooms just to say they’ve achieved real transactionality as it’s pulled from the roll and sent on over to the toilet), the more I go on, the more I genuinely believe that MySQL for CMS use cases is not only just plain wrong, but counterproductive over the long-term.

You hit on part of it with the add-ons. Take Matrix for instance: you’re throwing two (iirc) new tables into the mix, adding a number of additional queries to your templates depending on your Matrix data, and if you’ve got anything even remotely complex for your cell types, well, it’s going to get interesting. You can do some pretty creative stuff when it comes to caching, but in the end, there’s still the complexity that’s underlying it all.

Not that I’m bashing EE or fieldtype developers; on the contrary, they’re doing top notch stuff within the parameters of their limitations. But let’s think about MongoDB for a second as an example of alternatives:

```
{
  _id : ObjectId(“4e77bb3b8a3e000000004f7a”),
  when : Date(“2011-09-19T02:10:11.3Z”,
  author : “alex”,
  title : “No Free Lunch”,
  text : “This is the text of the post.  It could be very long.”,
  tags : [ “business”, “ramblings” ],
  votes : 5,
  voters : [ “jane”, “joe”, “spencer”, “phyllis”, “li” ],
  comments : [
  { who : “jane”, when : Date(“2011-09-19T04:00:10.112Z”),
    comment : “I agree.” },
  { who : “meghan”, when : Date(“2011-09-20T14:36:06.958Z”),
    comment : “You must be joking.  etc etc ...” }
  ]
}
```

That’s a sample document pulled from their docs representing a blog entry. That’s it; everything in one place. Take it a step further; instead of relying on additional relations with new fieldtypes, store it right in there with the entry itself. Including files, given that the usual (and very good) arguments against storing them in a database don’t apply. Business Insider does something really cool with their implementation by nesting comments directly in the entry’s document itself:

```
{ comments: [ { author: ‘Ian White’, comment: ‘Great article!’ },
          { author: ‘Joe Smith’, comment: ‘You suck!’,
          replies: [ { author: ‘Jane Smith’, comment: ‘No you suck!’ } ]
          }
        ]
}
```

Now that gets me excited. Schemaless setups aren’t the cure to all the world’s ails, but when you consider how EE’s custom fields functionality is quite literally at the heart of what makes EE, well, EE, it really offers up some possibilities. Forget scalability, forget performance gains (though I’m sure you can imagine them quite easily enough), forget all the hype. The mere possibilities such simplification offers developers and companies like Grist alike are enough to keep me up at 2am writing this comment.

Take a moment to read about how John from Ordered List implemented MongoDB behind their Harmony CMS:

http://railstips.org/blog/archives/2009/12/18/why-i-think-mongo-is-to-databases-what-rails-was-to-frameworks/

The other thing is, what you hit on is probably better described as attempting to mimic a flexible schema and not necessarily one that’s not stable (as in unchanging). The difference between the terms is minor, but I think that it’s sufficient to note. Flexible schema types aren’t bad things; in fact, they’re pretty much a necessity in a modern CMS.  [...]

Tom Stoecklein — 03:16 on 01.19.2012

I love EE. But the limitations are there and the world is (hopefully) changing. DBaaS providers are effectively offering the services of top-notch DBA teams to small and medium-sized businesses while simultaneously making it almost effortless to deploy alternative database solutions (including highly specialized relational offerings as well, but that’s tangential to this comment). SQL alternatives are crawling out of the woodwork to be battle tested under some downright extraordinary conditions unlike anything we’ve ever seen before, and considering that there really weren’t any significant challenges to the relational database for almost three (!) decades, it’s safe to say that things are going to get pretty interesting.

Right now, most CMS setups on top of NoSQL databases, are effectively one-off solutions, further complicated by the fact that most of them are on Rails/node/whatever (say what you like about PHP/MySQL apps but I’ll be damned if they’re not easy enough for someone’s 90 year old grandmother to deploy… even with her cataracts). But eventually, that’s going to change. I really do hope EllisLab is able to look to alternative database drivers and cook something up. If they do, the same innovation that made EE what it is today will enable it to go even further in the years to come.

Anyhow, getting off my tangent, this all applies to WP as well. Even with their third-party plugins for caching and what not, it’s still sitting on top of the same fundamental issues. You’ve protected yourselves from having to deal with them through WP VIP—which is great if it works for you (don’t let anyone, myself included, say otherwise)—but that doesn’t make them go away. You know that, obviously. I just hope that if someone’s reading this and is debating going with EE or WP they realize that we’re talking about fundamental issues and not ones unique to either platform.

—-

With Varnish, I’m looking into what’s called an edge side include (ESI). Instead of EE assembling the entire page, Varnish caches the bulk of it and then puts it together by including whatever dynamic fragments I’ve identified (through the use of the <esi:include src=“your/template/fragment/here” statement). Info here, which should be helpful in WP as well if you ever need to look into it later:

https://www.varnish-cache.org/docs/3.0/tutorial/esi.html

The problem is, because of how EE templates in general function, you’re looking at splitting off templates into separate elements and pulling from separate templates. Doing that on a single site isn’t the craziest thing in the world, but trying to put it together into a single add-on is effectively impossible IMO only because the flexibility needed is just too, well, a bit too much. Think Olympic gymnast compared to the fat bearded guy in a Nintendo t-shirt eating a hot dog in the park.

The other thing is coming up with a better solution for purging only specific objects in the cache. Again, because we can use channel entries in multiple places at once there’s a lot of complexity involved in there to do it right, assuming you don’t find having different revisions of your entries particularly appealing.

[P.S. - 10k characters isn’t enough for me! I need… well, I need more. :D]

Steven Hambleton — 06:17 on 01.19.2012

We just found our Geek of the Week winner! Well done Tom!

Aaron Waldon — 09:26 on 01.19.2012

To address the main issue about Grist.org moving to WordPress, good for them! At the end of the day, the CMS is a means to an end. If they feel the move will be advantageous, I am glad they are doing so and I genuinely hope it works out well for them.

As a community, we should not be offended when a company switches technologies. After all, it is not a personal attack on EE or its user-base. They didn’t pillage our proverbial village or threaten our livelihood. Not all companies are the same and not all end goals are the same. No big deal.

That being said, I think there are a couple valid and important points being raised here in the comments:

——- Performance——-
There are no doubt “weaknesses in EE’s caching layer and scaling.” Even though some of these will be much easier to overcome in the near future, there is still a lot to be desired in this arena. The amazingly flexible and feature-rich ExpressionEngine we know and love inherently comes with a price. The same can be said about its user-friendly templating system. However, those things are also what set it apart from the competition; it depends on your needs and the “end” you’re trying to achieve.

“We even wrote the only memcached caching add-on for EE (http://gristlabs.com/ironcache).”
I’m sure this was true at one time, but CE Cache can also integrate with Memcached. Although there are several fundamental differences between our add-ons, as your solution was aimed at full static page caching as opposed to fragment caching. CE Cache also has several other drivers to choose from, and Memcached is the least favorable, as there is no way to loop through the keys

——- Code Contribution——-
“...[T]here was no well-defined, efficient way to contribute core modifications as patches to the core product…”
Agreed. This has always been an issue, and has become an increasingly frustrating point for me too. Even more so *with* “Reactor.”

I don’t think it would have ever been—or would be now—difficult for the core EE dev team to take a user-contributed class or snippet of PHP and determined if they wanted to use it in core. Was it necessary for a super-secretive, elite code brotherhood to be assembled to work without pay in order for this to happen?

I spend a *huge* amount of my time every day developing and supporting EE add-ons. Yet, I have no idea what is going on with the brotherhood, and little time to react to core changes before they are released. Reactor members can literally add hooks to the core and have add-ons or add-on modifications ready for release before I even know EL has that functionality on their radar. Do us “other” devs really need to join the free workforce to have that advantage? Work for free or be left behind?

There are some amazing devs that would like to contribute to core? That’s great. Let them. Let everyone. Equally. There are *paid* developers for the *commercial* product that can make these changes and sculpt the overall direction of the platform at large. Please don’t fragment or cripple the playing field for the rest of us by giving a random subset of devs a substantial advantage. Please let everyone contribute, and let the core developers weed out what EL doesn’t want.

I cannot imagine that I’m the only non-Reactor developer that feels this way. I know that several “other” devs have add-ons that are in direct competition with those of the brotherhood. Not all of us have a co-worker Reactor members like Isaac does.

—-

In conclusion, I think the performance and code contribution issues raised by Matt and the folks at Grist are important to note and to strive to improve. If the performance concerns are completely valid or accurate doesn’t really matter, as it is the best move in their eyes. There is always room for performance improvements (although CE Cache will rock your socks). And finally, hopefully EL will be more approachable for code submission and facilitate it in a way that will allow third-party devs to work in an equal environment.

Philip Zaengle — 13:22 on 01.19.2012

Well said Aaron.

Brian — 13:31 on 01.19.2012

Aaron, I think if you sent a .diff file to EL with some core changes they would definitely review it. You don’t have to be on the Reactor team to send contributions, however, the Reactor team makes it a bit easier as we can just send pull requests, and review them in GitHub before it’s merged.

As for adding hooks and having an edge above the competition, I can see your point, but the other side of the argument is hooks benefit everyone. I think I can probably speak for the whole team when I say we’re not going to just add hooks that benefit our add-ons only. We also can’t just add a hook without a valid and solid explanation as to why it’s added. The EL team reviews those things heavily.

The Reactor team at this point is a trial. My guess is mostly for technical reasons b/c there were some hiccups with the initial repo forks (e.g. CI submodules). It wouldn’t be a good idea to unleash 20 or 30 devs on it at the same time. EL has already mentioned that it will expand the team after the process is established. Since EE is a commercial product, they can’t just open the repo to the world, so there needs to be a “brotherhood”, and right now it’s just a “lets get the process and technical kinks worked out first, then open it to more people” (at least thats how I’m understanding it, EL correct me if I’m wrong).

And yes, CE Cache rocks our socks

Travis Smith — 18:50 on 01.23.2012

Caching issues aside, perhaps one reason Grist.org switched was because of this:

http://gristlabs.com/2011/11/01/otto-nacin-at-grist/

When was the last time EllisLab sent members of their core team to help on an install? (And I’m not saying they don’t—I’m legitimately asking, when have they done this?)

TTFN
Travis

Levon Mock — 21:49 on 01.23.2012

Hi,

I wanted to reach out to you and let you know about our targeted email marketing lists.  We can offer you targetd, opt-in, fresh and responsive emails.  Also, we have software to send bulk emails that will keep you compliant to spam laws and get your message in the inbox.

Our largest targeted segments are:
Credit Seekers
Stock Investors
Businss Opportunity
Mobile App Download
Insurance
Online Dating
And more…......

We can further segment the data geographically so you reach your target market.

Depending on the segment you want we can get you 5,000-1,000,000 targeted opt-in emails starting at $24.95.

If you are unsure of running your email marketing yourself, let us set it up and send your message for you.

If you have any questions please contact me via email or visit our site. www.bulqq.com

I wish you the most success in 2012 and look forward to hearing back.

Regards,

Levon Mock
Levon@bulqq.com
www.bulqq.com

Bransin Anderson — 22:00 on 01.23.2012

I can see this happening.

Scenario 1:
Development needs are not met when using EE as a platform, the company itself begins to wonder if they are using the right CMS and see other companies using Wordpress.

Scenario 2:
Grist.org doesn’t understand the expansive abilities in EE, maybe it all comes down to who was doing the work. Maybe this wasn’t communicated. There are so many scenarios of why.

Overall I see it as a dumb move. Wordpress is meant for small scale websites. Expanding Wordpress takes a ridiculous amount of effort and is more vulnerable to being hacked.

Steven Hambleton — 22:03 on 01.23.2012

I can’t comment on whether WordPress is a good fit but my main concern is how this reflects on ExpressionEngine in the CMS market.

Either the product looks bad or the support looks bad.

If none of the above then Grist looks bad!

GDmac — 08:46 on 01.24.2012

“When was the last time EllisLab sent members of their core team to help on an install…”
- If I recall, when Devot-EE upgraded to 2.x, some of the EE team helped out.

Email Online Dating — 17:09 on 01.29.2012

Why would someone go to wordpress from EE. Expression Engine is such an awesome platform!

Tony — 09:42 on 02.08.2012

“Either the product looks bad or the support looks bad. If none of the above then Grist looks bad!”
- Steven Hambleton

There could be other alternatives beside the two you mentioned. The exclusion or denial of the two alternatives does not automatically lead to the conclusion that Grist looks bad. Both EE and EE’s support could be good without making Grist bad in this context.

A more useful question is this: What is wrong with the makers of EE targeting/enticing corporate users of WP by making EE easy to integrate with WP such that the two CMS’s can easily be used together? Killing two birds with one stone can never be bad for EE’s profits or growth! Often the solution of a problem is embedded inside the problem if the problem solver looks deeper and harder.

Thanks Ryan!
I still love your work, and I occasionally visit here for new EE things.

And finally, thanks for posting this:

“We admire people who speak their minds. At the same time we admire people who listen more than they talk, and make a real effort to understand views that differ from their own. Candor is a virtue; arrogance is not.”

http://eeinsider.com/blog/gentle-manners-hard-work/

paypercall101 — 14:19 on 03.17.2012

“Ultimately, I believe that the best publishing platform is whichever you are most comfortable with and whichever you can make your clients feel comfortable with.”
-@wesrice

Good point. The technology/feature set is only one (albeit important) criteria. Investment in skill sets often drive decisions like these.

интериорни врати — 11:20 on 04.02.2012

The article is really good. BTW - shown in photo is unique!

romantic dating — 14:43 on 04.29.2012

Great Information! I just couldn’t leave your website before telling you that we really enjoyed the quality information you offer to your visitors… Will be back often to check up on new posts. Thanks for sharing us!