Published by Mijingo

movie icon image

EE Insider Blog

Spend your time learning and developing sites with ExpressionEngine and we'll use this blog to keep you informed of all the news related to ExpressionEngine and CodeIgniter.

» Read more in the Archives.

» Have a tip? Send us your EE news.

Learn ExpressionEngine Today

Over a series of 8 videos, watch and learn as Ryan builds an entire ExpressionEngine website from beginning to end. Get started now.

Ask the Readers: Choosing an Add-On

Ask the Readers If you happened to already have listened to the latest EE Podcast you might recall Ryan and Lea talking about how they decide if an add-on is something they are willing to add to the site they are building. There are a lot of factors that go into this kind of decision: Whether the developer will continue to support the add-on, any potential performance drawbacks, does it make the clients life incredibly easier, etc.

My question for today’s “Ask the Readers” segment is: Do you have a process for deciding what kinds of add-ons you will install? What reasons might you have for avoiding an add-on?

Posted on Jan 19, 2011 by Brian Warren

Filed Under: Ask the Readers

nataliav10:11 on 01.19.2011

I agree with Ryan and Lea’s reasons. I try also to use the add-on to evaluate its quality. For example in the case of a WYSIWYG editor, I try to format real text, copy and paste, etc. and see the results, even if it is a pay add-on, I think it’s worth buying a license and play with it in personal site or a sandbox site before using it for a big client’s website.

Who is going to use the site is a major factor. For myself, I’m using 1 - 3 add-ons, mostly fieldtypes, I use the EE textarea, global variables, the pages module, but less tech savvy people need easier ways to manage their site.

Chris Calabrese12:15 on 01.19.2011

Ryan Masuga and the team at devot-ee have done a masterful job putting the support questions in the sidebar of each add-on. This guarantees that when there are problems with add-ons, developers really take notice.  It’s annoying when a developer complains that the problem must be your specific environment, when it clearly isn’t.  The sidebar allows others with the same error to weigh in and help isolate the bug and make the add-on all the better.  It has been my experience that EE developers are the best and on a daily basis make EE more robust and interesting.  They are extremely conscientious about timely support. The developers and the community in general are the #1 selling feature of EE and make it a joy to work with.

bluedreamer14:48 on 01.19.2011

Haven’t listend to the show yet - gasp!

I have 3 main criteria for using an addon…

1. Can I accomplish the task using native EE funtionality?
- there’s no point in using an addon if you don’t have to

2. Is the addon source/author reliable?
- for the most part most popular EE addon devs are fine and hopefully we don’t need to worry that much!

3. Can I provide a fallback if things go tits-up?
- this is probably the most important aspect. Say I use an addon to output a map. If there’s a problem with the addon I can fall back to a simple textarea field and paste in map embed code, not perfect but it could get me out of a tight situation. For other addons that have specialised functionality where no alternative can be provided it’s always going to be a gamble, that’s just part of the game though!

Paul Frost04:37 on 01.20.2011

Is there a way to achieve what you want without an addon must be first in the list.

Second, is it simple to set up, configure and implement.

Then, most important, does the developer provide good timely support?

Look through the various support forums to see if the addon has issues, either of it’s own or playing nicely with others.

Juan06:54 on 01.20.2011

I try to go for a EE2 non addon approach at first. As the project grows into a solution and each use case develops, I confirm if the addon is need it: previously I did confirm it’s possible use in a Project Scope (to have a budget prepared).