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

When I was developing my first web app (version 1 of BadgeTracker) I really wanted to implement this feature, but for the life of me I couldn’t figure out how to do it. I didn’t even really know what it was called so I had a hell of a time searching for information. I then built Sign-Up-Sheet.com and still had no idea how to accomplish the effect, but I really needed to because each sign-up-sheet needed to have it’s own address and a dynamic address would have been perfect. I don’t really recall how I finally figured out what I was looking for, but the answer to my prayers was Wildcard DNS. In this post I will walk you through implementing Wildcard DNS with your next web app.

Disclaimer

Before I get started I just wanted to mention that I do not claim to be a networking person. I don’t enjoy networking or server administration or anything like that… I’m software not hardware . However, this was a topic that I personally struggled with when starting out and I wanted to pass along what I have found and done.

What is wildcard DNS?

Wildcard DNS is typically defined as: an address record you can place in the DNS for your domain that will send all subdomains (not otherwise declared in your DNS) to a specified IP address. The concept is simple once you figure it out. Adding a Wildcard DNS record to your existing host records looks something like this:

*.christophermonnat.com A 10.5.128.1

The astrisk in this case is the wildcard character. This A record directs all subdomain requests to the IP 10.5.128.1. So now all you have to do is place you web app at the same IP address and you will be well on your way.

Do I need a dedicated IP?

It depends on how your app works. With Sign-Up-Sheet I have one CodeIgniter installation running 2 parts of the site. There is the website/admin area where users can browse the features of the program or sign-in to administer their account. And there is the actual public sign-up-sheet’s themselves which need to be displayed when a user enters the specified sheets address into the browser window. Because my app has 2 parts but is using the same CI installation I decided to use a shared IP for Sign-Up-Sheet.

With BadgeTracker there is only one CI installation but it has nothing to do with the website. The website and application are 2 physically separate things so the easiest way to facilitate this architecture was to get a dedicated IP for the application and leave the website with a shared IP. All subdomains go to the dedicated IP while the WWW record points to the shared.

When asking yourself this question I guess the determining factor boils down to how many parts there are to your app and whether they all belong to a single CI installation or many separate ones.

Wildcard DNS and CI

As I mentioned above, with Sign-Up-Sheet I have one CI install that handles both the display of sign-up-sheets decided by the URL and the front-end website/admin area. Since I’m using a shared IP I chose to have CI handle the determination of what to display to the user and when.

When doing something like this, there are 2 files you need to be concerned with: config/config.php and config/routes.php. In config.php, the issue is the base_url variable. This needs to be set to the home of your app in order for CI to operate properly. The problem with our implementation however is that it may change depending on what the user is requesting. Sometimes it will be a subdomain and other times it will be straight WWW. One way to account for this is to generate the base_url setting dynamically.

[code]
$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']);
[/code]

The above example is from the CI Wiki. By placing this code in your config.php file, the base_url will be dynamically generated based on what is being requested thereby solving that problem. The other file we need to be concerned with is routes.php. The issue here is that we want to serve the user with a different default controller if they are visiting the site using a subdomain vs. just WWW. We can accomplish this with the following code:

[code]
if(preg_match("/^([a-zA-Z0-9\-_]+)\.([a-zA-Z0-9\-_]+)\.([a-zA-Z]{2,5})$/",$_SERVER["SERVER_NAME"],$matches))
{
list($subdomain,$domain,$tld) = $matches;
}

if($domain == 'www'):
$route['default_controller'] = "main";
else:
$route['default_controller'] = "signup";
endif;
[/code]

The above code looks at the URL and gets just the subdomain portion. We then look at the subdomain and determine if its WWW or something else. From there we decide which default controller to set for the application. Once placed in your routes.php file this accomplishes our goal nicely. Now that we are pointing our users to the correct controller we can refer to our database to find the records associated with the requested subdomain and proceed from there.

Conclusion

Wildcard DNS is available with most popular DNS providers like Enom, Inc. and GoDaddy and is also available with popular control panels like Plesk. If your not sure if your provider offers Wildcard DNS you should ask because there are some out there that don’t. Something I did want to mention about using Wildcard DNS is that it’s not necessarily the answer to all of your problems and should be implemented after careful consideration. The makers of Wufoo, a popular app that makes hosted web forms, wrote a post a while ago about the issues they experienced while working with this kind of setup. It’s a must read before adopting this concept for your own apps.

Well, there you have it Wildcard DNS demystified. If you have any questions or if you are a networking/DNS genius and you see something I have gotten terribly wrong please post a comment and let me know.

Related posts:

1. How-to Ensure a Secure Connection Using PHP

SPAM… a nasty little four letter word. Could mean tasty meat in a can or could mean junk e-mails and form submissions clogging your server and taking up space in your inbox. We are all familiar with it and are engaged in a constant battle to stop it. In this tutorial I’m going to show you how to implement a popular 3rd party CAPTCHA service with your CodeIgniter application.

The commonly accepted approach of handling form SPAM is by using a CAPTCHA control on your forms. The good news is that CodeIgniter comes with it’s own built in CAPTCHA functionality included in the form of a plug-in. I’ve used their plug-in before and it works well. It takes a little bit to get it setup and working properly and requires it’s own database table but it gets the job done.

There is, however, another CAPTCHA tool which I have been using a lot lately called reCAPTCHA and I like it better. reCAPTCHA is a free hosted CAPTCHA service provided by Carnegie Mellon University and serving over 60 million CAPTCHAs a day. This service allows you to integrate a CAPTCHA control on your site quickly and easily without any database modifications or a lot of coding. Below are step-by-step instructions for integrating reCAPTCHA in your CI app.

Step 1 – Create a reCAPTCHA account

Before you can start working with reCAPTCHA you will first need to visit their website and create an account. Once you have filled out the form you will be logged in and prompted to enter your first site. Each site you wish to protect with reCAPTCHA needs to be entered in your account. This is because each site will get it’s own unique private and public keys which you will need to interact with the reCAPTCHA API. So, enter your domain name and click Create Key.

Once you have entered your domain you will now be presented with your public and private key. Take a minute to copy and paste those two long strings into a text document for later use. Be sure to keep track of which is which or else things won’t work properly.

Step 2 – Download the reCAPTCHA PHP library

Now that you have your keys, you will want to download the PHP library they provide for interacting with the reCAPTCHA API. The archive you download will contain two example files and a code file called recaptchalib.php. Once you have the archive, unzip it and move the recaptchalib.php file into your applications helpers folder.

Why a helper and not a library?

We could certainly turn what they provided us into a library, but that would involve changing some of the code they provided since they are not providing a class. The recaptchalib.php contains a number of functions which are meant to help while interacting with the API. Therefore, it fits the helper definition nicely.

Step 3 – Use the library in your project

Now that we have the code we can use it in our application. The first thing we need to do is display the CAPTCHA control on the form your trying to protect. So, first load the helper:

$this->load->helper('recaptchalib');

Now that we have access to the helper functions, we can use the recaptcha_get_html() function.

<?php echo recaptcha_get_html($public_key); ?>

You will want to place this function in your view where you want to display the form control. This function takes only one argument: the public key you received earlier when you added your site to your reCAPTCHA account. You can either add both the public and private keys as class variables to your current controller. Or, my preference is to add the public and private keys to a custom config file that I autoload throughout my entire app. That way I can use the control anyplace in my site without duplicating my keys.

Now that we have the control displaying on our form we need to add code to handle the validation.

<?php

// Validate the captcha submission.
function val_recaptcha($string)
{
	$resp = recaptcha_check_answer($this->config->item('recap_private'),
									$_SERVER["REMOTE_ADDR"],
									$this->input->post("recaptcha_challenge_field"),
									$this->input->post("recaptcha_response_field"));

	if(!$resp->is_valid) {
		$this->validation->set_message('val_recaptcha','Your answer for the security question was incorrect, please try again.');
		return FALSE;
	}
	else {
		return TRUE;
	}
}

function process_form()
{
	$this->load->library('validation');
	$this->load->helper('recaptcha_helper');

	$this->validation->set_error_delimiters('<li>', '</li>');

	// Validation rules.
	$rules['recaptcha_challenge_field'] = 'required|callback_val_recaptcha';
	$this->validation->set_rules($rules);

	// Validation field names (for display in error messages).
	$fields['recaptcha_challenge_field'] = 'Security Question';
	$this->validation->set_fields($fields);

	if($this->validation->run() == FALSE) {
		// display errors
	}
	else {
		// process submission
	}
}

?>

In the above code we are using CI’s built in validation library to validate the CAPTCHA. You can of course add any additional rules or fields that are needed. I’ve created a custom validation function called val_recaptcha() which is called via a callback within the validation rules on the recaptcha_challenge_field field (which is created when we used the recaptcha_get_html() function above). This validation function uses the recaptcha_check_answer() function from the reCAPTCHA helper to check whether what the user submitted is correct or not.

And that’s really all there is to it. You are now using the same CAPTCHA protection as Facebook and many other sites throughout the web.

Wait… it’s RED! Can I make it look better?

Absolutely, the reCAPTCHA website has detailed instructions for how to alter the look and feel of the reCAPTCHA form control. There are a number of pre-set themes which you can choose from or you can create your own.

Related posts:

1. Generating PDF files using CodeIgniter
2. How-to Ensure a Secure Connection Using PHP
3. Building Applications using CodeIgniter (Part 3) – Helpers