CodeIgniter 1.7 Professional Development is a complete soup to nuts overview of the CI framework. Coming in at 10 chapters and around 260 pages this book is perfect for those new to CI. The book starts out with reviewing CIs MVC architecture, system libraries and form validation techniques. Then the author dedicates 2 chapters to user authentication and walks you through building your own authentication solution (includes details on oAuth and Facebook Connect). Application security, large scale development and extending CIs core is also covered in later chapters. All in all this book provides a very well rounded sampling of topics for complete newbies and experienced developers alike.

The one chapter I found most informative was chapter 8 Web Services. Like most developers, I have done quite a bit of work with consuming APIs but never had to write one of my own. Recently however I was charged with the task of writing an API that other developers would be interacting with and I had to stumble along and come up with my own solution. In chapter 8 the author reviews web services in depth and how to create your own REST service using CI. Very helpful for those new to that particular topic.

To be honest, when I first received the book I was a little disappointed. I’m not a CI beginner so I was hoping for a lot more advanced items, answers to questions I’ve been struggling with myself. But after spending some time with the book and writing this review I think I have changed my tune. The author spends ample time on the basic stuff but also finds time to touch on more advanced topics like user authentication (with oAuth and Facebook Connect), application security and web service development.

If you are a professional web worker who uses CI in your day to day activities then you should consider getting this book. There is a little something for everyone.

Related posts:

1. CodeIgniter 1.7 Professional Development
2. 10 Reasons Why CodeIgniter Rocks
3. Never Buy Another Tech Book Again!

Related posts:

1. Review: CodeIgniter 1.7 Professional Development
2. Building Applications using CodeIgniter (Part 2) – Configuration
3. Never Buy Another Tech Book Again!

Related posts:

1. Implementing Facebook Connect (Part 1) – What is Facebook Connect?
2. Implementing Facebook Connect (Part 3) – Accessing Data from Facebook
3. CI Inferno

So far in this series I’ve discussed my typical application structure, configuration and helper files when developing apps using CodeIgniter (CI). In this final post I’ll review creating code templates for quick consistent development.

There is nothing really functional/technical about code templates. Templates are a set of simple files that have the basic document structure for the specified file (controller, model, library, etc.) that you use as a common starting point when creating any new file for your app. Your template should contain common elements to all files like the header comment block, class declaration, constructor, etc. There is no need to come up with your own standard when creating your templates because CI has a very nice style guide you should follow.

CI Style Guide

A few versions ago, CI added a page to their users guide entitled PHP Style Guide. In this section they do a great job at outlining the proper format when declaring variables, writing comments, naming files, etc. This is a great place to start when creating your templates. If you don’t already, you should think about getting in the habit of following these standards (even if you aren’t programming with CI) because they will help keep your code clean and consistent.

Template Files

Before I start coding my app I typically create a template file and place it in the controller and model folders. The templates are different of course, but they both create a nice starting point whenever I need to create a new file. It’s important to note that you don’t necessarily have to create physical template files to accomplish clean and well formatted code. Some tools like Coda and TextMate give you the ability to save bits of text and reuse them in your files. So you could create your header comment block and save it in your editor and just call upon that whenever you create a new file. Doesn’t really matter how you do it, it just matters that you do.

That’s a Wrap

OK… lecture over. That does it for the building applications using CodeIgniter post series. If interested, you can download a copy of the final CI install that we’ve created over the last 4 posts with helpers, code templates and all.

I hope by sheding some light on my process and explaining how I do things you came up with some ideas on how you can improve your own CI apps. As always, feel free to leave any questions or feedback as a comment below.

Related posts:

1. Building Applications using CodeIgniter (Part 1) – File Structure
2. Building Applications using CodeIgniter (Part 3) – Helpers
3. Building Applications using CodeIgniter (Part 2) – Configuration

What belongs in a helper?

Something I’ve struggled with in the past is determining when a certain function or process belongs in a helper file and when it would be better off elsewhere. There is no cold hard rule for determining when something belongs in a helper and when it doesn’t but you do need to be aware of the following:

“Unlike most other systems in CodeIgniter, Helpers are not written in an Object Oriented format. They are simple, procedural functions. Each helper function performs one specific task, with no dependence on other functions.”
- CI Users Guide

This means that in order to access libraries and models within your helper functions you will need to get a CI instance:

$CI =& get_instance();

With the technicalities out of the way let’s take a look at the 2 helper files I’ve developed: display_helper.php and  flash_helper.php.

display_helper.php

A lot can be accomplished with CI’s built in templating but there are still some things that require logic and therefore fit nicely within a helper function. The display_helper.php file holds a number of common HTML display functions that I use throughout my program view files. To see what this file looks like, download an example. The functions in this file are pretty self-explanatory but I will briefly describe what each does below:

display_error()

The display_error() function displays a properly formatted HTML error message. I have this function setup so it can display 2 types of message: standard and form. When using the form_validation library I use the set_error_delimiter() method to wrap my error messages in list item tags and then display form error messages as unordered lists. So, I can easily accomplish displaying both types of messages using this function just by passing some variables.

display_msg()

This function just displays a properly formatted HTML message. This doesn’t necessarily need to be in a helper function because it’s so simple. But, the nice thing about having it here is if I ever decide to change the format of my messages I just need to come here in one place and make the update. So it consolidates my code nicely… but the same could probably be accomplished by using more generic CSS ID names.

req_field()

You should always identify required fields on your forms so users know what they need to fill in and what can be left blank. I’ve put the display of this flag in a helper function again to consolidate my code. As with the display_msg() function, if I ever decide to change my required field flag I just need to come to this one place and change it instead of going into all my view files and going a find and replace.

js_confirm()

JavaScript confirmation messages come in handy when you want to check with a user to make sure they are sure of something before you do it. You can accomplish the same confirmation by writing more PHP but that takes more work. The js_confirm() function, when used with the default CI URL helper anchor() function, displays a browser pop-up message with whatever text I pass to the function. If I’m in a hurry and don’t provide a message the function just returns a generic “Are you sure?” message.

Your display_helper file might look much different than mine, this is just an example of how I use it. But you want to be on the look out while your coding for repetition and little details here and there that might be changing down the road. If you can consolidate those things in a helper file you will end up saving a lot of time updating down the road.

flash_helper.php

CI added flashdata to it’s session library a few versions back and I for one was happy to see it. Flashdata allows you to pass messages for display between pages.  Simple status messages like “record added” or “record not found” can be placed in a flashdata variable and then displayed after the user is redirected to another page. A very handy tool for letting your users know the results of their actions.

While I do like this functionality, writing $this->session->set_flashdata(‘item’, ‘value’) and $this->session->flashdata(‘item’) every time I need to set or get something is a lot of typing. So the flash_helper is a pair of wrapper functions that handle the job of setting and displaying flash messages for me. To see what this file looks like, download an example.

display_flash()

The display_flash() function displays a selected flash message in a view file. Simply provide the name of the flash variable and it will display it in a properly formatted HTML div.

set_flash()

This function sets a flash variable with a value I specify. Since I use flash variables for a lot of different messages, which I may need to format differently, I also use this function to store some formatting data along with the message. That way when I display the message it is automatically displayed using the CSS style I intended.

The flash_helper file is based on the same concept that Michael Wales posted about a while back. I would link to the post but I can’t seem to find it anymore.

Last up: Code Templates

That wraps up the 3rd installment of this series. In the next, and final post, I’ll discuss creating code templates to help you maintain consistency between your files.

Related posts:

1. Building Applications using CodeIgniter (Part 2) – Configuration
2. Building Applications using CodeIgniter (Part 4) – Code Templates
3. Building Applications using CodeIgniter (Part 1) – File Structure

Config

All of CI’s configuration files are stored in application/config.

- config
— autoload.php
— config.php
— constants.php
— database.php
— doctypes.php
— hooks.php
— mimes.php
— routes.php
— smileys.php
— user_agents.php

The purpose of each file coincides with it’s name. To get us up and running we are only going to worry about autoload.php, config.php, database.php and routes.php.

config.php

The config.php file is the main configuration file for the framework. In this file you can control things like logging, character sets, extension prefixs, etc. The folks over at EllisLab have done a great job at commenting this file so I’m not going to go through the whole thing. The only thing I’m going to change here are lines 14 and 26.

Line 14 holds the full web path to your CI installation. In the past I used to type this in by hand until I had the need to write portable apps that could be distributed and installed without much configuration on the users end. Since then I have resorted to using this code I found on the CI wiki. By replacing line 14 with that code you can set this variable and forget about it. Wherever your program ends up this config variable will be set automatically so you don’t have to worry about it.

Line 26 of the config file holds the name of the index file. Since I use search engine friendly URLs where ever possible I just delete the value and leave it blank (just like the comment tells you to do).

autoload.php

Now that the config.php file is taken care of we turn our attention to the tools we need to build out app. What libraries, models, helpers, etc. are we going to need on a regular basis throughout the entire app? The answer to this question will probably differ based on what app your building, but I have found there are a number of common files I always load throughout any application:

Libraries – database, session

Helper – form, url, display, flash

Config – program

The libraries above, database and session, are the default CI libraries to handle database abstraction and user sessions (note, if your app doesn’t use a database consistently throughout the whole app you might not want to autoload this library). The form and url helpers are both default CI helpers but display and flash are two custom helper files I’ve developed to assist with some common tasks. I will discuss helpers in the next post. Finally, program is a custom config file that I create for all my applications which I will discuss shortly.

database.php

If you are app is interacting with a database then you need to update the database.php config file. This file stores the access information for the database or databases that your app will be interacting with. This file is pretty self-explanitory so I’m wont go to delve into it.

routes.php

The routes.php file allows you to define custom URLs and map them to specfic controllers and methods. This is a very powerful tool that comes built into the CI framework. The only thing we want to update in this file to get started is line 43. Right now it’s set for the default welcome message we saw before. I usually set this variable to home just because it’s pretty generic and tends to work well in URLs but you can set it to whatever makes sense to you and your app.

program.php

Now that I’ve discussed all the default CI files, I’m going to create a custom config file called program.php (the same one we auto-loaded above) and place it in the config folder. This file will store all the application wide configuration settings and information that I will be referring to both programmtically and manually. To see what this file looks like you can dowload an example for reference.

At the very least this file will always have 2 variables: ci_version and program_version. Both are pretty straight forward in purpose, ci_version stores the current version of CI that I’ve used to build the app and program_version is the current version of my app. I’ll typically call upon the program_version and display it in the footer of the app and knowing the version of CI running comes in handy when updating or making any framework modifications.

When building an app of any size you always want to build in a quick and easy way of taking the app offline. I accomplish this with the status variable. If the status is true then the program is online and everything is operational but if it’s false then things are offline. By creating a config variable for this I can easily refer to this flag throughout the program to determine whether or not input should be accepted and processed.

Another thing I commonly store in the program config file is e-mail settings that will be used whenever an e-mail is sent from the app. This commonly consists of the from and reply-to address and names. Again, by storing this information here it’s easily accessed whenever sending an e-mail.

Your program config file can store any type of system wide configuration information that your app will need to reference from many places. You could theoretically store this configuration information in a database but then you wouldn’t be able to take advantage of the native CI config tools available. In the end it’s up to you.

Next up: Helpers

That wraps up configuration. In the next post I will review some custom helper files I’ve developed and autoload in most of my applications.

Related posts:

1. Building Applications using CodeIgniter (Part 3) – Helpers
2. Building Applications using CodeIgniter (Part 1) – File Structure
3. Building Applications using CodeIgniter (Part 4) – Code Templates

When submitting sensitive information over the web it’s important to ensure that the requested page is being accessed via an HTTPS encrypted connection. I’ve come across some forms that don’t check whether a secure connection has been made or not. In other words, you can delete the S from HTTP and instead of redirecting the user back to the HTTPS connection the form is just displayed unsecured. This is a BIG NO NO… as a programmer you cannot rely on the visitor, or even other developers who would be linking to the form, to request a form securely. In this post I will review how you can ensure that your users are accessing certain pages using a secure connection.

The Server Superglobal

How can you tell if your user is requesting a certain page using a secure connection (HTTPS)? Enter the PHP server surperglobal.

“$_SERVER is an array containing information such as headers, paths, and script locations. The entries in this array are created by the web server.”
- PHP Manual (http://www.php.net)

There are 2 elements within this array that you can check that will tell you whether the user has made a secure request or not: https and server_port.

Programmer Beware

Something to keep in mind is that each web server will provide or not provide certain information in the $_SERVER array depending on their configuration. The PHP manual also points this out:

“There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here.”
- PHP Manual (http://www.php.net)

So I guess that brings us back to the original question: how can you tell if your user is requesting a certain page using a secure connection (HTTPS)? Of the 2 elements mentioned above, server_port is part of the CGI 1.1 specification so the chances are good that element will be available in most servers. You can check for the availability of the https element if you wish but you should also include a check of the server_port as a fallback.

The Code

There is a good code example in the comments of the PHP manual of a function that checks whether or not the user has made a secure request:

<?php
function isSSL(){

if($_SERVER['https'] == 1) /* Apache */ {
return TRUE;
} elseif ($_SERVER['https'] == 'on') /* IIS */ {
return TRUE;
} elseif ($_SERVER['SERVER_PORT'] == 443) /* others */ {
return TRUE;
} else {
return FALSE; /* just using http */
}

}
?>

This example function makes use of both the https and server_port elements of the superglobal array and also takes into account the different values that might be provided based on the web server. The only thing I will mention about using the server_port element is to make sure you know what port your server is using for HTTPS connections. I believe 443 is the standard, but ports can be changed so you just want to make sure you are checking the correct port for your server.

What about CodeIgniter (CI)?

If your programming using CI, you could certainly put the function above in a helper and call it whenever necessary. Or, a technique I’ve used successfully in the past, is to put the check in a custom library and auto load it. When you do it this way the connection is tested every time a page is loaded automatically without you having to make any additional function calls. And instead of returning TRUE or FALSE you can simply redirect the user to the requested page using HTTPS instead of HTTP which truly automates the process.

One thing that can trip you up when making secure connections using CI is the address you’ve entered on line 14 of application/config/config.php. If you enter just a static address starting with HTTP then HTTP will be used when calling any URL helper function like site_url() or anchor(). To avoid this issue,  you can replace line 14 with the following code from the CI wiki:

$config['base_url'] = ((isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == "on") ? "https" : "http");
$config['base_url'] .= "://".$_SERVER['HTTP_HOST'];
$config['base_url'] .= str_replace(basename($_SERVER['SCRIPT_NAME']),"",$_SERVER['SCRIPT_NAME']); 

This code will automatically set the base_url config element so you don’t have to. This also comes in real handy when writing portable code that you want to distribute to other users or clients for installation on their own servers.

That’s a wrap

That does it for making sure your files are being accessed securely. If you have any questions or use a different technique for checking secure connections please share them by posting a comment.

Related posts:

1. Customizing Domains With Wildcard DNS
2. Implementing Facebook Connect (Part 3) – Accessing Data from Facebook
3. Generating PDF files using CodeIgniter

In this first part of the series I’m going to talk about file structure. The first step to building your app is to get your folder and file structure setup so you have an idea where everything is going to go. If you wait to figure this out as you go along you run the risk of inconsistencies in your code so it’s good practice to just settle on a structure first thing.

CodeIgniter Default

By default, CI (version 1.7.1) presents you with the following structure:

- system
— application
—— application folders…
— cache
— codeigniter
— database
— fonts
— helpers
— language
— libraries
— logs
— plugins
— scaffolding

Everything lives inside the system folder. This isn’t necessarily a bad thing, but every time you want to get to your application to add or update files it’s just a hassle to go into system to get to your application. So, it’s pretty common practice to move your application folder outside of the system folder so it’s front and center in the document root (or whatever folder your developing in).

To accomplish this you will need to update the main index.php file outside of the system folder. Line 43 needs to change to “../application” instead of “application”. Once that update is done then CI shouldn’t be able to tell the difference.

Application Assets

It might be because I’m a neat freak or maybe it’s because of the brief exposure I had with Ruby on Rails (RoR) but I don’t like having my application root littered with folders for images and JavaScript files and such. I like a nice clean document root. So I create a folder at the root of my application called assets. Inside the assets folder I create 3 other directories for images, JavaScript and CSS files so it looks something like this:

- assets
— images
— js
— css

Now all of my non-php files are nicely organized in a single directory at the top of my application. From time to time I’ll also add a directory for videos but you get the idea.

Template Files

Another one of those common application tasks that CI handles, like I mentioned earlier, is templating. The views folder (inside application) makes up the V in MVC and that’s where all your design/display files should go. It’s taken me some time but I’ve settled on a pretty standard way I handle my application templating and it all revolves around a folder I create within views called _templates.

Instead of loading a bunch of view files one after another to make up my page, I prefer to create layout files which are complete web pages just with some variables acting as place folders for content to be inserted later. When it’s time to display a page I load a couple of partial views into variables (by returning the views as strings instead of displaying them) and then passing those variables to my master view file for display. The main benefit of this type of templating structure is that your whole application can use a just a hand full of layout files to handle page structure.

Within the _templates folder I create another folder called layouts. This is where the actual layout files live. Other include/template files are placed inside the _templates folder that are included in more than one layout file like navigation elements and such. I will also typically create other folders within _templates for things like system e-mails and the like.

Final Structure

That just about does it for our structure. I’ve listed the new structure below with just the new directories we should be left with and where they live.

- application
— views
—— _templates
——— layouts
- assets
— css
— images
— js
- system

At this point I typically move the files to the development environment and make sure the default CI welcome message is displayed. If your following along at home and don’t see the welcome screen you more than likely didn’t make the change to the index.php file I mentioned above when we moved the application folder outside system. Double check that and if all was done correctly you should be all set. If you continue to have problems, leave a comment and I’ll see what I can do to help.

Next up: Configuration

In part two of this series I’ll talk about configuring CI to load the common libraries we’ll need and creating a custom config file to keep information specific to our application.

Related posts:

1. Building Applications using CodeIgniter (Part 2) – Configuration
2. Building Applications using CodeIgniter (Part 4) – Code Templates
3. Building Applications using CodeIgniter (Part 3) – Helpers

Related posts:

1. JPG Magazine Says Goodbye
2. Building Applications using CodeIgniter (Part 4) – Code Templates

On another note, I know it’s been quiet here for the last month or so. I have been trying to get BadgeTracker 4.0 in shape for an early November release so I’ve been heads down coding. More soon…

Related posts:

1. Update