I use Kohana exclusively for pretty much all of my websites (the ones I dont are simply static pages). Since I posted a critique of the PHP framework last year I've got more and more addicted to it. Simply for the ease with which I can prototype functionality. There is a directory on my file server stuff full of useful code snippets, models, libraries and views which I can drag-drop and reuse in any new projects.
Which is where the slight problem comes - things are a mess! Most of the sites are hosted on a single server I have with Servage (disclaimer: that is my affiliate link, but I do find them excellent hosts!) which means they can share the system and modules directories. When I dug into the server earlier tonight I found a total of 8 versions of the Kohana core shoved in there and no particular way to trace which particular sites used which (some, it turned out, were completely unused!). The danger is I could remove one that appeared unused and potentially kill a whole website in seconds. So I decided to sit down and take the time to record which site related to which and come up with an organised solution to the problem.
The Solution
The first step was to switch all of my sites to use the same core framework, allowing me to clear the dupes out. That seems a simple fix but bear with me! A further optization idea occured to me.
Prevuiously all the directory configuration was done in the index.php file in every site root. Why can these not be in a single directory together leaving the inex file simply to load the relvant one. This has the dual benefit of making the sites easy to find AND cut down the amount of PHP code inthe web root to ONE line!
Here is an example cfg file:
define('IN_PRODUCTION', FALSE);
// APP Name
define('APP_NAME', 'bloggish');
$kohana_application = '../apps/bloggish';
// include the core framework configuration
require('framework.php');
//.. and so on (usual core initialisation stuff)
The next logical step is, obviously, to condense even more. So a second file called frameworks.php was created which sets up the system and modules directory for all the sites. To make things even more configurable I added an array containing a reference to sites for which I needed to fine tune the directory path (plus a default for the rest). Using a constant in the individual site config file (APP_NAME) I can now change system paths on the fly for nearly 15 websites from just one file as the below example deomonstrates (shortened for ease):
$kohana_modules = '../modules';
$frameworks = array(
'default' => '../frameworks/latest',
'bloggish' => '../frameworks/latest',
'livemeta' => '../frameworks/kohana_2_0_0',
'errant' => '../frameworks/kohana_2_3_1',
);
$kohana_system = (array_key_exists(APP_NAME, $frameworks)) ? $frameworks[APP_NAME] : $frameworks['default'];
define('CORE_UPGRADE', FALSE);
Upgrading will be a breeze now. The latest Kohana framework core sits in /latest, with an upgrade reayd to go I can copy that to Kohana_VERSION_NUMBER and update the default paths. Then upload the latest core and switch each site to the default a few at a time. Any incompatabilities can easily be tweaked back to use the older core until issues can be fixed.
Next Steps
This has potential to go far for me! Some ideas I had were:
- Write me a private web front end to update the paths
- Add a CORE_UPGRADE constant that I can switch to TRUE allowing the sites to show an "Essential Maintenance" notice whilst the upgrade goes down (and, hopefully, still allow me full access via IP or URL secret key code).
- The ability to tweak which module path to use. Whilst you can fine tune this in the cfg files of individual sites I also have "clones" of those sites still under active development on which to work - and these obviously need to use a different module path.