Skip to content

Pardon the dust! We're slowly revamping our site over time so some things may not look perfect.

Blog : The ExpressionEngine Add-On Addiction

By Angie Herrera // December 5, 2014

At our local EE Meetup last month we had a mastermind session of sorts where we talked about ExpressionEngine and our businesses and development processes. It was a good session for sure. One thing we got to talking about was moving away from using so many third-party add-ons in EE. Sacrilege? For some, perhaps. But let's dig a little deeper into this as it's something that's been in the back of my mind for some time in some form or another.

It seems that we have gotten so used to using an add-on for everything, that we don’t stop to think about whether we absolutely need it or not.

When it comes time to upgrade EE, it's a bit of a roll of the dice as to how easy or hellish it'll be. A big part of that has to do with add-ons. Yes, EE itself has it's fair share of issues. What software doesn't to some varying degree? That isn't the point here. Besides, EE 2.9.2 is rock-solid in my opinion. In our experience though, it's add-ons that cause problems most of the time.

(This isn't meant to be a knock on add-on developers. They provide digital products that are often invaluable to the products we build for clients. Again, no software is without its issues.)

I don't hate add-ons and in no way am I suggesting we throw them out altogether either. Here at Block 81, we certainly have our favorites that make publishing and development workflows much, much easier for clients and for us. EE can't solve every problem natively and never will. Honestly, I really don't think that's what a CMS should aim for.

It seems, though, that we EE developers have gotten so used to using add-ons for everything, that we sometimes don't stop to think about whether we absolutely need them or not. To take it even further, do we really need to use add-ons to the point that we've bastardized the intent of how EE should be used?

To give a concrete example, we recently had to upgrade an EE 2.4.0 site. A site we didn't build and that had quite the abundance of third-party add-ons for features that could have been handled natively or that weren't even being used by the end-client. We had hoped to go to 2.8.1 but had to stop at 2.7.3. Why? Third-party add-ons. At least a couple of add-ons that are being used on this particular setup are not compatible with EE 2.8.1+, mainly because the add-on developers stopped developing it or abandoned it altogether. And in this case, the add-ons in question probably weren't needed in the first place. We spent way more hours on that upgrade than ever, and I'm convinced it could have been avoided had the site been set up differently. (That's a whole other story though.)

On the flip-side of that coin, Kurt Deutscher – an EE user since its pMachine days – has almost zero issues with upgrading EE because he and his team rarely use third-party add-ons. His company, NetRaising, manages a ton of web properties, all on EE (I forget the number but it's way up there). They upgrade EE sites on a regular basis with almost zero incidents. I'm a little envious, to say the least. But this discussion last month and Kurt's experience certainly sparked a re-evaluation of how we build EE sites.

I'm not sure we could ever truly kick the third-party add-on dependency. I'd wager that's true for a lot of EE shops and devs. But I'm convinced that we do need to change things so that when we set out to build an EE site, we don't instantly turn to third-party add-ons for every little problem and instead reserve them for the big problems that can only be solved with add-ons, such as e-commerce and subscriptions, to name a couple.

Keep it simple. As simple as possible. Why not?