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.