All posts by Steve

How to Run Cron Jobs in CodeIgniter

After a fair bit of trawling Google, I got the impression that setting up a cron job in codeigniter was going to be a bit tricky.

The two potential solutions I discovered were:

  1. execute the “wget” command to replicate a normal browser request, which then exposes my cron functionality to the big wide world and creates some additional unnecessary overheads, or
  2. Create a bespoke front controller a bit like the existing index.php but specifically for cron jobs

Neither of these options sound particularly ideal to me, and thankfully, there is a better way (and it turned out to be a case of RTFM).

Firstly, just create a normal controller. I creatively called mine Cron.

class Cron extends CI_Controller {

    function __construct()
    {
        parent::__construct();

        // this controller can only be called from the command line
        if (!$this->input->is_cli_request()) show_error('Direct access is not allowed');
    }

    function foo($bar = 'bar')
    {
        echo "foo = $bar";
    }
}

Note the call to $this->input->is_cli_request() which ensures that this controller cannot be accessed directly from a url.

Next we setup our cron job as you would any other, except that you provide the path in a special format.

php /path/to/index.php controller_name method_name ["params"]

The first part is either the command “php” or your server path to php.

The second part is the absolute path to your CI front controller, eg. /path/to/index.php.

The third part is the controller name, followed by the method name, followed by optional parameters.

The CI manual gives the example:

php /path/to/index.php cron foo

If that doesn’t work, it probably means you don’t have the package php5-cli installed. On debian / ubuntu you can install this package as follows:

sudo apt-get install php5-cli

If you are not able to install packages, you can specify your path to php. I set mine as follows:

/usr/local/bin/php -f /home/clinic/public_html/index.php cron foo

You can even pass parameters in quotes, which have the same effect as parameters in regular url requests!

/usr/local/bin/php -f /home/clinic/public_html/index.php cron foo “beer”

Automatically Submit Google CSE

This tutorial outlines two techniques to customise Google’s Custom Search Engine:

  1. Generating your own custom styled search form
  2. Fetching the search results on page load rather than the default which requires the Google provided search form to be submitted

This enables you to place your custom styled search form anywhere on your site (for example in a global site header), and when the form is submitted the search results are automatically loaded as soon as the user lands on the search page – as opposed to the default behavior which requires submission of the Google provided search box.

This is a sample global form that I use in my header file, which submits to the url “/search”. I will leave the CSS side to your imagination.

<form id="search" method="get" action="/search">
<fieldset>
<input type="text" name="q" value="" placeholder="Search Records" />
<button type="submit">Search</button>
</fieldset>
</form>

On my search page, the following code displays the Google CSE search box and pre-loads the results which are passed in from PHP’s $_GET. Don’t forget to replace myUniqueID with your Google CSE unique ID.

<!-- div container to display search results -->
<div id="cse" style="width: 100%;">Loading...</div>

<script src="http://www.google.com/jsapi" type="text/javascript"></script>
<script type="text/javascript">
  google.load('search', '1', {language : 'en'});
  google.setOnLoadCallback(function() {
    var customSearchControl = new google.search.CustomSearchControl('**myUniqueID**'); // change this to your unique ID
    customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET);
    customSearchControl.setLinkTarget(google.search.Search.LINK_TARGET_SELF); // open results in current window
    customSearchControl.draw('cse'); // set the results div id
    customSearchControl.execute("<?php if (isset($_GET['q'])) echo filter_var($_GET['q'], FILTER_SANITIZE_STRING); ?>"); // run the search using the value of $_GET['q']
}, true);
</script>

CodeIgniter Getting Started Surprises

I’ve been looking into the CodeIgniter PHP framework (CI)  for a couple of weeks and want to document some of the surprises and caveats I have discovered. Coming from a non-framework background, I was surprised at how similar the CI conventions are to my own pseudo “framework” that I use on my projects – so I guess I must’ve been doing something right so far!

This is what i’ve learnt.

CI is backwards compatible with PHP4

Which, in my opinion is something they should rectify – ie. retire support in the next major release and move forward. From what I have read about CI vs Kohana (a CI fork), it seems that CI is sacrificing pretty autoloading simply because they remain backwards compatible.

Edit: This is actually incorrect, as of version 2.0.2 the minimum required version of PHP is 5.1.6. Thats to Dale for pointing this out in the comments.

The MVC structure is superb, however…

Alot of tutorials i’ve watched lean towards using helper functions within views, such as for forms. From a developer perspective thats fine, however you can imagine a designer having problems with form_open() when he wants to add a simple class or ID. The upside is that they are just helpers – if you don’t like them, don’t use them.

Speaking of functions

I was surprised to discover the folder full of procedural helper functions. This is nice in terms of using functions anywhere inside the application, although it does seem a little out of place in an OOP framework. It would be nice to see these converted into classes.

Default session security is awful

Usually a PHP session’s data is stored server side and only a small cookie is kept client side to track a user session. However in CI, the session data is stored client side, which means that a simple alteration in firebug later and you potentially just gave yourself admin privileges or discovered some other potentially sensitive information. It should be noted that an encryption key can be used to protect session alterations, but having to add 3rd party classes to do conventional PHP session storage left me gob smacked.

Edit: Eric Barnes correctly pointed out that you can also securely store sessions in the database out of the box.

Using dashes instead of underscores in urls…

Is alot less trivial than you might think; In fact, i’m still trying to figure that one out.

CI is the logical introduction to frameworks

for the curious developer – the documentation is quite good and it has a strong community. The common view seems to be that some other frameworks (Zend, Symfony) are better for high end and complex application development, but CI has the easiest learning curve, and it does enough to satisfy most requirements.

Picking up CI (or in other words learning a PHP framework for the first time) is a bit like that feeling when you go from regular javascript to jQuery. You get blown away by how few lines of code it takes to achieve big things. It’s also great to get that feeling that all the crazy things about PHP are now wrapped up in a nice big blanket, and you basically don’t have to worry about them.

Having said that – learn PHP properly first, then learn a framework.