Lessons learned in ExpressionEngine add-on development

Feature image

In January I released the first commercial add-on I’d developed for ExpressionEngine. It’s called Pic Puller and it helps an ExpressionEngine developer create and integrate an Instagram application into his or her site.

This post isn’t meant to get you to go buy a copy of the Pic Puller add-on. (Granted, I won’t stop you either.) Rather, it’s a personal journal of my process of making it and what I’ve learned along the way. It may be a bit rambling, but it’s the story of how I ended up where I am now with Pic Puller. Maybe it will be helpful to you if you’re trying to make add-ons of your own.

Some history.

Pic Puller started life as a simple PHP application I built for a client project that got killed after it was built, but before it went live. That application was not built for ExpressionEngine. It was originally a standalone PHP app that lived on a Tumblr site, pulled in via an iframe.

That original app was an elemenarty piece of work. It required cutting and pasting the Instagram app ID and client secret into the PHP document. It functioned but I would be embarrassed to tell anyone else the hoops to jump through to get it working. It was far from an elegant solution, but it served the purpose it was built for.

It was rewarding to learn about the Instagram API with that project, but I was disappointed that it never saw the light of day due to my client’s changing needs. I wanted to do something with what I’d learned though.

Next stop, ExpressionEngine.

If you’ve read much from my blog, you may know that I work with a number of technologies. One of my favorites is ExpressionEngine, EE, for short, the CMS that’s behind the scenes here at SuperGeekery and nearly all the content managed sites I build. It’s a powerful CMS that gets even more power and flexibility through add-ons built by the EE community.

I’m happy using EE as it comes ‘out of the box,’ but being a tinkerer, add-on development really interested me. A year or 2 ago, I started at what I consider the entry point in add-on development, making a plug-in during the creation of a new version of this site. That plug-in is SuperGeekery TagStripper. I released it for free and was surprised by how popular it was. It’s not a complex creation, being basically a wrapper around 3 PHP functions that use regular expressions, but it solves a problem I personally run into often when building EE sites, stripping out selected tags of HTML.

I made a number of plug-ins after that, mostly for personal use or for others who I met through this site who had specific EE problems to solve. Building plug-ins is like anything you practice. If you do it enough, you start to get the hang of it and you can do it more easily. I felt like I had plug-ins under control.

Last October (2011) I went to EECI, the ExpressionEngine Conference, and got inspired by all the talented people in attendance. Some of the add-ons that I regularly use were built and maintained by the people I met there and I had the pleasure of meeting them and learning from them.

I’d been toying with the idea of taking my basic (and dead) Instagram project I built for Tumblr and making it more user-friendly (or, user-friendly at all, in all honesty) and turning it into an EE add-on. EECI and the people I met there were the spark I needed to get started.

Is this legal?

I got to work almost immediately after the conference and began by sketching out a basic flow of how I wanted the add-on to function. I also re-read the Instagram API documentation and the developer agreement. One clause in that agreement made me question whether I could make the add-on I had in mind and comply with that agreement. I decided that it was necessary to get clarification on the issue. I sent Instagram an email and described the add-on I wanted to make. I specifically asked them whether I would be in compliance given a particular line in their legal in the developer agreement. Happily, within a few hours they answered my email and told me ‘yes’ and I continued my work.

Having my legal question answered, and a rough UX figured out, I moved into development.

The EE developer documentation.

The ExpressionEngine add-on documentation was helpful. Actually, it’s invaluable. But my method of going directly to the point in the docs where I thought I’d find an answer I was looking for didn’t always serve me well. There is a lot unsaid on any single page of documentation. It can be a bit like reading a mystery novel, littered with clues to a solution but requiring a bit of detective work to crack the case. (A valid criticism would be to tell me to read the entire instruction manual before operating the heavy machinery. Point taken, but point ignored.)

If you’re digging through the EE docs and feel lost, in my experience, the answer you’re looking for is probably in the documentation somewhere, but you just haven’t found it yet.

Questions? Go to the source.

Even after you’ve dug into the documentation and still find yourself stuck, I have two tips. “Go to the source” and “Go to the source.” (Clever, right? The same phrase, but meaning 2 different things? Ok, moving along.)

The first “Go to the source” tip is to literally go look at the source code that ships with EE and other add-ons you might use. The PHP that makes up the modules and fieldtypes that you’re familiar with are right in front of you. Open them, read them, and learn from them. Most problems have been solved before. You can learn from others successes and failures.

The second “Go to the source” tip is more figurative. The source for all those great third party add-ons are people just like you. This is a resource you should use sparingly, but the EE developers I know are generous with their time. They are typically overworked though, so don’t abuse them.

As an example, I was stuck on one particular problem when I was building the image browser fieldtype for Pic Puller. After searching the forums, looking through examples of existing fieldtypes, and having tried several failed solutions on my own, I was stuck. I read and re-read the docs looking for an answer without luck. (You could find me at the gym with printouts of sections of the EE docs to review while I was working out.) I finally decided to ask for help.

I had met Carl Crawly (from http://madebyhippo.com/) at EECI and he had talked about fieldtype development with me so I reached out to him. We exchanged a couple of emails and he offered some suggestions to me. Ultimately, I didn’t solve the problem as efficiently as he and I discussed, but having his feedback did help kickstart my brain again and find a solution that works. (Thanks, Carl!)

Releasing early.

About a week before releasing version 0.9.0 of Pic Puller, I felt I needed about 3 more weeks to work on it to get it to the place I wanted for version 1. I hadn’t intended on releasing version 0.9.0.

That version was working well on all the installations I’d tested it on. I had some cosmetic things I wanted to give some more thought to before releasing it, but it was in a good place overall.

I was spurred into releasing it early by a tweet Low posted. (Low is the Low of gotolow.com. If you’re using any add-ons, there’s a good chance one of his add-ons is running on your site.) I wish I could point you to Low’s tweet, but it basically said “ship early, ship often” in reference to software. I’ve heard that before, but that tweet motivated me to accelerate my schedule.

I asked a friend of mine, Melissa, from emtwo.com, if she would test the add-on for me. Thankfully, she agreed. She helped me track down a pesky bug involving security certificate credentials that I would never have caught without her help.

Roads are seldom traveled alone.

With some ‘outside’ user testing now out of the way, I decided to ship early. I had spent nearly 3 months on the add-on and wanted to sell it commercially. I decided on $15 as the price. I already had a couple free add-ons on Devot-ee.com so I just needed to upload and go. (By ‘upload and go’ I mean ‘upload and go’ after settling on Pic Puller as a name for the add-on, designing and building a companion web site, writing the documenation, and creating a free limited-feature version of the software to let users test the add-on before buying it.)

On that day I posted my add-on to Devot-ee, someone else uploaded a free add-on to integrate Instagram into Expression Engine. I was floored and a little disheartened after the amount of work I’d put into it to see a free alternative appear on the same exact day. Such is life though.

The coincidence made me even more gratified with my decision to heed Low’s tweet and release early. The second part of that tweet to ‘release often’ though was also part of my plan. Since that initial release, I’ve added additional updates. There is a new function and an image browser fieldtype now part of the add-on.

Competing with free.

Even with a free add-on promising similar features sitting right next to Pic Puller, there were still people who chose to buy and use the one I had built. (To anyone who has bought a copy, thank you for that support!)

Why would someone do that? I can’t speak for anyone who actually bought Pic Puller, but if you’re making an add-on and you have similar angst of a free competitor, I can give you my perspective behind why I will buy an add-on when free alternatives are available.

I regularly buy an add-on called “CE Image” when building sites on ExpressionEngine. There is a free add-on, Image Sizer, that does many of the same things that CE Image does but I still end up buying CE Image. Why?

Documentation is one factor. CE Image (http://www.causingeffect.com/software/expressionengine/ce-image) has excellent documentation and its site has many examples of using the add-on. That makes it easier for me to use.

The potential for support is another factor. Having paid for the add-on implies support if things go wrong while using it. In the case of CE Image, it is written so well that I’ve never needed to ask for help, but the idea of support is a selling point.

Keeping it alive is another factor. Paying for the add-on supports its continued maintenance and growth. I don’t want it to go away because it’s a valuable tool for me. The support it’s getting shows. Check out its change log to see what I mean. (http://www.causingeffect.com/software/expressionengine/ce-image/change-log).

So would Pic Puller sell more if there were no free alternatives? I would assume so, but it’s not something I can control. I can only try to make the best add-on I am capable of making. I think the presence of the free add-on actually has made my desire to make my paid add-on even better.


If you’re working on an add-on, becoming rich is not a realistic motivating factor in my opinion. If you want to go for the money, become an investment banker.

Creating software that makes your job and others’ jobs easier is a much better reason to make an add-on. That goal is not tied to whether someone buys a copy of your software or not. You will know if you’ve built a good piece of software. You will know what you did right, and even more informative, what you did wrong. The process will make you a smarter, better developer for having built it. The journey is worth it.

Comments on this post.


Great post. I also buy commercial add-ons that have free competitors because I feel confident that it won’t become abandonware and that it will continue to be supported.

By Sean on Mar 08 2012

now instagram also available on android.

By garry on Apr 05 2012

Leave Your Comment:





your comment:

Remember my personal information

Notify me of follow-up comments?