At Focus Lab, one service we offer our clients is custom add-on development for ExpressionEngine. We started dabbling in add-on development about a year after first using EE. It was a foreign land for quite some time, but eventually we noticed the positive impact it was having on our business. Over time, we found ourselves able to say “Yes, EE can do that,” to far more requests than we once thought possible. Eventually, our add-on work led to Focus Lab partnering up with Train-ee to provide add-on development training in the classroom.

Over the past few years, I’ve worked with a number of other developers who have the time and experience to learn how to build add-ons, but simply haven’t slowed down to do so. I seem to rehash the same benefits to each of them, so I wanted to put those benefits out on the blog today for all to consider.

Here are some really good reasons why you should learn to build (or customize) add-ons for ExpressionEngine:

You learn more about how the system works

ExpressionEngine has numerous twists and turns on any given page load. Building add-ons helps you learn where these are and better understand what happens when you use a website. This knowledge helps you not only build better add-ons, but also choose existing add-ons better by knowing what’s possible and appropriate within the system.

You can say “yes” to more features

Out of the box, a CMS only does so much. That’s a fact. Expandable CMSs give 3rd party developers the ability to add features without hacking away at the core code. Learning about EE’s system, and how to build add-ons for it, gives you the ability to say “Yes, we can build that into EE,” to a client or product owner.

Save money and time for your project

Currently, when you discover a need for a custom add-on in a project, what do you do? Chances are you either hire a company (like Focus Lab) to build one, you bend EE and/or existing add-ons to do something they aren’t really built to do or you forgo the feature all together. If you can build the add-on yourself, you not only save time and money up front, but the continued maintenance and feature additions are also easier to access down the road.

Get better at planning

In the early stages of project research, proposal writing or project planning, you need to know if certain requirements are possible (and/or recommended) with EE. Learning the ins and outs of add-on development provides more clarity during this research and will speed up the process quite a bit.

Get better at debugging

Debugging (or troubleshooting) problems is incredibly important when building websites. ExpressionEngine has so many layers that it can be hard to immediately identify where a problem lies. The process of learning to develop add-ons gives you additional knowledge for debugging use that you wouldn’t otherwise have.

Fast Prototyping

ExpressionEngine has numerous “types” of add-ons. If you understand what each type is for, and how it is used within the system, you can quickly and easily prototype add-on features before spending an insane amount of time (and money) figuring out if something is possible.

What Others are Saying

Don’t just take my word for it though, here are some thoughts from other ExpressionEngine developers who sport add-on chops in their daily work:

Whether you’re a freelance developer, a web development firm or an in-house team, knowing how to build add-ons for EE (or any system for that matter) gives you the ability to get the most out of your software.

Today we continue our ABC’s of Add-on Development series. If you recall from the first post, this will be a 6-part series covering various aspects of ExpressionEngine add-on development in which we will cover one topic for each letter of the alphabet. My friend and fellow developer Tom Jaeger is assisting along the way. He and I will cover the next set of letters today, B-F.

B: Bug Tracker

By: Erik Reagan

I know what you’re thinking. “Bug tracker? Seriously?” Well, yes. Seriously.

One of the least glorious parts of using any software is searching and contributing to the official bug tracker. In the case of ExpressionEngine, there are actually two bug trackers you may end up using. There is an ExpressionEngine bug tracker and a separate one for CodeIgniter on GitHub (recently moved from BitBucket).

Should you encounter an issue during add-on development, immediately assume that the issue is yours. Do everything you can to eliminate your own code as the source of the error. Then, if you’ve found an issue with ExpressionEngine’s (or CI’s) core code, first search the Bug Tracker(s) to see if someone else has reported it. If no one has, take some time to poke around in the code to see if you can fix it in a small amount of time. Ultimately it’s your responsibility to report a bug that you find. This is a simple way to have a positive impact on the software you use and love.

Before moving on, a quick warning. Not every bug you file will be officially recognized as a “bug”. Sometimes what you call a “bug,” is simply a feature that doesn’t exist (which would lead to a Feature Request, hopefully). Other times, the EllisLab staff may not internally acknowledge what you have identified as a bug. Either way, don’t expect a 100% success rate at filing bug reports.

C: CodeIgniter

By: Erik Reagan

No add-on lesson is complete without a reference to CodeIgniter (CI). The thing that drew me to ExpressionEngine for the first time was knowing that the 2.0 release would be built on CI. We were already using CI and favored it among other PHP frameworks. I had even considered rolling out my own CMS with CI prior to trying EE. I’m glad I didn’t go down that road.

CodeIgniter is packed with numerous, handy tools ready to be used in your EE add-ons. Before diving into add-on development consider spending time reading the CI docs and other CI tutorials. In the past couple of years a number of great CI resources have cropped up. Here are a few:

• Official User Guide
• CodeIgniter From Scratch - series on NetTuts
• CodeIgniter Articles on gotphp.com
• learn-codeigniter.com - Only 2 videos so far, but they're quite good
• A Gentle Introduction to CodeIgniter
• CodeIgniter Directory

I say this often, so I can’t leave it out here. Your EE add-on development will only be as strong as your CodeIgniter, PHP and MySQL knowledge will allow.

D: Database

By: Erik Reagan

Similar to the “C” in our series (CodeIgniter), your EE add-on abilities will depend on your understanding of EE’s database schema and data placement. You won’t need to know anything about the database if you’re simply writing a Plugin to process input and return simple output. However, if you want to work with Extensions, Modules, etc., you’ll need to understand how data is stored in EE.

Using the common Channel Entry as an example, did you know that a given entry could involve the following tables:

• exp_category_posts
• exp_channel_data
• exp_channel_entries_autosave
• exp_channel_titles
• exp_comment_subscriptions
• exp_comments
• exp_entry_ping_status
• exp_entry_versioning
• exp_relationships
• exp_sites

Not every entry will involve each of these tables, but if you use any 3rd party add-ons such as Structure, Playa or Matrix, your Channel Entries may be referenced in a 3rd party database table. For this reason it’s very important to understand how the data is stored when using EE. It can take some time to truly understand it since there are so many tables at play. Ultimately, it’s worth the time it takes though.

Database Prefix

If you've ever installed ExpressionEngine you may be familiar with the database prefix setting. Out of the box ExpressionEngine uses "exp_" as a prefix to all database tables. You can, however, change that during the installation process. This is important to add-on developers because sometimes a user may change that prefix. If you're writing queries manually you need to be aware of this setting and pull in the prefix from the config object. (If you stick to using CodeIgniter's Active Record methods you don't need to worry about the prefix. Active Record will detect that automatically for you.) If you need to use the prefix in your code you can access it like this:

$dbprefix = $this->EE->db->dbprefix;

GUIs

Something else worth considering is the use of a desktop database application. We use a combination of Sequel Pro (seen below) and Navicat for MySQL in our development. Using such an application makes working with and exploring a database much simpler.

E: Extension

By: Tom Jaeger

In ExpressionEngine, there are a few fundamental ways to expand native functionality. One of which is Extensions, the “E” entry on our list. Extensions utilize little snippets of code within ExpressionEngine known as hooks. There are currently over 100 hooks in ExpressionEngine, strategically placed to allow third party developers to “hook” into the applications’ flow and insert code to be executed. The code that is executed is known as an Extension, because it “extends” the default behavior of the application.

Within ExpressionEngine I generally like to think of hooks as being in one of two flavors (or variations there of).

1. Hooks that allow you to modify or extend the application flow of ExpressionEngine
   Example of this type of hook in the core:
   $this->EE->extensions->call('entry_submission_absolute_end', $this->entry_id, $this->meta, $this->data, $orig_var);
2. Hooks, that in addition to above, allow a third party developer to modify existing data within the ExpressionEngine flow - They do so by passing variables from the EE core into an Extension, allowing a third party developer to modify the data and return it back to the EE core for continued execution with the modified variable.
   Example of this type of hook in the core. Please note that the output from an extension that is called by this hook will be assigned to the $str variable for continued execution, with a possibly changed $str variable
   $str = $this->extensions->call('typography_parse_type_start', $str, $this, $prefs);

Extensions have a few required variables and methods which need to be taken into account when developing to ensure they are usable within ExpressionEngine. For more on these requirements take a peak at the official extensions documentation and the hooks library.

F: Fieldtype

By: Tom Jaeger

Another fundamental way to expand native functionality in ExpressionEngine is through the use of Fieldtypes. Fieldtypes allow a developer to create new content via form input fields, or “field types”, to be used within channels for the publishing of data in ExpressionEngine. Fieldtypes can handle all kinds of content in a variety of ways and forms, including video content, user polls, WYSIWYG’s and data matrixes.

In addition to creating new channel fields within ExpressionEngine, Fieldtypes also allow you to create template tags through the use of the replace_tag method and support the use of both a single template tag and a tag pair for the rendering of content.

All field types inherit the EE_Fieldtype class which provides you with a base on which to start development.

For more information on Fieldtypes and Fieldtype development please take a look at the official fieldtype documentation.

Last week I had the honor of presenting at EECI 2011 in Brooklyn, NY. In the time that I've been using ExpressionEngine I had only met (in person) about ten people from the community. Attending such an event was long overdue and I was thrilled to be there. The content and speaker lineup was fantastic and it only solidified the fact that we use awesome software. My presentation was a lot to soak in, so I'm following up with some additional resources, my slides and most importantly - our EE config setup (as promised).

Version Control / Git Resources

In my presentation I discussed a lot of why you should be using a VCS in your workflow, but I didn't touch on how due to time restraints. Here is a list of resources you may find helpful:

• Pragmatic Version Control using Git - Great book on learning Git
• Git for Designers
• Beanstalk Guides - "Articles, tips and best practices to help you make the most of your design and development workflow." - by the Beanstalk / Wildbit team
• 16Toads Git resources - Resources collected by Paul Burton while diving into Git
• Developing ExpressionEngine sites with MAMP, Git (Tower) and Beanstalk Part 1 & Part 2 - by John Faulds
• PeepCode Git learning - Excellent resources for learning Git from PeepCode
• A web-focused Git workflow
• A successful Git branching model - The "git flow" model I mentioned being good for software / add-ons
• Version Control for ExpressionEngine Using Git - by Ryan Masuga (of Masuga Design & Devot:ee)
• Using Git to Manage an ExpressionEngine website - Part 1, Part 2, Part 3, - by Stephen Lewis (of Experience Internet)

Environment Config Setup

Another part of my presentation showed some code samples from our EE config setup. We've extracted the core of this setup into a GitHub repository for all to check out. I'll spare the technical details and just say you should check out Focus Lab's Master EE Config repository. If you would like to contribute to the code, there are notes in the repo regarding how.

Take a look and let me know if you have questions (below in the comments).

Slides!

Lastly, you can view the slides below or download them here.

Thanks again for the great feedback after the presentation. Feel free to drop me a line in the comments below or on our contact form if you would like to discuss my topic any further.