CodeIgniter Form Validation

Continually using the CodeIgniter MVC Framework has allowed me to experience many of it’s numerous “pros.” However, some times, I also hit a snag with one or more of it’s infrequent ”cons.”  Truthfully, it’s put together overwhelmingly well (and much credit is due to the Ellis Labs crew for helping to make a PHP developer’s life a little easier.) Unfortunately, some libraries just do not work the way one (okay, me!) would expect them to work. Perhaps they are just a bit too inflexible for me. For example, I’ve never been a huge fan of CodeIgniter’s Form Validation library, and now I have yet another reason to scorn it somewhat. Admittedly, I’m probably being a bit too severe on this one. However, I feel annoyed in situations where lack of proper documentation costs me precious time (I say this in light of CodeIgniter’s, otherwise, excellent documentation.) Luckily, my perceived notion of how CodeIgniter’s  Form Validation Library should work can be accomplished, once again, with the kind of simple modification that keeps me coming back to CodeIgniter time and again.

The problem

After using a 3rd party library for CAPTCHA’s today, I noticed that the rules in the included application/config/form_validation.php file (hereby referred to as the “config file”) were not running. My other rules that I had defined inline (inside the controller) were working, but it seemed to ignore the rules in the config file completely. When I looked into the the form validation core library, I noticed that when rules are set from within the config file, they are only evaluated if no rules were set inline (set via $this->form_validation->set_rules(…)…) In other words, you must set no rules inline if you want your config file rules to work. This behavior took me off guard a bit because I could not see it documented in the manual (if anyone feels the need to enlighten me, please do.) Also, it makes importing 3rd party code in this manner potentially confusing (I have never used the config file approach before.) I decided that it made more sense to be able to use both types of rules simultaneously. Thus, I wrote an extended version of the Form Validation library.

The Code

This extended version of the Form Validation library allows me to mix both inline and config rules. If inline rules by the same field name are set, these will override the settings in the config file:

application/libraries/MY_form_validation.php

<?php
/**
 * Extension class to override Core Form Validation behavior.
 *
 * @author bmillett
 */
class MY_Form_validation extends CI_Form_validation {
    // --------------------------------------------------------------------
 
    /**
     * Run the Validator
     *
     * This function does all the work.
     *
     * Modified by Brett Millett:
     *  Provided option to remove the config or inline only restriction on
     *  rules. This version will process config rules first and then any
     *  inline rules that exist after. This has the benefit of allowing
     *  inline rules to overwite config rules by the same key.
     *
     * @access	public
     * @return	bool
     */
    function run($group = '', $combine_conf_inline = FALSE) {
        if ($combine_conf_inline) {
            //only perform if we have both field and config rules.
            if (count($this->_field_data) > 0 && count($this->_config_rules) > 0) {
                // Is there a validation rule for the particular URI being accessed?
                $uri = ($group == '') ? trim($this->CI->uri->ruri_string(), '/') : $group;
 
                if ($uri != '' AND isset($this->_config_rules[$uri])) {
                    $config_rules = $this->_config_rules[$uri];
                } else {
                    $config_rules = $this->_config_rules;
                }
 
                // only set the rule if it has not already been set inline.
                foreach ($config_rules as $row) {
                    if (!isset($this->_field_data[$row['field']]))
                        $this->set_rules($row['field'], $row['label'], $row['rules']);
                }
            }
        }
        //run parent version last, so field rules will  override config ones and update
        return parent::run($group);
    }
}
?>

Examples

application/config/form_validation.php

<?php
 
if (!defined('BASEPATH'))
    exit('No direct script access allowed');
 
$config = array(
    'mycontroller/index' => array(
        array(
            'field' => 'recaptcha_response_field',
            'label' => 'lang:recaptcha_field_name',
            'rules' => 'required|callback__check_captcha'
        )
    )
);

To use both combined, just call run() with an optional 2nd parameter:

application/controllers/mycontroller.php

class Mycontroller extends Controller{
	function index() {
            $this->load->library('form_validation');
            $this->load->library('recaptcha');
 
            $this->lang->load('recaptcha');
            $data = array();
 
            //get recaptcha html
            $data['recaptcha_html'] = $this->recaptcha->get_html();
 
            $this->form_validation->set_rules('name', 'Your Name', 'trim|required');
 
            // call with new optional 2nd param to combine inline and config file rules.
            if ($this->form_validation->run('', TRUE) === FALSE) {
                $this->load->view('captcha_form', $data);
            } else {
                $this->load->view('captcha_form_success', $data);
            }
        }
}

Ever wonder why you can’t use query strings with CodeIgniter? This post will explain to some degree, but more importantly, show you how to parse query strings and how to get the GET back in CodeIgniter!

I’ve been using CodeIgniter for a couple years now. It’s small, it’s simple, it’s powerful. Admittedly, it’s not perfect (what framework is?) but it’s a wonderful way to slap together a website using MVC design principles and PHP. I do have one big complaint, however.

The Hated $_GET global

The CodeIgniter developers have some strange obsession with killing all GET data. It appears, from the manual at least, that they strongly discourage you from using query strings. For example, the following manual entry states:

By default, URLs in CodeIgniter are designed to be search-engine and human friendly. Rather than using the standard “query string” approach to URLs that is synonymous with dynamic systems, CodeIgniter uses a segment-based approach:

You’ll notice that I have highlighted the words, “By default,…” because you can, in fact, turn on query strings in CodeIgniter, however there is an important trade-off to note (besides saying goodbye to those pretty URL’s:)

Please note: If you are using query strings you will have to build your own URLs, rather than utilizing the URL helpers (and other helpers that generate URLs, like some of the form helpers) as these are designed to work with segment based URLs.

Okay, admittedly, it’s not a big deal to build your own URL’s. I mean we used to do that all the time, right? However, what if you have used the “default method” of the segment-based approach and suddenly you need to pass GET values to your CodeIgniter application? Let’s also say that you’ve used many of those helpful URL functions, etc. Now, for the cost of enabling query strings, in the manner indicated by the manual, for that one page, you’ve got plenty of re-factoring to do! Not cool.

I know this sounds like a fantasy scenario, but it’s real. It happened to me. On two different occasions, working with two different payment gateway API’s, I suddenly had to provide postback URL’s. In both instances, the postback URL’s that were directed to my website, attached query-string variables to the URL in order to provide the relevant data (receipt number, etc.) Obviously, this is something I had no control over because I had to adhere to the API convention and they didn’t offer alternatives for “segment-based” Web frameworks! I realize that I could have used a standalone script to handle these requests, but that could be potentially confusing for future developers (including myself after a few months) because the standalone script would reside outside of the framework. Also, I have based the entire application on the framework. The framework keeps my code organized in a way. I don’t want to have to use scripts that do not adhere to my conventions. I want to use the framework for all my code! More importantly, what about my models, libraries, helpers, etc? The framework shouldn’t force you to make the decision not to use it. It should, at least, provide a way to use a long-establish standard without compromising one of the best benefits of the framework.

I can understand disabling the $_GET super global (and query-string usage) by default when the whole framework is geared towards segment-based URL’s. What I can’t understand is why they make it so hard to enable query strings for situations when you might actually need them. There is no simple configuration Boolean variable you can flip on and off!

So, why can’t we just specify a controller/method URI and tack on a query string? Admittedly, this gets a little complex to depend on with mod_rewrite and other factors outside of the control of the CodeIgniter developers. However, no attempt has been made to allow for the possibility. For an explanation, let’s go back to the manual:

The security filtering function is called automatically when a new controller is invoked. It does the following:

• Destroys the global GET array. Since CodeIgniter does not utilize GET strings, there is no reason to allow it.
• Destroys all global variables in the event register_globals is turned on.

Okay, clearly there is a reason to allow it! I think we can tally up the real reasons behind destroying query string data to a matter of programmer laziness! I know that sounds harsh, but the manual clearly states (to paraphrase,) “Let’s not bother with storing GET data anywhere in the CodeIgniter super object because we don’t use it anyway. Phew, don’t have to worry about that anymore!”

Let’s put it back! Methods for enabling $_GET in CodeIgniter

Luckily, there are a few ways we can use GET variables without having to give up the segment-based approach (and all those nice URL functions!)

Method 1: Extend The Input Class

If you want to enable codeigniter to get query string variables globally, you can do it with a few easy steps:

1. Create a MY_Input class in application/libraries
2. Update your application/config/config.php file: Change $config['uri_protocol'] to “PATH_INFO”
3. If you are using mod_rewrite to hide index.php, make sure you have a slash in your rule after index.php: RewriteRule ^(.*)$ index.php/$1 [L]

application/libraries/MY_Input.php

<?php
class MY_Input extends CI_input {
 
    function _sanitize_globals()
    {
        // setting allow_get_array to true is
	// the only real modification
        $this->allow_get_array = TRUE;
 
        parent::_sanitize_globals();
    }
 
}
/* End of file MY_Input.php */
/* Location: .application/libraries/MY_Input.php

Conclusion

I had to do some “tinkering” to get this method to work; but in the end, it’s a fairly simple hack that requires minimal changes.

Our next method requires no configuration changes nor extended libraries whatsoever.

Method 2: Use parse_str to Grab GET data out of REQUEST_URI

This method should, perhaps, be subtitled, “The Quick and Dirty Method” as it’s extremely easy to implement: one line of code.

Despite what the manual states, CodeIgniter fails to destroy all global variables. For example, $_SERVER['REQUEST_URI'] shows what was given from the browser as the URL path. (Example: /controller/method?foo=bar.)

Having this data, we can use PHP’s parse_str function to parse $_SERVER['REQUEST_URI'] and rebuild the $_GET array. We also have to utilize substr to strip away the /controller/method part. Otherwise, we’ll end up with a $_GET key similar to “/controller/method?foo” when we just want our associative array key to be “foo.” It’s important to note that we can still use the fabulous Input class to filter our query-string data (it’s just not quite as pretty) against cross-site-scripting attacks.

Use parse_str to rebuild $_GET

<?php
//Remove everything before (and including)
//the question mark and then parse into $_GET array.
parse_str(substr(strrchr($_SERVER['REQUEST_URI'], "?"), 1), $_GET);
echo ' Using rebuilt $_GET array with xss protection: ' .
	$this->input->xss_clean($_GET['foo']);

My preference because it’s a “genuine hack”

I should note that this is the method I used for my payment gateway postbacks. In my particular situation, this was the best fit because I needed query-string variables for a single URL in the entire site. I really didn’t want to have to extend CodeIgniter or change my Apache settings for one URL (I’m fine with segment-based URL’s as long as they’re in my control.) I just put this one line of code in my controller method where it was needed.

If you don’t want the bother of dropping this code into each one of your controller methods, you can easily incorporate this into a helper function and make a simple function call any time you need $_GET. If you want to enable rebuilding $_GET globally, you can also take advantage of setting this code up in a pre_controller hook.

The best part of this method is that it works with CodeIgniter out-of-the-box. No configuration changes or extended libraries should be necessary. Always a “plus” in my book.

So, you finished that CodeIgniter Website last month. It was a tedious project and you’re glad it’s over! But wait! Now, your client informs you that you’re missing all the tracking code! The client also mentions he wants to use the popular, free Analytics tools from Google. This is gonna require inserting some javascript into all of your Web pages. Not a problem if you used a global footer in your views. A potentially huge pain otherwise. Either way, if you’re looking for a very simple way to globally implement Analytics code in your application, CodeIgniter hooks can make your life much easier. I’m going to show you how to take advantage of the ‘display_override’ hook point in CodeIgniter to get the job done fast!

To pull this off, you’ll need to slightly modify two configuration files (config.php and hooks.php) and then create another with a “hook” function (google_analytics.php.)

First, create a file named google_analytics.php and place it inside your application/hooks folder. We’ll reference this file later when we do our hooks configuration from within application/config/hooks.php.

google_analytics.php

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
 
if ( !function_exists('insert_ga_script') ) {
    function insert_ga_script($account_id) {
        /***NOTE: This hook replaces the _display
        * method in the Output Class. I have
        * not made provisions for caching nor compression!
        */
 
        $CI =& get_instance();
        $output = $CI->output->get_output();
 
        //keep performance templates in...
        $elapsed = $CI->benchmark->elapsed_time('total_execution_time_start', 'total_execution_time_end');
        $output = str_replace('{elapsed_time}', $elapsed, $output);
 
        $memory	 = ( ! function_exists('memory_get_usage')) ? '0' : round(memory_get_usage()/1024/1024, 2).'MB';
        $output = str_replace('{memory_usage}', $memory, $output);
 
        // keep profiler working
        if ($CI->output->enable_profiler == TRUE) {
            $CI->load->library('profiler');
            // If the output data contains closing </body> and </html> tags
            // we will remove them and add them back after we insert the profile data
            if (preg_match("|</body>.*?</html>|is", $output)){
                $output  = preg_replace("|</body>.*?</html>|is", '', $output);
                $output .= $CI->profiler->run();
                $output .= '</body></html>';
            } else  {
                $output .= $CI->profiler->run();
            }
        }
 
        // if no account information just return the output
        if ( empty ($account_id) ) {
            // keep _output methods working...
            if (method_exists($CI, '_output')) {
                $CI->_output($output);
            } else {
                echo $output;  // Send it to the browser!
            }
            return ;
        }
        ob_start();
        ?>
    <!--Begin Google Analytics Site Code-->
    <script type="text/javascript">
    var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
    document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
    </script>
    <script type="text/javascript">
    try {
      var pageTracker = _gat._getTracker("<?=$account_id?>");
      pageTracker._initData();
      pageTracker._trackPageview();
    } catch(err) {}
    </script>
    <!--End Google Analytics Site Code-->
        <?php
        $script = ob_get_clean();
        //insert the script
        $output = str_replace('</html>', $script . "\n</html>", $output);
 
        // keep _output methods working...
        if (method_exists($CI, '_output')) {
            $CI->_output($output);
        } else {
            echo $output;  // Send it to the browser!
        }
    }
}
?>

The function above slips Analytics javsacript code into the CodeIgniter output buffer. It finds the closing html tag in CodeIgniter’s output and replaces it with our script. It then puts the closing html tag back into the output string. Simple and effective; because your views generally output html, and this method will only insert Analytics code if a closing html tag is found (your rss feeds, etc. are safe.)

Now, how do we intercept CodeIgniter’s output before rendering it to the browser? This is where hooks come into play. CodeIgniter hooks provide a way to extend the framework without messing with the CodeIgniter core code (which has many advantages I won’t go into during this post.) CodeIgniter defines “hook points” to allow you to specify where you want to throw your “monkey wrench.” Our “gilded wrench” is going to be thrown into CodeIgniter’s display or output proccess.

To demonstrate, let’s edit our application/config/hooks.php file. We leave ‘class’ empty because we only need a function (in case you wondered.) We specify ‘googlea.php’ under ‘filename.’ We specify our ‘function’ (in our case ‘insert_track_js.’) Finally, we have one parameter to send to our function: the value of the google analytics account number (yours will vary of course.) We hook into the ‘display_override’ hook point to override CodeIgniter’s default output (display) process. When you are done, your application/config/hooks.php should look similar to:

hooks.php

<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');
/*
| -------------------------------------------------------------------------
| Hooks
| -------------------------------------------------------------------------
| This file lets you define "hooks" to extend CI without hacking the core
| files.  Please see the user guide for info:
|
|	http://codeigniter.com/user_guide/general/hooks.html
|
*/
 
// google analytics insertion
$hook['display_override'] = array(
    'class'    => '',
    'function' => 'insert_ga_script',
    'filename' => 'google_analytics.php',
    'filepath' => 'hooks',
    'params'   => 'UA-*******-**'
);
 
/* End of file hooks.php */
/* Location: ./system/application/config/hooks.php */

Finally, we just need to enable hooks in application/config/config.php. Look for the ‘enable_hooks’ line:

Source code

$config['enable_hooks'] = TRUE;

Set the value to TRUE as shown above. You’re done!

For more information on hooks, see the CodeIgniter Manual or this recent tutorial from Net Tuts.

After nearly two months of using OS X, I think I have finally found my groove when it comes to doing my job. That is, writing code for websites, mainly in PHP.

For many years prior to using a Mac for PHP development, I had been using Windows or Linux and Zend Studio 5.x. When I was looking several months back for the Mac version download for my Zend Studio license, I was presented, instead, with a free upgrade to version 6. Wow, that was nice Zend! Unfortunately, the version I paid for (the “perpetual” license) was no longer there to download.

UPDATE: As of my last login to Zend, the 5.5.1 download was available. I installed and everything worked well. Still using Netbeans but appreciated all the same.

But hey! I got the brand-new version. That’s great right? Wrong! Zend decided to drink the Eclipse Kool Aid and completely changed an IDE that I had grown accustomed to (I guess it’s only fair to point out that Zend Studio 5.x was so old at this point that it was getting increasingly more difficult to install on more modern operating systems and newer java platforms.) In spite of the seemingly “over-bloat” of Zend Studio 6.0, I decided to give it a try. I must say that everything just felt wrong. Now I’m sure there are many PHP developers out there that have been using Eclipse for years and can’t live without it, but I just couldn’t seem to make it work my voodoo. I didn’t have the patience to get my Eclipse PHD, so I went looking elsewhere. That led me to a surprising alternative: Netbeans. Although very similar to Eclipse, an IDE with modules/plug-ins for multiple computer language support, Netbeans (entirely free) impressed me right on the spot. I know Zend Studio has all the same features more or less, but the way Netbeans is put together just seemed more natural to me (things I wanted to do actually worked.) Let it suffice to say that I have been using Netbeans since then and I haven’t looked back!

In this post, we will discover how to go about debugging a specific page in your website through setting up debugging in your MAMP stack, the free Netbeans IDE and your Firefox browser.

Setting up Debugging with Xdebug and Firefox

In order to leverage the new-found versatility or MAMP, I needed a good debugger. I had had a pretty decent debugger with Zend Studio 5.x and that would be an essential requirement for netbeans. One of the cool features of Zend Studio was the integration of the Zend Toolbar with the debugger. Fortunately, this can be done with netbeans also, but you have to get a firefox plugin called Xdebug Helper easy Xdebug. When you get it, note that it has one configuration option you need to set: Xdebug.idekey needs to be set to netbeans-xdebug.

Since I was using MAMP, I needed to install the xdebug extension for PHP. I actually downloaded the source and built the extension (used Xcode tools to phpize the source and build it and then just copied it to the appropriate MAMP folder.) I wish I had taken the time to record the steps involved, but instead I’ll just refer you to the easy way. Now we just need a little change in our php.ini file and we are good to go:

Note: As of MAMP version 1.8.4, there is an xdebug extension that comes with MAMP (just be sure to disable Zend Optimizer since they don’t seem to play well together.)

; Xdebug config for Mac OS X and NetBeans IDE
zend_extension=/Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000

Xdebug in php.ini

Now, all we have to do in order to debug is evoke the debugger in netbeans. I do this by clicking on the debug project button in the netbeans toolbar:

netbeans debug button

Netbeans will open up your development website according to the URL you submitted when creating the project (make sure firefox is your default browser and that you have set the default page in your project.)

Tip! You can also force Netbeans to not open your browser when you debug:

In your project properties (right click on the project -> properties), click on Run Configuration, look for the “Advanced…” button and set “Do Not Open Web Browser“. Click OK.

A big thanks to Leonard Teo for this tip.

Often, just clicking the button will automatically activate the Xdebug Helper addon for me. But if you want to make sure that netbeans debugs the URL in your browser, be sure the click the X in your firefox footer bar so that it changes color from gray to green.

Xdebug Helper Toogle Icon

Netbeans will open your startup page to something like:

index.php?XDEBUG_SESSION_START=netbeans-xdebug

If you are using a PHP framework like Codeigniter, the URL can be a little annoying at first. I have found that I only need to press the continue button to let the start page run it’s path and then just close that tab. From that point I just leave the debugger running and toggle the Xdebug Helper “X” icon when I need to debug any page that I am working on. Couldn’t be easier!

Screencast Tutorials

The following screencasts cover making XDebug and Netbeans work together. It’s a recap of the text here with some added instruction on setting up an Apache virtual host for development from your computer. Please note, I do not have the ability to be concise when I speak and you may lose patience. My apologies up front. (If you want a condensed version, just watch Part 2 and than skip to Part 6. You might want to watch Part 5 if 6 leaves you scratching your head.) Also, as many people find when they listen to themselves recorded, I find that my voice and accent sounds kind of strange and annoying. That’s one part me and another part Southern Utah accent. Bear with me if you can.

Part 1: Prerequites for Xdebug and PHP on a Mac

Part 2: Setting up XDebug Helper

Part 3: Setting up an virtualhost apache environment in MAMP for codeigniter

Part 4: Starting to use XDebug in Netbeans

Part 5: Debugging with Netbeans and XDebug

Part 6: Wrapping up by showing a few features of debugging with xdebug in Netbeans