All posts by Steve

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.

Google-O-Meter tutorial with examples

Sentence Severity

You are sentenced to Life (doh!)... in Australia (woohoo!)

I came across the Google-o-meter widget in the Google Charts API today, and had a perfect use for it in my current pet project, convict records.

For the uninitiated, the Google Charts API allows you to request an image with query string parameters and format it in various different ways to produce a pretty graph.

I wanted to display the severity of a convict’s sentence, relative to the known minimum and maximum sentence terms of other convicts I had in my database.

It took a little wrangling before I discovered that I really only needed a few parameters to achieve what I wanted – the final request HTML looked like this:

<img src="http://chart.apis.google.com/chart?chs=240x100&amp;cht=gm&amp;chco=555555,FAFA05|FF0000&amp;chd=t:<?php echo $sentency_severity; ?>" width="240" height="100" alt="Sentence Severity" />

Lets break that down a little.

Range and Indicator Position

The Google-o-meter defaults to a range of 0-100, therefore the easiest way to position your indicator is if you can create a percentage value from 0-100. It does also support custom ranges but that is beyond the scope of this tutorial.

How do we determine the position of the indicator (in PHP)?

// determine the sentence severity
$sentency_severity = round(($term / $max_sentence) * 100);

The sentence severity is the sum of the sentence term in question, divided my the maximum known sentence (in my case 47 years, multiplied by 100, and finally rounded for good measure. This gives a percentage result somewhere between 0-100%. 23 years = 50%, 47 years = 100% and so on.

Other Parameters

Now that the sentence severity is known, all that is left to do is to pass the parameters to the Google Charts API.

  • chs=240×100
    The dimensions of the image length x height. *important* if you change the height value here, make sure you also change the <img> width and height attributes
  • cht=gm
    The chart type – gm = google-o-meter
  • chco=555555,FAFA05|FF0000
    The indicator hexadecimal colour followed by the start colour and end colour (the gradient in between is almost certainly created by some sort of voodoo magic)
  • chd=t:<?php echo $sentency_severity; ?>
    The chart data, in this case the indicator position.

The documentation is quite extensive on both the Google-o-meter and the Chart Wizard can also be helpful, although I did find that the wizard was a bit confusing for the google-o-meter in particular, and it ended up adding more parameters than I really needed in the end.