devot:eeDevoted to ExpressionEngine

On Releasing and Distributing Add-Ons for ExpressionEngine

January 27, 2009
by Ryan Masuga

Photo 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

The 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

The 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.

GitHub

Got 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.