Assumptions

1. You are using WordPress permalinks with mod_rewrite or a similar option.
2. You don’t have register_globals() turned on. Turn it off to ensure WordPress’s global variables don’t get removed by Kohana.

Renaming

First, you need to rename the __() function in Kohana. Say, you rename it to __t(). You’d need to replace it everywhere it appears, which if you use an editor like Netbeans that can find usages of a function or method is pretty easy.

Hierarchy

The next decision you need to make is whether you want to load WordPress inside Kohana or Kohana inside WordPress. I prefer the latter, which I’m documenting below.

I put the kohana directory in my theme directory.

In your functions.php file of your theme, simply

include TEMPLATEPATH . '/kohana/index.php';

Kohana Configuration

Your Kohana’s index.php file also needs some work. Remove the lines that look for install.php as they will load ABSPATH . WPINC . 'install.php' (usually wp-includes/install.php relative to your WordPress installation directory) instead and display an error message in your wordpress admin. You also need to change the error_reporting as at the moment WordPress fails E_STRICT.

You will very likely need to remove the last few lines of your bootstrap (in Kohana) that process the request, and change your init:

Kohana::init(array(
	'base_url'   => get_bloginfo('home') . '/',
	'index_file'   => '',
));

In either your WordPress functions.php file or in your bootstrap, add these lines:

remove_filter('template_redirect', 'redirect_canonical');
add_filter('template_redirect', 'Application::redirect_canonical');

where Application is a class of your choosing.

My code for the Application class (without the class definition) is:

public static function redirect_canonical($requested_url=null, $do_redirect=true)
{
    if (is_404() && self::test_url())
    {
        echo Request::instance()->execute()->send_headers()->response;
        exit;
    }

    redirect_canonical($requested_url, $do_redirect);
}

public static function test_url($url = NULL)
{
    if ($url === NULL)
    {
        $url = str_replace('?'.$_SERVER['QUERY_STRING'], '', $_SERVER['REQUEST_URI']);

        $url = trim($url, '/');
    }

    foreach (Route::all() as $route)
    {
        /* @var $route Route */
        if ($params = $route->matches($url))
        {
            $controller = 'controller_';

            if (isset($params['directory']))
            {
                // Controllers are in a sub-directory
                $controller .= strtolower(str_replace('/', '_', $params['directory'])).'_';
            }

            // Store the controller
            $controller .= $params['controller'];

            $action = Route::$default_action;

            if (isset($params['action']))
            {
                $action = $params['action'];
            }

            if (!class_exists($controller))
                return false;
            if (!(method_exists($controller, 'action_' . $action) || method_exists($controller, '__call')))
                return false;
            return true;
        }
    }

    return false;
}

which lets WordPress do it’s redirect for any page that may have moved e.g. /about/calendar to /calendar as long as you don’t have an about controller and calendar action defined.

So there you have it. Any urls not defined within WordPress will fall to your defined controller (or use your theme’s 404 template).

Additional

This isn’t required, but you could put your theme’s header.php under your kohana views folder (application or in a module) and from any of your theme files

echo View::factory('header')

You could do the same thing with your footer (or any other files for that matter). In your header.php, you could also do this:

if (isset($title)) echo $title; else wp_title(YOUR_OPTIONS);

That way you could in your controller

echo View::factory('header')->set('title', 'YOUR_TITLE');

To keep urls consistent, you may have to take off the / from the end of WordPress permalinks so /%year%/%monthnum%/%day%/%postname%/ becomes /%year%/%monthnum%/%day%/%postname%, etc

SELECT `wp_category`.`id` AS `category:id`, `wp_category`.`name` AS `category:name`, `wp_category`.`created` AS `category:created`, `wp_category`.`modified` AS `category:modified`, `wp_lib_items`.* FROM `wp_lib_items` LEFT OUTER JOIN `wp_lib_borrowers` ON (`wp_lib_items`.`id` = (SELECT `wp_b`.`id` FROM `wp_lib_borrowers` AS `wp_b` WHERE `wp_b`.`item_id` = wp_lib_items.id ORDER BY `wp_b`.`status` ASC LIMIT 1)) LEFT OUTER JOIN `wp_congregate_members` ON (`wp_lib_borrowers`.`member_id` = `wp_congregate_members`.`id`) LEFT JOIN `wp_lib_categories` AS `wp_category` ON (`wp_category`.`id` = `wp_lib_items`.`category_id`) ORDER BY IFNULL(NULLIF(`wp_lib_borrowers`.`due_date`, '0000-00-00'), '3333-33-33') DESC, `wp_lib_items`.`title` ASC LIMIT 10 OFFSET 0

Now I’m off to tango with PHP’s SplPriorityQueue.

[syntax,alg.phps,php]

So, all my problems are from the function get_items(). Basically, I don’t want to loop through the $used array to find out what values have a particular length. So based on my analysis, we have a theoretical function f(x, y) which gives the following when run:

f(1, 26) = 0
f(2, 26) = 26
f(3, 26) = 702
f(4, 26) = 18278

ie, the set {0, 26, 702, 18278, …}

f(2, 26) - f(1, 26) = 26      = 26 ^ 1
f(3, 26) - f(2, 26) = 676     = 26 ^ 2
f(4, 26) - f(3, 26) = 17576   = 26 ^ 3

Okay, now I see it clearly. Here goes:

[syntax,alg2.phps,php]

So, why do I need this? I have to do a test on an PHP-Ajax newsletter WordPress plugin. On a site I’m working on, we need to send emails to 70000 subscribers, and the current plugin loops through all the records in the database in one go. Of course the max execution time passes before then. I needed to generate a test database of 70000 emails @localhost.com to help me test while I rewrite the plugin.

Well, onto the actual rewrite.

The biggest problem, I think is that I cannot even implement the most basic structure needed — a binary tree — not to talk of directed and undirected graphs. Not knowing doesn’t necessarily translate to not wanting to know, and the fact that I can’t write a simple Insertion-Sort algorithm kind of makes me feel down.

I’m dusting off my old C++ book and starting over again from arrays and linked lists.

If you happen to know where a poor coder-wannabe can get a simple algorithms book — with code examples — I’d be very grateful.

I figured I had to learn something about MVC sometime, but here I am doing so — and it isn’t funny.

My friend Kwame had a book on Ruby which I perused and found the language was relatively simple. Now for such a simple, amazing language — and framework — one would think the install process was just as easy. Well, it isn’t 00 at least not to me.

I read tutorials on the arcane of the arcane, built it myself and whatnot and in the end couldn’t get it to run on my Windows machine — not that it was present in the online repositories to get it for my Fedora machine.

My answer? Screw rails. If I need a framework I’ll go for Cake — but we all know I won’t. After all, I’m very egotistical and want to try writing everything out myself.

The crazy context menu item just keeps getting in my way…

Doing a Google search, it’s apparent I’m not the only one who’s looking for such a feature. I know, I know. I could have written the column names manually during the time I typed this.

I’ve called session_set_cookie_params to no avail everywhere in my code — the time in the db’s correct, but the session always expires when the browser is closed. Setting the session cookie myself gives a different problem — it gets invalidated on the next page load.

Arrrrrrrgh! I hope it really is because I’m running it on a local domain. If it isn’t, I just might get angry, download the PHP source, learn C and rewrite PHP in no particular order (I wish!).

Something about code profiling from George Schlossnagle’s Advanced PHP Programming came back to me, and the hunt began. I must have been typing in the wrong stuff because only commercial products kept coming back until I got a Sitepoint article on XDebug.

Downloaded it, got WinCacheGrind and spotted the problem in less than a minute. That ‘nifty’ html_2_xhtml function I wrote sometime before when I was just starting out with regular expressions did a lot of arcane stuff with the e modifier of preg_replace.

Solution: swipe the wpautop and wptexturize functions from WordPress. The slow content item runs in less than 0.6 seconds now, and the other items take between 0.1 and 0.3 seconds to process. And er, the PHP website warns about using strstr just to determine if a needle exists in the haystack. Replacing it with strpos in my own version of wptexturize saw an increase in response times (by about 17 milliseconds).

Let’s hope I don’t keep profiling away instead of doing some real coding in the next few weeks.