ExpressionEngine is built on top of CodeIgniter, and while the framework is showing it’s age compared to the new hotness that is Laravel, it does have some decent tools for code re-use.

One tool is the CodeIgniter Model class (CI_Model), Models are simply classes designed to contain your application data and are responsible for managing data between your application and the underlying database.

Wait, doesn’t ExpressionEngine’s Database class do the same thing?

Not quite, the DB class is great for working with the database, however it isn’t a very reusable way to do common tasks of saving and retrieving data for your application.

Say you have a table for your add-on called exp_posts. To save a new post you’d use the insert command of the Database class:

$data = array( ‘title’ => ‘My title’ , ‘name’ => ‘My Name’ , ‘date’ => ‘My date’
);

ee()->db->insert(‘posts’, $data);

Seems simple right? Well say you have this code in a few places in your add-on to insert new posts. You also have code to pull the posts from the database. Now you need to add a new column to the posts table and use it in your add-on.

Uh-oh, you’ll have to now update all of the places were you’re working with data from the posts table. It’s not a big deal for maybe one table, but as your add-on grows in complexity suddenly every change becomes more of a hassle and starts creating a large number of bugs in your code.

What we need is a way to encapsulate the idea of a Post into a class were we only have one file we have to maintain when we need to make a change.

Above is an example of how I structure the model classes in my add-ons. You can see we have the common CRUD (Create, Read, Update, Delete) methods. It’s pretty similar to the CodeIgniter documentation with a few differences:

• A method called _get_table() which returns the table name, this is handy because it allows us to refer to the table name once rather than having to repeat the table name in every db statement. I made this a private method instead of an attribute because if it was a class attribute, CI’s insert and update methods would assume that it was a table field.
• Two methods, _set_model_for_save() and _set_model_for_return() which handles the mapping between the fields in the table and the properties of the class

You’ll also note that for one of the properties author_secret we’re encrypting and decrypting the data before and after saving in the mapping methods. By using a Model class I’m able to easily enforce the business rule that this field has to be encrypted when saving to the database. If I ever need to adjust or change this rule (or encrypt other fields) it’s as simple as modifying a few lines in this one class.

Using the model class is pretty straightforward. If you create a subfolder in your add-on folder called models you can use CodeIngiter’s Loader class to instanantiate the model. Here’s an example using my ExpressionEngine module for Rets Rabbit.

If you use the model method of the Loader class, EE will look in your add-on’s models subfolder. Afterwards you can access the model class by using ee()->Rets_config.

Saving data using the becomes really simple, here’s an example of how I use the class to save a new configuration.

Now this is pretty great. But there’s one more bit of refactoring we can do on our model classes to make sure we’re using DRY principles.

Do you remember the three private methods I used in my Post example class: _get_table, _set_model_for_save, _set_model_for_return? Well it turns out that they are the only methods that change from model to model. This means we’re repeating the exact same methods: get, get_by_site_id, insert, and update, which isn’t very DRY.

We can fix this by creating an abstract base class and inheriting our model classes off of it. An abstract base class is like a document template, it contains a common set of reusable code that other classes can derive from.

If you mark a class as abstract you are letting PHP know that it shouldn’t instantiated the class directly, it’s only purpose is to be inherited (if you try to use the class directly, PHP will throw an error). If you mark methods as abstract, you’re telling PHP that those methods must be defined in the child classes. The rest of the methods and properties are common to all classes and won’t have to be defined (unless a child class needs to override them).

Now our Post class looks a lot simpler.

Now whenever I need to add a new Model to my add-on, all I have to do is create a model class that inherits from Base_model and then modify the three protected methods to fit the data I’m storing.

Code re-usability is the mark of a true professional, it’s not sexy, but reliable and maintainable code will help you deal better with support issues help other developers understand and work with your code. As we’ve seen above, CodeIgniter gives us some decent tools to help us encapsulate our data into model classes and keep things DRY.

Patrick is the owner of the development agency Anecka. He also writes articles and guides for freelancers to help improve their development productivity at PatPohler.com.

Reduce the cost of maintaining your ExpressionEngine add-ons with CI_Model was originally published in ExpressionEngine Pros on Medium, where people are continuing the conversation by highlighting and responding to this story.

Whether you’re building an add-on for a client project or plan to sell your add-on commercially, building an API so other code can access your add-on is a great idea.

There are several advantages to building an API for your product:

• It can increase adoption of your software, many companies have sped up their growth by offering an API.
• It allows other developers to provide future functionality and solve problems using your core product.
• It leads to better code; you are forced to think about the issues other developers will face in using your software. This can make you a stronger developer.
• Allows you to use powerful javascript frameworks like Ember, Angular and Knockout for front-end development.

So how would we go about implementing an API in our add-on? First let’s talk about what makes a great API. Great APIs must be:

• Understandable, if it’s hard to use then no matter your features developers wont use it
• Secure, you want to make sure only valid allowed programs have access and user data is protected
• Versioned, you have to plan for new features without breaking apps using older code
• Graceful in handling errors and send back clear and understandable error codes to help the developer using your api diagnose problems

Now that let’s talk about actually building the API. For this article I created a sample add-on called the A-Team Mission Tracker to help my favorite soldiers of fortune track their missions.

So how are external apps going to communicate to our ExpressionEngine add-on? We’ll need to make sure we can expose API methods that respond correctly to GET and POST requests. Typically in CodeIgniter you would simple create a route to respond to API requests, however ExpressionEngine overrides CI’s routing to route requests to EE’s controllers. There’s no way to get around it without making modifications to EE’s core files.

Since modifying core EE files is out of the question for our add-on, we have to find other way. Actions are how EE runs code in core and third party add-ons, they support GET & POST requests and can render JSON & XML.

This sounds great, unfortunately there’s a major problem with EE Actions. Here’s what they look like:

http://www.a-team.com/index.php?ACT=23

http://www.a-team.com/index.php?ACT=33

http://www.a-team.com/index.php?ACT=99

Can you tell just from looking what API methods these URLs map to? Actions fail the “Understandable” criteria big time. Also, Action IDs vary from environment to environment and there’s no way to easily distribute it to other developers.

Fortunately there’s a way to call our API methods without having to use Actions or modify EE core. The key is to use EE’s “sessions_start” extension hook which fires every time a request is made.

Using this extension in the Mission Tracker add-on is as easy as creating an extension class, Mission_tracker_ext, and with a method that will respond to the session_start extension hook.

To explain this method, let’s assume the following GET request is sent to EE, “/api/mission/show_all”:

• Line 29: checks the first url segment against an API trigger word (“api”) if it doesn’t match we ignore the request, otherwise we move on to
• Line 34-35: we check the second url segment (“mission”) if there’s a match it calls CodeIgniter’s loader class (also available in EE). We use the actual segment for our class name. In this example we’re loading the “Mission_lib” API class.
• Line 38: finally we call the “call_method” method and pass it segment 3 (“show_all”), “call_method” will then go into the Mission_lib class and execute the “show_all” method returning a JSON formatted response of missions.

Let me explain the loader class in detail, you can see we passed in a third parameter to “load->library()” on line 35, this powerful parameter let’s us dynamically load any library we want and define a bookmark to it, for example “mission_api.”

Then in line 38, we just use “mission_api” to refer to our class, as long as the class has a “call_method” method, we’re able to use it.

Remember how we said call_method will actually run the API method in the loaded class? Line 21 is how it does it, PHP will execute the $method variable in the class.

By organizing the API around “trigger/resource/method” we can extend the API simply by adding more resource classes (ex. Equipment_lib, Vehicle_lib) and route_url doesn’t change. As long as the resource class implements the call_method method route_url can use it. In order to make it easy, I put the call_method function in a base class that the rest of my resource classes extend.

There’s a lot I didn’t cover in this article, some notes about security and other best practices:

• You can go deeper to secure your API, but at the very least create randomly generated API keys for registered apps. Force the apps to send the get in POST requests (you want to avoid using URLs as the key can be written to server logs). Reject requests that don’t have the proper key
• Use SSL, or HTTPS. It won’t completely prevent man in the middle attacks, but it makes them harder
• Use EE’s input & db libraries instead of raw PHP code to process forms and save data to the db. Be paranoid about any input you get from your API and be extremely narrow what data you’ll accept
• Use CodeIgniter models so your API code can use the same business logic as the rest of your module
• Organize your code into libraries for reusability, move common code for your API into base classes.

Finally here are a few tools to help you debug and test your API:

• JSONLint to validate/test JSON is valid
• Postman is a REST client for Chrome, send & receive HTTP request & responses, very good tool for quick inspection of your API without having to right an app. Although I’d highly recommend learning PHPUnit or SimpleTest and writing real unit tests.
• For Windows there’s Fiddler which is an amazing powerful tool for debugging HTTP requests & responses. It can do security and man-in-the-middle attack tests and has a number of advanced features.

I hope this is enough to get you started in the world of APIs and how you can implement them for your ExpressionEngine add-ons.

Patrick is the owner of the development agency Anecka. He also writes articles and guides for freelancers to help improve their development productivity at PatPohler.com.

Building an API for your Add-ons with ExpressionEngine (and the A-Team) was originally published in ExpressionEngine Pros on Medium, where people are continuing the conversation by highlighting and responding to this story.

So what is a “dependency manager” anyway? I hate that term, because while it’s technically correct it’s a very dull way to describe something that’s so freaking magical. So let me state it in better terms.

Remember in the Matrix how the characters could just download certain skills into their brains and they’d instantaneously have that skill-set in the Matrix? So if one of the characters wanted to fly a helicopter all they’d have to say is “I need to fly that Huey” and BAM they could fly that particular helicopter.

Now in order to fly not only do you need to know all there is to know about basic flight, but you’ll need hundreds of other smaller skills related to the very particular art of flying that model of aircraft (helicopters fly very differently than airplanes). Can you imagine how exhausting it would have been to ask and load all those particular skills (in the right order!) in an emergency? Also different characters might have had different levels of training previously that would apply to flying that would have to be worked out. It would have been almost impossible for the characters to remember and rattle them off before getting killed.

Fortunately the Matrix was equipped with a very good dependency manager so all the operator on the other end had to do was to load the Huey helicopter program and the Matrix would figure out the rest.

That’s what Composer does, anytime you want to load a particular library in your add-on it figures out any other libraries it depends on for you and installs it on your system.

I won’t go into the details on how to install and use composer, but it’s shockingly easy to install and there are very good docs here.

Instead let’s skip ahead to using them in an add-on. I’m building an ExpressionEngine add-on to work with the API product I’m building called Rets Rabbit.

The Rets Rabbit API has a client PHP library to help developers quickly use the API. It’s open source and located on GitHub.

Normally if I wanted to use the library in EE I would just download the source code and copy it to “libraries” folder in my add-on’s file structure. Unfortunately the PHP library also depends on Guzzle so I would have to find and download that library too (and it’s dependent libraries).

Instead I create a simple composer.json file in my add-on directory with the following text:

After saving the file all I need to do it simply run “sudo php composer install” while in my add-on directory.

Composer then creates a “vendor” folder in your directory containing the third-party library and any other needed files.

It also creates an “autoload.php” file that you can use to load your library. Using this in your ExpressionEngine add-on is as easy as using ‘require’

Composer knows how to download and install Rets Rabbit PHP client by checking Packagist.org, which is a global repository of all of the publicly available composer packages.

The most powerful thing about Composer + Packagist is that allows PHP developers to quickly publish and share libraries. This allows developers to focus on making a great add-on without wasting a lot of time re-inventing solutions to problems that have already been solved.

Creating a package for the Rets Rabbit PHP library was really easy. All it required was again to create a composer.json file with a name and description of the package (and any dependencies it required).

Once I checked in this file into my GitHub repository all I had to do was submit the package on Packagist and it became publicly available.

If you’re a PHP developer, especially an ExpressionEngine add-on dev, I hope you give Composer a try. If you have a few handy libraries that are already open sourced and on GitHub consider making them into Composer packages for others.

Patrick is the owner of the development agency Anecka. He also writes articles and guides for freelancers to help improve their development productivity at PatPohler.com.

Turbo-charge your ExpressionEngine Add-Ons with Composer was originally published in ExpressionEngine Pros on Medium, where people are continuing the conversation by highlighting and responding to this story.