On Releasing and Distributing Add-Ons for ExpressionEngine

January 27, 2009
by Ryan Masuga

What is the best way to distribute add-ons for ExpressionEngine? Devot:ee takes a look at the currently available avenues and asks the rhetorical question, “Could this be better?”

BoxicityPhoto by Syntopia via flickr. (cc)

ExpressionEngine has grown quite a bit in the 2-3 years I’ve been using it. The community has grown and the overall user base has expanded. As more people have adopted it and learned the inner workings, there have been more and more add-ons (extensions, modules, and plugins) created to expand EE’s default capabilities. This is great because it means more people can reap the benefits of all that extra development, but with the recent proliferation of 3rd-party ExpressionEngine-related sites, and the recent adoption of GitHub as a source code repository by many bright names in the EE development community, that original add-on distribution method may be on the way out.

Current Methods

Here are the main ways that EE users are currently and most commonly releasing, distributing, and finding add-ons:

  1. EE forum thread
  2. The official ExpressionEngine add-on library
  3. A developers’ own site

And here are a couple of the newer ways add-ons are being distibuted:

  1. A 3rd-party site (possibly one like devot:ee)
  2. GitHub

I’ll touch on all of these methods in turn.

In the Beginning: Releasing Add-ons in an EE Forum Thread

Add-on Thread in the EE ForumsThe most common way to distribute add-ons for EE: An EE forum thread with the file as an attachment in the first post. Seen here is Mark Huot’s classic Edit Remember.

Up until fairly recently, the main, and practically only, way to announce releases and distribute 3rd-party EE add-ons has been the EE Forums. The common method is to start a new thread and attach a zip file to the first thread in the post. This has worked fairly well, except that there are almost no rules or guidelines for this method.

The idea for this article started on this thread about not being able to scroll back to a submitted comment. This add-on was made and distributed in the “normal” manner: someone makes a request, and someone fills the void, posting the result to the EE forums. The whole exchange went like this:

  1. I make request for ability to scroll to comment after posting comment
  2. Someone seconds that motion, and bumps the thread
  3. Other user can’t wait, so makes a new extension that does what I wanted, and posts the entire code of extension in a codeblock in the third post
  4. I make a suggestion: “If this works as advertised, I’d zip it up, call it 1.0, and start a new thread in Plugins called “Plugin: Scroll to Comment”, (my fault, I should have realized this was an extension -ryan) and attach it to the first post in the thread. That seems to be one of the most accepted methods for distributing add-ons, and would make it easier for people to find.”
  5. Extension author does as suggested, but into “incorrect” forum
  6. EE Moderator moves the thread to the Extensions forum
  7. Ahh, finally. New Extension file is posted as an attachment to the first post of this thread in the Extensions forum, with a fairly descriptive title: Extension: Scroll to Comment
  8. I won’t even go into how the extension file is named (not that it’s wrong or bad, but we have enough to talk about for this article)

Problems With EE Thread Inconsistency

Many times, the developer won’t overwrite the file in the 1st thread post with a new version, but will attach updated files to a later post, that may be buried 7 pages down the line, forcing users to wade through any number of off-topic comments, support requests, and other detritus.

Other times, the developer will just post the entire code of their add-on as a codeblock in the post (as in the above example), making the potential user have to copy all the code, paste into a file, and save it on their own. Not the most convenient method.

There’s no guideline for titling the thread, or the file(s), either. My suggestion has always been to prefix the thread title with the type of add-on you’re posting, such as “Extension: MD Dulee Noted”, or “Plugin: Weegee”, but not everyone follows that.

The Official ExpressionEngine Add-on Library

EE Add-On LibraryThe official ExpressionEngine Add-On Library. Sort of like a real library – pretty quiet.

It sounds official. It is official. However, in all the time I’ve been using ExpressionEngine, this is the last place I look for add-ons, new or otherwise. It seems like the last place most developers go to release an add-on, or that it is always an afterthought. I’ve made over 15 EE add-ons myself (not all public), but I don’t have a single one in the EE Add-On Library. Multiply that by many, many other developers and you see that this Library is probably in no way representative of the breadth and scope of available EE add-ons. Devot:ee currently has over 300 add-ons catalogued (that’s over twice the number in EE’s own Library!), and I know that we’re still not aware of everything that’s out there.

The EE Library should be the place to go, but for some reason it doesn’t seem like it has ever been used to its full potential. Part of that may be an obstacle that isn’t there when simply posting to the forums: your add-on has to be accepted to be included here.

To further complicate things, at the time of this writing there is currently a moratorium on add-on submissions, so no one can distribute via this method in any case.

Developer Sites

Over the last year many developers have put together areas of their own sites that house their own EE add-on work. This is a great evolution in that these people are taking the initiative to do this, but there can be some problems:

  • Totally decentralizes where EE users have to look
  • Every developer’s site is different

I’ll think I’ll take this method over the forum method or the EE Add-On Library any day, knowing that I’ll have to keep a few more sites bookmarked. It’s either that, or add a site to the (unfortunately, in many ways useless) ExpressionEngine Wiki page titled List of Add-On Sites whose purpose is to try and keep track of 3rd-party developer sites or even add-on related threads straight from the EE forums.

Ever been to the Wiki page? I have, exactly twice: Once to take a look a few months back, and once to reference the link to it for this article. And I was even largely the impetus for the list getting started! (The developer who started the forum thread to gather these links, was working for me at the time, helping me with the early stages of devot:ee)

So, those are our current methods of distribution. Let’s look at a couple other ideas.

Is a Central 3rd-Party Site With an RSS Feed the Way to Go?

I believe this is what the ExpressionEngine Add-On Library was supposed to be. It might be due to the fact the EllisLab simply doesn’t have the manpower to spend a ton of time approving add-ons and adding them, when they’re so busy working on making a fantastic CMS and dealing with ridiculous threads in their forums that hash and re-hash old, tired subjects about pricing and release dates. So, if EllisLab can’t do it themselves, who can? Let’s use devot:ee as an example.

When I started devot:ee I was insane. I wanted to offer everything to everyone, and I forgot there are only 24 hours in a day, and that I’m really the only one running the show here, in any and every capacity. The more time I’ve spent working on devot:ee and doing some writing, I realize that add-ons, and not just my own, are what I want to focus on. I love finding them, love using them, love trying to improve them.

That said, let’s assume devot:ee had a goal not only of cataloging every EE add-on known to man, but also of offering the download, with an RSS feed, etc etc, essentially becoming the 3rd-party version of EE’s Official Library. Think of the logistics: some add-ons are commercial, some are 1st party, and some people may just not want their add-ons being downloaded from someone/somewhere else, no matter how effective it might be. Some devs are idiots, some are proud, some add-ons are junk, and so on. Trying to keep that straight would take some serious people-hours. I can see why EllisLab had a submission process. If they are hosting your download they want to make sure there are no shenanigans going on.

So that could be a big mess and devot:ee’s goal isn’t quite that lofty. The goal of devot:ee regarding add-ons is to be the site of choice for add-on information, for everyone – but not necessarily the place to download these things. Maybe there’s another way that people can distribute add-ons, including downloads, where people can even easily grab your source code to help you improve your add-on in as smooth a method as has ever been seen in the ExpressionEngine world.


A Public EE Add-On at GitHub: MD Live SearchGot Git? A Public ExpressionEngine Add-On repository at GitHub: MD Live Search. 1) Fork the project. 2) Download the add-on. 3) Link to the developer’s site 4) The files included in the download

The Nitty Gitty

Over the past couple weeks quite a few EE developers have been popping up on GitHub.

What’s Git? Git itself “is a fast, efficient, distributed version control system ideal for the collaborative development of software” and GitHub is a site that provides a central place for developers to collaboratively work on their projects. Git is free, and relatively easy to use—especially if you already have experience with version control.

There’s quite a list of EE devs on there so far: Leevi Graham (Newism), Brandon Kelly, myself, Nathan Pitman, Tim Kelty, Chad Crowell, Matthew Pennell, Ryan Irelan, Mark J. Reeves, and many others.

Leevi has suggested a naming convention by which everyone can find other ee addons at GitHub. He suggests to add “ee_addon” to the end of each project name, which almost every dev there has adopted. Theoretically, you should be able to search for that term (though I’ve found the search to be a little less than effective at GitHub so far). Though an account isn’t necessary, if you have an account at GitHub, you can “follow” all your favorite devs, and “watch” your favorite add-ons.

Downloading ExpressionEngine Add-Ons From GitHub

Downloading add-ons from GitHub is as straightforward as downloading them from anywhere else. There is a download button on each repository page. Do you need Git to do that? No. If you’re a regular, normal user of EE, you don’t have to be afraid of anything. You’d don’t need Git on your machine, you don’t need to learn Git, and you don’t need a GitHub account. Click the download button and you’re done.

Fork You

A big plus of keeping add-ons in repositories at GitHub (other than version control, obviously) is the ability to easily fork others’ work and improve it. This is a major advantage, and could lead to much faster improvement in all EE add-ons.

Take a real example from this past week. I had taken Mark Huot’s Live Search extension and added a number of things to it. I posted it at GitHub. Tim Kelty was able to fork the project and add a number of changes and improvements from Karl Swedberg. Tim then sent me a “Pull Request”, which is like saying “Hey, I made a couple changes you might like, maybe you want to merge these back into your project.”

I tested out the submitted changes, and then merged their work into the main “master” project, and called it version 1.1.9, which was then available for immediate download (no extra step on my part at the dev to zip it up, as GitHub offers that automatically).

The only other thing to do was to increment the version number at my site, which updates the XML template needed for LG Addon Updater notifications, and then tweet about it.

Where Git May Not Work

Odds are, if you’re a dev and know enough to write a plugin, module, or extension, you can get up to speed with using Git, but there’s still a bit of a learning curve there that you may not want to bother with. An area where Git may not work for distribution is if a developer is selling commercial versions of a script, or if they prefer to offer downloads from their site (maybe for tracking purposes). As far as I can tell, there is no way to track the number of downloads from GitHub.

Got All That?

I think EllisLab and the ExpressionEngine community may be outgrowing the current method of distributing add-ons primarily through the EE forums. A forum format will only get you so far. But this is all a good thing—growth is good, so let’s roll with it because it will benefit everyone.

The proliferation of 3rd-party sites hosting their own contributions is certainly a welcome evolution, but it could end up being as difficult to keep track of add-ons this way as it is in the forums. At least in the forums, they’re somewhat centralized, if not a little hard to find through lack of convention. Distribution could be flaky depending on how a developer presents their download links. Good design will be key.

Git and GitHub seem almost like an ideal way to distribute new EE add-ons, with the added benefits of version control and collaborative improvement. It’s consistent, items are easier to search here, GitHub can be tied to any number of 3rd party API’s for update notifications, and developers can help each other out by forking each others’ work.

Since the time I started this article, the “Scroll to Comment” add-on outlined above has been added to Github, and follows Leevi’s suggested naming convention.


Chad Crowell 01.27.09

Ryan, great summary of the situation and suggestions for improvements.  Her’s to hoping everyone “git“s on board!  (OK that was the lamest thing I have ever typed”

Just one other note: you are still insane.

Stephen Lewis 01.27.09

Thanks for an interesting article Ryan.

One of the many long-planned editions to my site is a section to house the various EE add-ons I’ve authored.

The idea was that my site would provide the file, version history, and usage instructions, and a thread on the forum would act as a discussion and support area for the add-on. You know, like forums are supposed to work.

Of course, this recent migration to GitHub by the great and the good of the EE community has thrown that entire plan into turmoil. I notice that GitHub even has a wiki associated with each project, which could happily accommodate documentation.

Looks like my site won’t be getting that upgrade after all.


Stephen Lewis 01.27.09

“Editions”? Additions even. Numpty.

Jason 01.27.09

Great article. I’ve not used GitHub yet, but it sounds very promising. At this point, anything will be better than the current forum-centric method. Which is not a knock against EllisLab or anyone on the forums; forums just are the best distribution method for this sort of thing.

Matthew Pennell 01.27.09

Nice article, Ryan. It only took me an hour or so to get up to speed with Git, setup my new GitHub repo, and get my extension hosted there. (In fact I think I spent longer tweaking the new graphic treatment on my site to link to GitHub resources than I did setting it up in the first place!)

It’s still not perfect, though, I think – you’ve still got the issue of documentation (GitHub asks for an external link, so you’re still coping with many diverse personal sites), and there’s no consistent way of formatting the README file; plus the licensing/commercial issue you mentioned seems unlikely to be solved at the GitHub level.

Ryan Masuga 01.27.09

Ryan Masuga

@Matthew: Regarding documentation, each repo/project does have a wiki page. See this example GitHub Wiki page being used for GitNub

One thing I like, as a dev, is that I don’t have to bother with the downloads on my site, or even bundling the files into a Zip. I can still keep a “homepage” for the add-on, but let the downloads come from GitHub.

The README files can use textile or markdown for text formatting. See this article on formatting ReadMe files at Github. I’m using Textile to format mine. I’ve been trying to be consistent with mine: title, info, installation, changelog.

Regarding commercial: I do have MD Markitup (my only commercial offering) at GitHub – but in a private repository. There’s an extra step involved there. When I have an update, I need to download it myself and move it to my site so it can be downloaded only through my download script.

You’re correct – the whole Git thing isn’t perfect. But I do think it’s important, going forward, for ExpressionEngine add-on developers to start adopting conventions and certain ways to do things, whatever they might be.

Not everyone will agree – but the conversation is started. I’m an add-on maniac and I just want things to be ever better.

Sean 01.27.09

Just last week I was asking about a centralized location for “all known modules”. This post addresses that to a large extent. I’d still somehow like to have an RSS feed or single searchable location for all add-ons (not necessarily to download from that location).

Anyhow github looks like a good solution for addon coders.

Ryan Masuga 01.27.09

Ryan Masuga

Sean: In case it isn’t clear enough for people, devot:ee is aiming to be that centralized location for all known add-ons (not just modules, but plugins and extensions, too).

I have the this resource in development right now, and you should see it in February. No downloads, but the most complete list of add-ons anywhere. It’s pretty nice, if I do say so myself.

Sean 01.27.09


you d’man!

Will Bolton 01.27.09

So do you have a fairly complete list already of known add-ons? I’ve bookmarked a whole load of stuff on that may be worth looking at:

Also +modules and +plugins

Ryan Masuga 01.28.09

Ryan Masuga

@Will: I have over 300 add-ons in the library right now, but it goes further than “just a list” of add-ons or links to add-ons. There will also be some interesting help in here for developers that I think is quite unique.

Will Bolton 01.28.09

@Ryan: I’m looking forward to seeing what you’ve come up with. Keeping track of third party add-ons is a nightmare, so here’s hoping you’ve solved it.

You must be registered member to comment. If you're already a member, log in now, and if not go register (it's free and easy!).