In the past 6 months, I’ve been using Drupal quite a bit and have made the decision to migrate my site from WordPress to Drupal. I’m more familiar with Drupal 6.x than Drupal 7.x right now, but I can easily change that. The decision to migrate really came to a head when I made my last post about the statepicker module and realized I have no ability to show off this module on my own site. Not only is this site running software that isn’t Drupal, but WordPress is a platform that I don’t foresee myself spending much time in its development community.

My time with Drupal has really changed my opinion of it from ‘meh’ to semi-awestruck. The main point that I keep thinking about is that I have yet needed to hack in any changes to Drupal. Every module I’ve written and every customization I’ve done has been neatly tucked into the sites folder, where custom content is intended to be handled. Unlike the other platforms I’ve used (mostly Kohana and WordPress), I have not needed to go edit things I shouldn’t be editing to reach my desired result.

I’ll be doing the migration over the next month or so. As of right now, I just have a blank Drupal 7.7 install floating in a git repository. I have a lot of work before it’s suitable to replace this WordPress build.

I’ve spent the past few months working heavily with Drupal, rebuilding my company’s primary site on it. While doing this, I came to an interesting issue that involved creating a module that I think the Drupal community at large could use – a new form item type for choose a state, with a full country list as well. To solve this issue, I created the statepicker module, which is currently hosted on Drupal.org as a sandbox project, but I hope to have it upgraded to full project status shortly.

Statepicker creates a new field type, called ‘statepicker’, that creates a pair of dropdown menus in the form – a state dropdown and a country dropdown. When the country dropdown is changed, an AJAX call refreshes the state list to show the states from the current country. I’ve also created an administration panel that lets an admin edit the state list.

You can download the module from the Drupal.org site, currently only through the repository viewer.

http://drupal.org/sandbox/visual77/1258930

In a quick followup to yesterday’s building and releasing autoasset, I’ve created another module to do something simple and portable for Kohana 2.x. This module, kotidy, uses the PHP Tidy library to clean up the HTML output immediately prior to display. Even though the HTML is not seen by the end user, I find myself OCD about this kind of stuff and want to know that my source code is clean, even if most people will never see it.

Just like autoasset, kotidy uses the Event system to hook a basic function in place to use the tidy library to clean up the output. Other than adding this module to your module list in the main config file, no work is required on your part, unless you want to customize the config data being sent to Tidy::parseString(), of course.

Download Kohana 2.x – kotidy

I’ve set up about a half dozen Kohana 2.x sites now, and one problem that I constantly run into is including javascript / css based on the controller and method for the current page. For instance, if you go to “/user/view/1″ on a Kohana site, I would like to automatically include “/javascript/user.js” or “/javascript/user/view.js”, if the files exist.

To solve this problem, I created an autoasset module for Kohana 2.x. It will not work on Kohana 3.x due to the removal of events and hooks. To use autoasset, simply load it like you would any other module, and then go into the config file and specify which kinds of assets to load. Just input the directory that these assets are stored in, the file extension, and a callback to use when rendering. I put in example entries for javascript and css as a demonstration. You can then render the autoloaded assets by calling autoasset::render(); where you want to include the assets, such as the html head tag.

On a similar note, modules like this are one of the main reasons why I am launching ko23.net. I think Kohana 2.x is a fantastic framework, and if a large community arose to provide modules that are just generally useful, then Kohana 2.x could really shine.

Download Kohana 2.x Autoasset

I’ve been a Kohana user for about a year now, and every major update pleases me less than the last. I’m considering starting a community dedicated to Kohana 2.3, built around maintaining documentation (since the official site already pulled the Doxygen docs, how long until they pull the documentation wiki?), creating new modules and generally working on preserving the Kohana 2.3 legacy. Would anyone be interested in being a part of this community?

I’d like to stress that I am in no way trying to insult the developers and maintainers of Kohana through this project. Their work has been absolutely amazing, but just as they forked from CodeIgnitor when they felt it was no longer serving their needs as developers, so now am I feeling that Kohana no longer serves my needs as a developer.

I’m setting the project up at ko23.net. I’ll begin adding some functionality such as forums and module hosting / rating.

This iterative build was to test the economy calculator at different time intervals. I created an array to store information on 5 basic protoss units – Nexus, Pylon, Gateway, Probe and Zealot. I then wrote some quick calculators to accept a time, in seconds, and return the amount of minerals available at that time. The display is fairly minimal, just showing economy, but various units and builds were constructed at certain times.

The calculation is based on finding out how many probes exist at this time, how long they have existed, and multiplying that by 5/6. 5/6 is the number of minerals gathered per second per harvester (before saturation, at least). Once I have found the total minerals gathered, I get a list of all units that have begun construction at that time and subtract it from the total and return it.

The formula for calculating wealth seems okay, but the initial array contained far more data than I ended up using and the formulas were a bit too hard coded. Things like MULE and Chrono Boost are not being accounted for, and supply count is ignored as well.

I like the idea of a function being passed a time value and returning a snapshot of the build status at that time, and the array storing the build information also containing when each item was started. This system would fairly easily allow new commands to be inserted mid way through the build.

I definitely need to make the calclations more dynamic, though. I’m also still unsure of how to handle the starting Nexus and 5 Probes. This system puts the build time at -100 and -17, respectively, and always adds 700 minerals to the mineral count.

All in all, this iteration did show some interesting ideas, particularly with where to store data on all of the units. I ended up sliding it in as an array inside the build class, but that seems impractical. I should probably set a race as a class, units as a class, buildings as a class and special abilities as a class. My next experimentation will involve testing those methods for viability.

I’ve recently begun work on a new project that should see the light of day in time for StarCraft II to launch on July 27. The project, being hosted over at http://sc2build.com, is the StarCraft II Build Order Calculator. The project aims to take the ease of use and share-friendly nature of World of Warcraft talent calculators and apply it to StarCraft II build orders.

The project is just beginning the iterative development phase, with some small scale tests of single aspects of the system. I began writing my notes on the site in plain text, but it quickly became apparent that I will have enough notes to require a full fledged blog.

Expect to see a flood of posts in the coming days as I think aloud on how to build this system and test various methods of implementation. I will be building it through iterative development, and as such there will be many micro tests in the coming weeks of single aspects of the system.

The first test that has already been pondered upon and attempted once is how to store the build order data in a URI without that URI becoming ungainly in length. You can see my notes on that test and see a sample of this one attempt in the iterative development section of that site.

It’s been a little over six months since I first began to use Kohana framework for all PHP development, and I thoroughly love the system. The only issue I’ve had with Kohana is the lack of built in, intuitive support for dynamic themes. I was unable to find an easy method to set up a theme that automatically wraps itself around all pages, while remaining dynamic enough to change certain elements on a page to page basis.

Over the past few days, I have been exploring methods to do this, with the following requirements:

• Keep all theme files separate from the application
• Require no changes to existing controllers and views to implement or change a theme
• Allow multiple applications on the same Kohana build to use the same theme
• Provide support for cascading themes

After a few failed attempts, I have found a solution that covers all four requirements and is pretty easy to implement. Of course, it is easier to implement this from the start, but if you have an existing Kohana site, it shouldn’t be too difficult to integrate this theming setup into the site. The concept of the theme is simple: create a theme as a module and then use hooks to implement the theme elements as appropriate.

Step 1 – Enable hooks

Without hooks, this theming set up won’t be able to execute at the proper time, and timing is essential. In order to enable hooks, open up application/config/config.php and change $config['enable_hooks'] to TRUE. With hooks enabled, all files within a hooks directory are included. This will be the starting point for inserting the theme content around the template.

Step 2 – Create a theme folder

One of my stated goals for the theme was to keep all theme files inside a single folder. This encapsulation allows for very easy modification, copying and replacing of themes. Make a folder called themes, and a subfolder named after the theme. This theme folder will operate just like a module folder, containing config, controllers, hooks, views, etc. My directory tree now looks like this:

/httpdocs
    /application
    /modules
    /system
    /themes
        /visual77
            /config
            /controllers
            /css
            /hooks
            /images
            /views
    /index.php

Step 3 – Add the theme folder to the list of enabled modules

In order to use the theme folder just as a module folder, you need to register the folder in the list of modules being used by your application. Open up application/config/config.php and add the theme folder to your list of modules at the end. This lets Kohana make full use of the directory.

$config['modules'] = array
(
    DOCROOT.'themes/visual77',
);

Step 4 – Create a hook for adding theme content

The most important step is creating a hook to add your theme content around your template content. You want to let your template proceed as normal, and after completion, add your theme data.

To create hooks in Kohana, just create a file inside your hooks directory. All files in that directory will be loaded automatically. For instance, make a file called theme.php inside themes/<theme-name>/hooks.

In order to do the theming, the ideal hook to use is system.post_controller. The previous hook, system.post_controller_constructor, is before the controller has executed; the following hook, system.send_headers, is after system.execute, and therefore can’t manipulate the controller.

The goal is then to create a hook on system.post_controller and manipulate the controller to take the template data and move it within the overall theme. To access the controller, call Kohana::$instance and begin manipulating. My hook file looks like this:

<?php defined('SYSPATH') or die('No direct access allowed');

// set my hook up to execute at the appropriate time
event::add('system.post_controller', 'visual77_theme');

function visual77_theme() {
    // grab the controller
    $controller = Kohana::$instance;

    // pull the original template aside
    $temp = $controller->template;
    // replace the template with my theme template
    $controller->template = new View('visual77/index');
    // put the original template into the content section of my theme
    $controller->template->content = $temp;
    // free up some memory by unsetting the temp variable
    unset($temp);
}

Step 5 – Begin building the theme

Now that the hook is in place, the only thing left to do is build your theme. In my example, create an index.php file in themes/<theme-name>/views/<theme-name>. This index file will contain the wrapper HTML for your theme, leaving the original template to drop neatly inside the content section that you define. When you begin adding css and images, you can keep it inside the theme directory. The usual .htaccess restriction on modules only applies to the module directory, which is why I put the themes outside of the module folder.

While building, remember to keep all theme related content, such as views and controllers, inside the theme directory. This makes the theme ultra portable and easily removed. To change themes, just change the name of the theme from Step 3 to the new theme directory.

In a system like this, you can even cascade themes. One great example of cascading themes is including barebones files like CSS resets and jQuery files. On a current project, I have to build an internal client administration and an external company website. Both use certain shared libraries and both need a CSS reset and jQuery files. Using cascading themes and module sharing, I can blend these two sites very neatly. The file structure for this project looks like this:

/httpdocs
    /internal_application
    /external_application
    /modules
        /shared_libraries
    /system
    /themes
        /internal_theme
        /external_theme
        /default
    /index.php

Both internal and external applications include modules/shared_libraries and themes/default. However, internal_application also includes themes/internal_theme and external_application includes themes/external_theme. A switch statement in index.php dynamically switches the application based on the hostname. In the end, I  have two sites running smoothly in parallel on a single Kohana build.

Final Thoughts

Kohana is a fantastic system, but really needs better support for dynamic theming. In my build process for this theming pattern, I tried to emulate the wordpress theme convention, where all theme files are kept clustered and are easily swapped out for a new theme.

To see a full theme example, you can download my Sample Kohana Theme and then modify it to fit your needs. Just remember to enable hooks and include this theme as a module!

In a recent Kohana project, I came across a somewhat odd PHP scenario – I had a multidimensional array that I needed to compress to a single dimensional array, but retaining all of the non array values. Basically, I need to make this change:

Array
    (
        to => Array
            (
                0 => stevep
                1 => bobw
            )
        bcc => Array
            (
                0 => paulj
            )
    )

Array
    (
        0 => stevep
        1 => bobw
        2 => paulj
    )

I looked around a bit for an existing PHP snippet to do just this, but they were all overly complex and used recursive callback functions. I had a feeling I could pull this off in a much more clean fashion. I toyed around a bit with the array functions and the ArrayObject library, and this is what I settled with:

$new_array = new ArrayObject();
array_walk_recursive($old_array, array($new_array, 'offsetSet'));
$flattened_array = array_keys($new_array->getArrayCopy());

The big drawback is the way ArrayObect::offsetSet() accepts its parameters, compared to how array_walk_recursive() sends the callback parameters; they are reversed. This causes the values to become keys, which has the effect of canceling out duplicate values. If your script needs duplicate values to remain intact, then this solution won’t work for you. Otherwise, it should work out just fine.

How many times have you been presented with a character encoding glitch on a PHP site that you thought was working properly? You finished the site months ago with no issues, but now you are being told some weird character is showing up on that page? Chances are, that character is either Ã, Â or Ä, possibly followed by some other random character. If I’m right, keep reading. If not, I offer my deepest condolences, for you are knee deep in a character encoding issue that I cannot help you with.

So what is it that causes that à to show up? In short – you have UTF-8 encoded data set to display as ISO-8859-1. But the more important question is how to prevent this from happening in the future. The easy answer to that – store all data in the same format as the final display. Convert the encoding as soon as you receive the data, either through an input field, reading a file or any other method. Don’t put anything in your database unless you are sure it is in the right format.

First, an introduction to the three important character encodings that you are likely to deal with – ASCII, UTF-8 and ISO-8859-1. Character encoding is, in a nutshell, the exact method that characters are stored and displayed by a computer. Since computers only deal in binary, there must be some way to convert from binary into a character. Character encodings come in two flavors (at least, two flavors I’ll be discussing) – single byte and multi byte encodings. Single byte encodings, such as ASCII and ISO-8859-1, use a single byte to represent a character. For instance, the letter “M” in ASCII is represented as 0x4D, whereas the number 4 is 0×34.

A single byte is limited to only 256 possible values, which rapidly becomes a limitation when you want to use characters not typically seen in English, such as “ç” or “ß”, and when you begin thinking about Asian languages, you can quickly see there simply isn’t room for all characters. Multi byte encodings use one or more bytes to represent a character. Each byte still only has 256 possibilities, but 2 bytes have 65,536 possibilities. But, what if there is confusion as to whether or not you are using single or multi byte encoding? Is that short string “0x3C 0xA5″ supposed to be the UTF-8 character å or the ISO-8859-1 string ÃÑ? And there we are – a sudden bug has shown up.

ASCII is the oldest of the three and the most basic. The ASCII character set started out as just 128 characters, and very English-centric. You can see that the basic ASCII table is very restricted to the English speaking world. The extended ASCII table goes off into some weird directions and is rarely used. The full ASCII table is only 256 characters, and thus fits neatly into a single byte, and so it is a single byte encoding.

ISO-8859-1 is also a single byte encoding, but you can see that it is a bit better in the extended range to support many Latin based languages. Unlike ASCII, ISO-8859-1 can handle the majority of Latin based languages without too much issue. It fails when you go outside of the Latin based languages, however.

The third character encoding is UTF-8, which is designed to support over 1.1 million characters, more than enough for all existing languages (and a few dead ones). Unlike ASCII and ISO-8859-1, UTF-8 is not limited to a single byte, but can vary between 1 and 4 bytes, depending on the character being used.

One thing to take note of is that the first 128 characters of all three encodings are identical. This is why a character encoding issue on an English website can take so long to spot. You can go months not knowing that you have a character encoding issue because the only characters you used were the same in all 3 encodings – 0x4D is an M in ASCII, UTF-8 and ISO-8859-1.

On to the meat of this article – dealing with character encodings in PHP. Namely, how to detect and convert encodings.

The magic bullet of dealing with character encodings in PHP can be summed up in three functions – mb_detect_encoding(), mb_detect_order() and iconv(). The mb libraries are designed for working with multibyte languages and iconv is a function to convert from one encoding type to another. One nonobvious restriction to the multibyte languages is the lack of native support for ISO-8859-1, since that is a single byte language. mb_detect_order() can be used to specify the order of encodings to scan when attempting to detect an encoding on a string.

The basics of dealing with character encoding conversion in PHP is a simple three step process:

1. Set the encoding types to scan (ASCII, UTF-8, ISO-8859-1). Luckily, this only has to be done once.
2. Identify the encoding of the string to convert.
3. Convert to the desired encoding type (I prefer UTF-8).

But, let’s cut to the crap. Sample code!

// tell the multibyte library which encodings to use
mb_detect_order('ASCII, UTF-8, ISO-8859-1');

// tell the browser that we are using UTF-8
header('content-type: text/plain; charset=UTF-8');

$string = "Fün wîth èñcøding!";

// UTF string displays properly
echo $string . "\r\n";

// convert to ISO-8859-1, which will confuse the browser
$string = iconv(
    mb_detect_encoding($string),
    'ISO-8859-1',
    $string
);
echo $string . "\r\n";

// convert back to UTF-8, which the browser understands
$string = iconv(
    mb_detect_encoding($string),
    'UTF-8',
    $string
);
echo $string . "\r\n";