ExpressionEngine 2 Week: Add-on Development
ExpressionEngine 2.0 has become more of a framework for add-on development then previous iterations. The changes that the development team have made to the backend will have a remarkable effect on the complexity and customization of ExpressionEngine in the future. In this article, we’re going to talk about what it means to develop an add-on for ExpressionEngine 2.0.
Easy Installation
One of the significant changes with ExpressionEngine 2.0, is how much easier it’s going to be to install add-ons. Add-ons are no longer divided into separate folders. You’ll no longer have to put a file in the extensions, language and (for some) themes folder. This is because Add-ons are now folder based in a directory called third_party. Everything goes into the an add-on folder: extension files, language files etc. Not only does this make the installation of add-ons easier for the user, but it makes it significantly easier for an add-on developer to plug and play their add-on.
Here are two use cases for the new folder-based add-ons.
Let’s say you always use a certain group of extensions and modules for your application. We all have them. Over time we’ve just learn to build quicker and better with certain extensions. Instead of going through each individual extension (or for the more technical minded, create crazy symlinks everywhere), you just drop in the addon folder to the third_party
folder in the EE application folder. In fact, you can drop in each add-ons’ folder as they are their own self-contained unit. You go through the normal process of installing an extension or module in the control panel, but still, each add-on is now it’s own mini-application.
Another use case for this is that many developers use Git to build their add-ons. No longer will you be required to pull the latest from the repo and then manually copy and paste. You can create your own versioning repository that pulls in the latest versions of your developers add-ons, and just do one quick checkout to install them all. This will be a great benefit for those of us who use source control as a means of getting our extensions in.
But wait, there’s more…
Not only are add-ons now a self-contained unit, but they have their own view files. If you’re a developer, this means you no longer will have to use ExpressionEngine’s display class. It breaks one of the barriers of entry to EE development by allowing the developer to create their own markup. In case you don’t know what a view file is, a simple way of looking at it is a html, php, or other template that pulls in your add-on’s php code. This means that prototyping and testing add-ons will be phenomenally quicker.
You also get access to models now, contained in its own folder, in your add-on directory. Models, for those of you who don’t know, are PHP classes which you use to access the database. If you’re accessing the database and modifying, creating or sending that data to the user, you will need to learn to use models. If you’ve heard the term MVC, the approach to an addon is the MVC pattern. You have views, models and your extension/module PHP file is the controller.
Another benefit of this now contained add-on folder, is that you can put in several other files and folders that will help ease development. Updates, for example, are no longer a part of your PHP class, but instead are in a separate file to migrate your extension or module to a new version. You can put your add-on’s javascript into its own javascript folder and load it using Codeigniter conventions. Helpers, another CodeIgniter convention, are little functions that you can put in a folder that are just utility functions (of mixed type, not a class) you build for your application.
Get to know this line, because it’s how you load javascript files into the control panel from your add-on:
$this->EE->cp->load_package_js('my_file');
One of the best part of CodeIgniter is that you can plug in a library (such as a Twitter library) and use that to immediately access a resource in your application. This functionality is included in the add-on folder you build. You can put libraries which will not only keep your code DRY, but also allow for loose coupling. In many ways this helps to expand your add-on to other uses by offering additional libraries and functionality.
Also, as mentioned earlier this week, EE 2 has the option of accessories, which you can store in your ExpressionEngine third_party add-on folder. You can create a piece of documentation, screencast and help guide links within your module or extension. Not only will this help the end user see, right on your module’s setting page, how to use your add-on, but also give them easy access to your documentation, other add-ons or support links. Accessories will let the user get help while viewing your add-ons pages.
No longer will you rely on ExpressionEngine to hold your add-on specific configs. Instead, users and you will be able to modify the configuration settings in your add-on’s very own config folder. This will keep the add-ons from interfering with EE, and allow users to easily install your extensions and modules.
There are several other wonderful features that just make EE 2 the sweetest gift to developers (other than pie).
The control panel is automagic!
The control panel will flash success and error messages, and will automate breadcrumbs (down to the controller it’s automatic, so you only need worry with setting breadcrumbs for methods or deeper). You only have to worry about the primary content area of the page for your module control panel (the view), not the stuff that wraps around it. Adding markup, stylesheets, or scripts to head
no longer require extensions.
No more globals
There are no more global classes and you have automatic access to all the classes. There is the ExpressionEngine super object, which will become your best friend, and which you will load with great might to create new and interesting pieces of data. It’s simple:
$this->EE
Those two segments mean: this current CodeIgniter instance and the EE object (superobject/application/whateverfitsyourfancy)... and they will rule your world.
Documentation
Unfortunately, I can’t show you the documentation, but I can guarantee you this: The ExpressionEngine 2.0 Add-on documentation is much more thorough and easier-to-read than it ever has been. Hopefully this will bring many of you into the fold.
CodeIgnited.
ExpressionEngine really is just an application that sits in the CodeIgniter system folder. This means you can CodeIgnite the crap out of it, beyond just the third_party area, and with plenty of ease.
What to expect.
While EE 2 has a nice polish, and some very welcome UI changes there’s not much that has changed, philosophy-wise, on the front-end. However, there is no doubt about it: ExpressionEngine 2.0 is a release for developers. It is an amazing and solid framework for building really incredible things with, and the hard work that EllisLab has put in really shows the most here. They have built this so that we can expand it, and the access to the system, the API, the views and the EE object mean a whole new type of ExpressionEngine for developers.
I suspect that if you were wowed in the past 2 years with some of the great, interesting and mature add-ons that appeared… you will be blown away in the next two years.
Brandon Kelly — 09:47 on 10.29.2009
Totally agree that EE 2.0 is all about developers. Not just us third party people, but EllisLab as well, who now have a lot less duplicate code to maintain.
I
Phil Norton — 11:01 on 10.29.2009
@Brandon: I for one can’t wait to see what talented guys like yourself can add to EE 2.0 using CodeIgniter. And I’m also looking forward to seeing what I can do with the combination too!!
Jack McDade — 12:48 on 10.29.2009
I think I speak for all addon devs when I say, 2.0 is a breath of fresh air and a gateway to a whole new world of opportunities. However, we all have a lot of work to do to bring 1.6.x addons up to 2.0’s playing field, but it will be worth it.
Brandon Kelly — 12:57 on 10.29.2009
? A whole new world!
A dazzling place I never knew! ?
Kenny Meyers — 13:24 on 10.29.2009
?But when I’m way up here, it’s crystal clear?
Brandon Kelly and Kenny Meyers, at the same time — 13:28 on 10.29.2009
? That now I
Avi Block — 15:00 on 10.29.2009
EE Superobject? What kind of developers are they planning this for? What other kinds of anti-patterns are in store in EE 2.0? (That said, it’s still a *vast* improvement over 1.x
Kenny Meyers — 15:03 on 10.29.2009
The CodeIgniter object ($this) is available through CI application. It gives you access to the load function anywhere which can load libraries etc.
In ExpressionEngine (the CI application), the same could be said (I think, though not confirmed) for the $this->EE object. It’s just one of the underpinnings of a CI application.
Avi Block — 15:30 on 10.29.2009
The CI object sounds like a “service locator” to me. In general, I prefer to use a DI container to get my services to where I need them. The EE object described here is starting to sound almost like a “god object”, which is a big no-no. It sounds like they’re hiding the previous global variables behind some big object, to pretend that no EE no longer has any global variables.
The big downside of a service locater, is that you now have a dependency on it, and you can’t mock it out easily if you want to test without it.
Jason Hudnutt — 04:38 on 10.30.2009
Nice write up, I’m still wondering why they decided to even keep the extensions/modules setup and why they didn’t just move to an “add-on”. I understand the differences between extensions and modules but it seems like that is the path they are slowly moving to.
Either way, I’m excited to hear that add-on documentation will be thorough this time around.
GeoffC — 23:34 on 10.31.2009
Thanks for the write up (and all the other EE2 goodies on the site).
Very much looking forward to writing lots of new addons for EE2 using the power and flexibility of CI.
Fun times ahead!
Jon Z — 15:38 on 11.01.2009
Ive used CodeEgniter for over a year and EE for about 6 months and coming from a developers standpoint adding CI to EE might win me back to developing on EE as a choice. I have been forced to use EE at my job and with CI experience EE slows my development time down. EE creates a crutch for developers and those developers willing to run a race with a crutch will surely lose the race. Now with CI integrated, I feel EE is going to be a CI developers jet packed boost.