function beforeFilter(){
    $admin = Configure::read('Routing.admin');
    if (isset($this->params[$admin]) and $this->params[$admin]){
        $this->layout = 'admin';
    }
    else {
        $this->Auth->allow();
    }
}

The problem with this however is static pages handled by the pages controller cannot be password protected. To resolve this problem, I had to overload the PagesController class that Cake comes with, and add in the required functionality. Part of the reason for doing this for me was to allow a setup where there was a password protected admin welcome page or control panel located at my_app_URL/admin, so I’ll show you the necessary routing to achieve that too.

Adding a route and overloading PagesController

First of all, copy your_app_dir/cake/libs/controller/pages_controller.php into your_app_dir/app/controllers with the rest of your application’s controllers. Then fire up an editor and take a look at your newly copied version.  You’ll see there is a function called display, this is what the pages controller uses to display pages. There is a route in app/config/routes.php that maps /pages/* to /pages/display/* to make the URL easier on the eyes, so if we’re gonna have /admin/pages/* working properly, we’ll need a similar route. Open up app/config/routes.php, and underneath the line

Router::connect('/pages/*', array('controller' => 'pages', 'action' => 'display'));

add in the following route:

Router::connect('/admin/pages/*', array('controller' => 'pages', 'action' => 'display', 'admin' => true));

Now, when admin routing is enabled, Cake looks for controller actions appened with “admin_”, so we’d better add in the function to handle this in PagesController. Open it up, and underneath the display function, add the following:

function admin_display() {
    $path = func_get_args();
    $temp = null;

    $count = count($path);

    if ($path[0] != 'admin') {
        //This adds admin to the beginning of the path so the pages controller will look in the 'admin' folder in pages directory
        $path = array_merge((array)'admin', $path);
    } else {
        //This removes admin from the beginning if it's there already, and sends the request round again so we end up with URLs that look like app/admin/pages/x
        //when app/admin/pages/admin/x is requested somehow.
        $path = array_slice($path, 1);
        $this->redirect(array_merge(array('controller' => 'pages', 'action' => 'display', 'admin' => true), $path));
    }

    if (!$count) {
        $this->redirect('/');
    }
    $page = $subpage = $title = null;

    if (!empty($path[0])) {
        $page = $path[0];
    }
    if (!empty($path[1])) {
        $subpage = $path[1];
    }
    if (!empty($path[$count - 1])) {
        $title = Inflector::humanize($path[$count - 1]);
    }
    $this->set(compact('page', 'subpage', 'title'));
    $this->render(join('/', $path));
}

As you can see it’s fairly similar to the display function, with a few extra lines added in that handle admin pages. There are a few subtleties here which I will explain in a second. Before that however, we also require a slight change to the existing, non-admin display function. Look for the if statement below:

if (!empty($path[0])) {
    $page = $path[0];
}

and change it to:

if (!empty($path[0])) {
    $page = $path[0];
    if ($page == 'admin') {
        //Sends admin page requests to their proper place to stop sneaky access attempts
        $this->redirect(array_merge(array('controller' => 'pages', 'action' => 'display', 'admin' => true), $path));
    }
}

Ok so what have we done?

1. The added nested if statement in the display() function redirects requests for /pages/admin/x to their proper place, /admin/pages/x.
2. The ‘else’ clause of the if ($path[0] == ‘admin’) in admin_display redirects requests for /admin/pages/admin/x to /admin/pages/x, which just tidies up a URL aesthetics issue.
3. Finally, the first part of the same if statement is what handles the /admin/pages/x requests proper – it adds the ‘admin’ part back to the beginning of the $path variable that point 2 removes. This is actually just exploiting a subtlety of the pages controller, ’subpages’ (this seems to be quite hard to find in the documentation actually) – requests sent to /pages/a/b will display a page b stored in the folder your_app_dir/app/views/pages/a, rather than a page b stored in the pages root. Adding this additional logic helps organisation a bit by storing all admin pages in you_app_dir/app/views/pages/admin/.

So now this is all in place, everything should work correctly. Requests to /pages/admin/x and /admin/pages/admin/x both get sent to /admin/pages/x, and these require proper authentication.

The final step is to add in a route that allows my original use for this whole setup to work properly – displaying an admin homepage or control panel that requires authentication when a user visits your_app_URL/admin, i.e. without referring to any controllers or actions. First, create a page in your_app_dir/app/views/pages/admin/, called home.ctp that contains the content you want. You can now access this from your_app_URL/admin/pages/home, but the shorter URL works after adding the route:

Router::connect('/admin', array('controller' => 'pages', 'action' => 'display', 'admin' => true, 'home'));

Hooray! We now have an admin homepage. Hope everything worked for you, hit me with a comment if you have an issues and I’ll try and help out.

Joining the sections together

If you followed the first part of the tutorial, we currently have a few sections that we’ve generated models, controllers and views for. By navigating to your_app/controllername/action in your browser, you can access the different functions of the application. But unless your users know this in advance, they have no way of accessing them.

The easiest way of implementing navigation common to all pages is to use Cake’s built in templating system, the page “layout”. Cake uses its built-in layout if it finds no user defined layout default available. To add one, create the file your_app_dir/app/views/layouts/default.ctp, and put in your basic page layout. Mine looked like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title><?php echo $title_for_layout ?></title>
<link href="favicon.ico" type="image/x-icon" rel="shortcut icon" />
<?php echo $html->css('default') ?>
<?php echo $scripts_for_layout ?>
</head>
<body>
<div id="container">
<div id="header">
<h1>King-Jon Illustration</h1>
</div>
<div id="navigation">
<ul>
<li><?php echo $html->link('News', array('controller'=>'News'))?></li>
<li><?php echo $html->link('Works', array('controller'=>'Works'))?></li>
<li><?php echo $html->link('Sketches', array('controller'=>'Sketches'))?></li>
<li><?php echo $html->link('Friends', array('controller'=>'Friends'))?></li>
</ul>
</div>
<div id="content">
<?php echo $content_for_layout ?>
</div>
<div id="footer">
</div>
</div>
</body>
</html>

You’ll notice this looks like a pretty normal basic page skeleton, with a few extra bits of PHP inserted. The $title_for_layout, $scripts_for_layout and $content_for_layout variables are filled in by Cake automatically depending on what the current page request is and the title and content are fairly self-explanitory.  The scripts variable lets you specify scripts on a per-page basis but still include them in the <head> section.  The $html->xxx code snippets are part of the Cake HtmlHelper. This allows you to insert well formatted elements easily – the $html->css(‘default’) includes the stylesheet “css/default.css” (this is stored in the your_app_dir/app/webroot/css directory), and the $html->link lines let you point to different parts of your app easily. You could just add normal links, such as <a href=”/news/”>, but pointing to the controller allows a bit of flexibility if you want to change anything further down the line.

Adding a splash page

As it was an art portfolio website, it was decided a splash page would be useful to have, to give a good first impact when entering the site and the ability to show off a bit of artwork right away. Cake uses its built-in pages controller to handle static pages, and the different pages are stored in the folder your_app_dir/app/views/pages. To view a page, you navigate to the URL your_app/pages/pagename. Here, the pages controller doesn’t take an action, so the additional directory level on the URL is an argument passed to the controller, in this case the name of the page to display.

Cake also automatically serves up a default page, called “home”, when a user requests the root of your_app. The name of this page is set by Cake’s router, and if we look in your_app_dir/app/config/routes.php, we see at the bottom, the lines:

/**
* Here, we are connecting '/' (base path) to controller called 'Pages',
* its action called 'display', and we pass a param to select the view file
* to use (in this case, /app/views/pages/home.ctp)...
*/
Router::connect('/', array('controller' => 'pages', 'action' => 'display', 'home'));
/**
* ...and connect the rest of 'Pages' controller's urls.
*/
Router::connect('/pages/*', array('controller' => 'pages', 'action' => 'display'));

The comments tell us what’s going on – this is what maps the pages to the locations I have talked about. You can add your own mappings here too if you like.  For our splash screen however, we can just make use of the already defined “home” page, so edit this to make it look how you want, you’ll find it in your_app_dir/app/views/pages/home.ctp. Mine looked like this:

<?php $this->layout = "splash" ?>
<div id="splash">
<?php echo $html->image("splash.png",
array("alt" => "King Jon Illustration",
"url" => array("controller" => "news")));?>
</div>

A couple of things to note here. The first line $this->layout = “splash”, tells Cake not to use the “default” layout we created earlier, but to instead use one called “splash”.  I sneakily created a splash layout without telling you here, but it is in fact just an exact copy of the default layout with the navigation div removed, to give the page a more “splashy” feel.

Next, I used the image HtmlHelper to include an image called “splash.png” – this is located in my_app_dir/app/webroot/img, the location the image helper looks in. The second argument is an array of additional attributes, “alt” being the alt text, and “url” puts an <a> element around the image, creating a link to the specified address.

Admin section authentication

At the minute, all our sections are wide open for anyone to just stroll in and start adding news, posting works, and generally delete or edit existing pieces of data. This clearly isn’t ideal, so next on the agenda is sorting this out. We’ll use the Authentication component for this.

First of all, we want all add/edit capabilities to be kept within the admin section, so the first step is to remove the non-admin versions of these. Go through all five of the your_app_dir/app/controllers/*_controller.php, and delete the functions “add” and “edit” that were automatically generated. Next, clean up the views associated with these functions – delete the two files your_app_dir/app/views/*/add.ctp and edit.ctp in all five of the view directories. This means now we can only add and edit our data by navigating to your_app/admin/controller/add etc.

We’re going to want to use authentication for all our controllers, as all of them have an admin section that we need to login for. Instead of telling each controller to use this component individually, we can tell the whole controller superclass that we want to use it, to save repetition. Open the file your_app_dir/app/app_controller.php and add the line in the class definition like so:

class AppController extends Controller {
var $components = array('Auth');
}

Now if you try and visit an admin page in your_app, you’ll be greeted with an error messages telling you there’s no login action in the Users controller, which is where the Auth component looks by default, so we’d better add this in. Edit the file your_app_dir/app/controllers/users_controller.php, and right at the bottom of the class definition, add these two functions:

function admin_login() {
}
function admin_logout() {
$this->Redirect($this->Auth->logout());
}

Now try and navigate to an admin section again. You’re told that there’s a missing view this time! Better do what Cake says and add one in. Create the new file your_app_dir/app/views/users/admin_login.ctp, and fill it with the following skeleton login form:

<?php
if  ($session->check('Message.auth')) $session->flash('auth');
echo $form->create('User', array('action' => 'admin_login'));
echo $form->input('username');
echo $form->input('password');
echo $form->end('Login');
?>

Now there are two problems: we’re greeted with a login for all the admin sections – a slight problem as we don’t have credentials… we’ve locked ourselves out of the whole website! There are also some error messages when we try and view the non-admin sections of the site, which seem to want us to login but can’t find a login() action (remember we only created admin_login, and didnt bother with login). Fortunately, we can get around these problems by adding exceptions to the authentication. Open up the users controller, your_app_dir/app/controllers/users_controller.php, and then add in the following controller callback function (I added it in near the top):

function beforeFilter() {
$this->Auth->allow('admin_add', 'admin_index');
}

This gives access to the admin add and index (which lists all users) actions of the users controller. So now, navigate to your_app/admin/users/add, and create a login for yourself! You’ll probably want to remove the allow line once you’ve added yourself to prevent anyone else creating a login for themselves when you’re not looking.

We’re still however stuck with the problem that none of the non-admin sections work, so we need to add an Auth exception to all non-admin sections. The best way to do this is by adding the following into the your_app_dir/app/app_controller.php AppController class definition, underneath where we told it to load the Auth component earlier:

function beforeFilter(){
$admin = Configure::read('Routing.admin');
if (isset($this->params[$admin]) and $this->params[$admin]){
//$this->layout = 'admin';
}
else {
$this->Auth->allow();
}
}

Now we should be able to navigate the site without any problems. The commented out line above allows the future addition of an admin.ctp layout file that will automatically be loaded when viewing admin sections – I haven’t done this yet though.

The next phase of the project is to go through and edit all the views, layouts & CSS and get them looking how you want, and this is largely an exercise in usual web development – you can take a look at the default views to see how to include data provided by Cake  fairly easily. If I come across anything else I think might be of help while I’m building the rest of the site, I’ll make small posts for those too. Hopefully you’ve been able to follow this introduction to Cake so far, but if not drop me a line in the comments below and I’ll try and give you a hand where I can. Good luck!

Downloading and setting up CakePHP

Create a new directory on your webserver where your cake website will reside (or just use the web root if this is going to be the main webpage).  Next, we’ll need to actually download CakePHP.  If you have shell access to your webserver, you can use SVN to get the latest stable release automatically: navigate to the directory and use the command (note the “.” at the end of the command)

$ svn checkout https://svn.cakephp.org/repo/trunk/cake/1.2.x.x/ .

to do so.  If you don’t know what any of this means, just download the latest stable release from the CakePHP website and extract the files into the directory you created – make sure the various .htaccess files don’t go astray in the process.

Some standard setup is also required: we need to tell cake how to connect to our database server, to do this follow the steps on this page. There’s also a couple of optional (but recommended) configuration steps here. After this, you should be able to browse to the directory in a web browser and see the default page – there shouldn’t be any errors or warnings if all configuration has been completed correctly (N.B. if the default page looks a bit plain – no colours, CSS styles etc., then you probably have a mod_rewrite issue, check out this page).

Now we can begin work on the site.

Bake a cake

Cake’s bake utility is a handy way of generating the basic code structure for a web application, saving a lot of the tedious grunt work that often comes with setting up a new project. The general idea is often seen in frameworks that take advantage of the MVC (model-view-controller) programming pattern (such as Ruby on Rails, and others). It involves creating a database structure that describes the various data entites – or “models” – of our application, then running a script that reads this structure and generates the framework code for the models. It can then generate standard interfaces (or “views”) for displaying the data, and “controllers” which tie our interfaces and models together, allowing data to be input and manipulated. Of course, these standard pieces of generated code probably won’t be exactly what we want, but they can provide a great starting point to work from and then tweak.

First of all, we’ll create our database structure. I’m using an empty database for this project, although if you’re using a database with tables from other projects in, you can set Cake to work with a table prefix fairly easily. Let’s get to work building the tables.

The first model will be “News”, containing data for a news section where the owner can post updates and information onto the site.  To represent this, I created a table “news”, with four fields:

• id – type: int – extra: auto_increment – primary key (A unique identifier for each record)
• date – type: date
• title – type: text
• body – type: text

The next model is for representing finished works placed onto the site – the main part of the portfolio. Create a table called “works” with the four fields:

• id – type: int – extra: auto_increment – primary key
• date – type: date
• title – type: text
• desc – type: text

Next up, a sketches model. This is pretty much the same as “works” but will contain sketches as opposed to finished pieces. Create a table called “sketches” with the same four fields as above.

A friends model for a page that will contain links to websites belonging to friends of the owner, along with a thumbnail and description. Create the table “friends”, with the fields:

• id – type: int – extra: auto_increment – primary key
• name – type: text
• url – type:  text
• desc – type:  text

There is one last model we’ll need: “users”. By creating a table with a username/password, we can let the owner login to manage the site, add new works, sketches and friends. Multiple users will mean we can also have a login to test out the site. So create the “users” table, with fields:

• id – type: int – extra: auto_increment – primary key
• username – type: varchar(20)
• password – type:  varchar(50)
• displayname – type:  varchar(20) (Name shown when making posts etc – can be different from login name)

Now all our tables are created, we can get to baking. In a console, navigate to yourdir/cake/console, and then run the command

$ ./cake bake

and you’ll be presented with:

Welcome to CakePHP v1.2.2.8120 Console
---------------------------------------------------------------
App : app
Path: /home/dave/public_html/kingjon/app
---------------------------------------------------------------
Interactive Bake Shell
---------------------------------------------------------------
[D]atabase Configuration
[M]odel
[V]iew
[C]ontroller
[P]roject
[Q]uit
What would you like to Bake? (D/M/V/C/P/Q)
>

at this point, if you haven’t setup your database configuration yet, you can create it with the “[D]atabase Configuration” option. We’ll be choosing the “[M]odel” option however:

> m
---------------------------------------------------------------
Bake Model
Path: /home/dave/public_html/kingjon/app/models/
---------------------------------------------------------------
Possible Models based on your current database:
1. Friend
2. News
3. Sketch
4. User
5. Work
Enter a number from the list above, type in the name of another model, or 'q' to exit
[q] >

notice our database tables have been read, and cake has automatically figured out that an entry in “works” will be a “Work”,  “sketches” give a “Sketch” and so on, but “news” is still “News”.  We may as well start with the first entry, so enter 1, and hit enter. You’ll be asked the following:

[q] > 1
Would you like to supply validation criteria for the fields in your model? (y/n)
[y] >

Cake has a set of predefined validation criteria to make sure that data entered for a model is correct. We may as well take advantage of these, so hit “y” and press return.

Next Cake goes through each of the fields in our table, and asks what validation criteria we want for each. id is first, and I chose “blank” (number 3 in my case, athough I guess this number may change depending on which version of cake you’re using). This ensures that no data is entered for the id, which is what we want as the field is auto generated by mySQL’s auto_increment. For name I chose “Do not do any validation on this field” as the name can contain any text. For url I chose the rather fitting “url” (number 27) validation type. Finally, for desc I chose “Do not do any validation on this field” as well.

A final couple of questions now pop up: model associations – for this I just hit “n” as our model is simple and has no relational properties – and a confirmation to check your settings are ok:

---------------------------------------------------------------
The following Model will be created:
---------------------------------------------------------------
Name:       Friend
Validation: Array
(
    [id] => blank
    [url] => url
)

Associations:
---------------------------------------------------------------
Look okay? (y/n)
[y] >

Confirm this and there’s a final question about SimpleTest and unit test files. This is to do with Cake’s testing framework which I personally haven’t tried, and as this is just a simple project I won’t other using it, so just hit “n” here.  Congratulations, you’ve successfully baked your first model!

Continue the process now, and bake the other models with appropriate validation criteria (I used “blank” for all the IDs, “date” for the date fields, and no validation for all the title/description fields – although for the users table, I chose “notEmpty” for the username, password and displayname fields as blank entries here would cause problems).

Next up, time to bake some controllers. I’ll show you the output from my run through first including the options I chose, and explain to you afterwards what some of them mean and why I chose them:

What would you like to Bake? (D/M/V/C/P/Q)
> c
---------------------------------------------------------------
Bake Controller
Path: /home/dave/public_html/kingjon/app/controllers/
---------------------------------------------------------------
Possible Controllers based on your current database:
1. Friends
2. News
3. Sketches
4. Users
5. Works
Enter a number from the list above, type in the name of another controller, or 'q' to exit
[q] > 1
---------------------------------------------------------------
Baking FriendsController
---------------------------------------------------------------
Would you like to build your controller interactively? (y/n)
[y] > y
Would you like to use scaffolding? (y/n)
[n] > n
Would you like to include some basic class methods (index(), add(), view(), edit())? (y/n)
[n] > y
Would you like to create the methods for admin routing? (y/n)
[n] > y
Would you like this controller to use other helpers besides HtmlHelper and FormHelper? (y/n)
[n] > n
Would you like this controller to use any components? (y/n)
[n] > n
Would you like to use Sessions? (y/n)
[y] > y
You need to enable Configure::write('Routing.admin','admin') in /app/config/core.php to use admin routing.
What would you like the admin route to be?
Example: www.example.com/admin/controller
What would you like the admin route to be?
[admin] > 

---------------------------------------------------------------
The following controller will be created:
---------------------------------------------------------------
Controller Name:  Friends
---------------------------------------------------------------
Look okay? (y/n)
[y] >

Creating file /home/dave/public_html/kingjon/app/controllers/friends_controller.php
Wrote /home/dave/public_html/kingjon/app/controllers/friends_controller.php
SimpleTest is not installed.  Do you want to bake unit test files anyway? (y/n)
[y] > n

Ok, I started by building the controller for the friends section again. Building interactively gives you access to more options in the setup, so I went for that. Scaffolding is basically a flag you set in your controller telling cake that you want basic skeleton app behaviour to be created at runtime. By baking we are given the advantage of pre-generating code that does more or less the same thing, but that we can also edit later, so choosing “n” for scaffolding is a wise plan in our case. The next question about basic methods is where our pre-generated skeleton code comes from, so choose “y” here. Admin routing creates an admin section for adding/deleting/modifying records. As we don’t want visitors to the website to be able to do this, but the portfolio owner will be wanting to do this, an admin section is a good idea, so “y” to this question as well. We are now asked about helpers. Helpers are libraries built into cake that add functionality and generally make your life easier. At the minute we’ll just use the default two, so choose “n”, although more can be added later easily if we need them. Next up are components which are similar to helpers, although these are more at a behind-the-scenes level, and helpers are used more for displaying and formatting data on the interface side of things. Again we may use some of these later, but at the minute just hit “n” for components. Finally hit “y” for sessions, and I agreed to the default name for the admin section, “admin”, although you may wish to change this.  Hit “y” for the confirmation, and then “n” for the testing question again.

Repeat this for the other controllers.

Finally we have to make some views, so here we go again, although this step is a lot quicker. Choose “[V]iew” from the main menu, and I’m starting off with Friends again. The first question it asks is seemly about the scaffolding again:

Would you like to create some scaffolded views (index, add, view, edit) for this controller?
NOTE: Before doing so, you'll need to create your controller and model classes (including associated models). (y/n)
[n] > y

Before we wanted nothing to do with scaffolding, but here we hit “y”: this generates the views for the basic class methods we agreed to in the controller generation. We’re then asked about admin routing views, and we press “y” again, and the script tells us it’s generated the files we need.

Repeat this process for the other views, and then we’re done with baking.

Let’s see what we’ve done so far…

Now what exactly has all that baking achieved? If you go to the index page of your app directory in the web browser, you’ll just be greeted with the same welcome page. But try navigating to your_app_folder/news or your_app_folder/works and a new page comes up. You can give adding a piece of a news a go with the “New News” link on the news page. A form pops up letting you fill in the date, title and post body, and you’ll notice the entry form lets you fill in the date correctly and so on.  We aren’t prompted to enter an ID because our validation criteria said we wanted this to be blank as it would be generated automatically. Once the post has been added, an entry comes up on the main page, letting us view the individual post, edit it or delete it.

In fact, if you’ve been keeping an eye on the URLs, you’ll have noticed that they take the form your_app_folder/controller/action. The actions were generated automatically by our baking process, and we’ll take a look at them in a bit more detail later on.

You’ll notice you can also go to your_app_folder/admin/news to get the same page – this is our admin routing. At the minute there is no difference between the two sections, but we’ll edit it so that you wont be able to add/edit/delete thing unless you’re in the admin section, and logged in correctly.

As you can see, baking has set up all the basic logic for our various sections, we just need to tweak it and glue it together a bit, and I’ll deal with that in the next part of the tutorial.

In the end I used a wonderful little script called Lightbox 2 and a bit of JavaScript Prototype magic to produce this (try clicking on the image files).

The directory listings are provided by an apache module going by the name of mod_autoindex. This module allows you to insert a custom header and footer through the directives HeaderName and ReadmeName. The plan is to insert some HTML that includes the Lightbox code and tags all the links to images with the rel=lightbox attribute that Lightbox uses to function.

Create a directory called lightbox in your server’s document root. Download Lightbox 2 and extract it to that directory (go to http://www.yourwebsite.com/lightbox to try it out). To get the Lightbox ‘loading’ and ‘next’ images to show up, you need to edit a couple of lines in the configuration section of js/lightbox.js that comes with Lightbox. Change the following

LightboxOptions = Object.extend({
    fileLoadingImage:        'images/loading.gif',
    fileBottomNavCloseImage: 'images/closelabel.gif',

to look like

LightboxOptions = Object.extend({
    fileLoadingImage:        '/lightbox/images/loading.gif',
    fileBottomNavCloseImage: '/lightbox/images/closelabel.gif',

I also adjusted resizeSpeed to 9 to make it feel a little snappier, change this to your taste.

Now create a new file called lightbox.html in your /lightbox directory and copy and paste the following:

<script src="/lightbox/js/prototype.js" type="text/javascript"></script>
<script src="/lightbox/js/scriptaculous.js?load=effects,builder" type="text/javascript"></script>
<script src="/lightbox/js/lightbox.js" type="text/javascript"></script>
<script type="text/javascript"><!--
    // Insert the lightbox stylesheet into <head>
    var stylesheet = new Element('link', {  'rel': 'stylesheet',
                                            'href': '/lightbox/css/lightbox.css',
                                            'type': 'text/css',
                                            'media': 'screen'
                                         });
    $$('head')[0].appendChild(stylesheet);

    // Check for links preceded by the image icon provided by mod_autoindex.
    // On my setup the src attribute in the img tag preceding a link to an image
    // is "/icons/image2.gif". This is used to identify links to images.
    $$("a").each( function(elmt) {
            // The default output is tabular, so check the previous cell for the img tag
            imgelmt = elmt.up().previous().down()
            // If the FancyIndexes option is set, the output is formatted differently
            if (imgelmt == undefined) { imgelmt = elmt.previous('img') }
            if (imgelmt.readAttribute('src') == "/icons/image2.gif")
            {
                elmt.setAttribute('rel', 'lightbox[images]');

                // As ps suggested, provide a link to the image in the lightbox description
                link = "<a href='" + elmt.readAttribute('href') + "'>" +
                        elmt.innerHTML.stripScripts().stripTags() + "</a>";
                elmt.setAttribute('title', link );
            }
        } );
// --></script>

Now all you have to do is tell apache to include this file in its directory listing page. Simply paste the following two lines into a file named .htaccess and copy it to any directory that you want Lightbox to appear in.

Options Indexes
ReadmeName /lightbox/lightbox.html

Et voila! No php, no databases to maintain. Image galleries don’t get much simpler than that.

The website suggests building from source – I attempted this but there are currently a couple of issues with compilation mentioned in the wiki, and even with the fix suggested I couldn’t quite get it to work – although I didn’t try too hard it must be said; instead I found another method which I will walk you through now.

Installing and Trying It Out

The method I ended up using (thanks to my buddy Matt for figuring this out) revolves using binaries from the Debian experimental repository, which seem to work perfectly. First, you can download the awesome 3.1-1 package (N.B. The binaries I’m linking to here from Debian’s website are for i386, for others just search for them on the site), and try and install it with:

wget http://ftp.uk.debian.org/debian/pool/main/a/awesome/awesome_3.1-1_i386.deb
sudo dpkg -i awesome_3.1-1_i386.deb

However, it will spit out a list of dependencies it couldn’t manage – these are packages that are also outdated in the current Ubuntu repos. So next, fetch the ones you need which are listed below:

wget http://ftp.uk.debian.org/debian/pool/main/x/xcb-util/libxcb-atom1_0.3.2-1_i386.deb
wget http://ftp.uk.debian.org/debian/pool/main/x/xcb-util/libxcb-aux0_0.3.2-1_i386.deb
wget http://ftp.uk.debian.org/debian/pool/main/x/xcb-util/libxcb-event1_0.3.2-1_i386.deb
wget http://ftp.uk.debian.org/debian/pool/main/x/xcb-util/libxcb-icccm1_0.3.2-1_i386.deb
wget http://ftp.uk.debian.org/debian/pool/main/x/xcb-util/libxcb-keysyms0_0.3.2-1_i386.deb
wget http://ftp.uk.debian.org/debian/pool/main/x/xcb-util/libxcb-property1_0.3.2-1_i386.deb
wget http://ftp.uk.debian.org/debian/pool/main/x/xcb-util/libxcb-render-util0_0.3.2-1_i386.deb

Then try and install them all with dpkg:

sudo dpkg -i awesome_3.1-1_i386.deb libxcb-atom1_0.3.2-1_i386.deb libxcb-aux0_0.3.2-1_i386.deb \
libxcb-event1_0.3.2-1_i386.deb libxcb-icccm1_0.3.2-1_i386.deb libxcb-property1_0.3.2-1_i386.deb \
libxcb-render-util0_0.3.2-1_i386.deb libxcb-keysyms0_0.3.2-1_i386.deb

At this point, it might spit out that it needs some extra packages – these are packages that you should just be able to install normally with synaptic or apt: I had to install menu for example,  you may have to install some others as I had a few other dependencies installed from trying to build from source earlier on.  Once you have all the packages, run the above command again to install awesome.

Once awesome is installed, we need a configuration file. A default config file is provided, so go ahead and copy it to your home dir:

mkdir ~/.config/awesome
cp /etc/xdg/awesome/rc.lua ~/.config/awesome/rc.lua

Now we can see if awesome works – kill your current window manager (in my case compiz), then fire up awesome:

killall compiz.real && awesome&

Hopefully everything has gone to plan, and awesome should now be running! Hooray! Have a little play around with it, mess with the config file a bit and see if you like it. Some useful key-bindings are:

• Win + Enter – launch a terminal
• Win + F1 – run a command
• Win + J/K – switch windows (à la vim)
• Win + H/L – resize major/minor divide
• Win + Shift + J/K – move windows
• Win + Space – change layout
• Win + Ctrl + r – restart awesome, for example to update if you change the config file

There are loads more keybindings that you can find/change in the config file if you wanna know what they all do exactly.

If after using awesome for a while you decide you want to keep it, there are a few loose ends to tie up.

Setting awesome as the Default Window Manager

First, fire up gconf-editor:

gconf-editor

On the list on the left, goto:

 desktop > gnome > session

First of all, we’ll get rid of the gnome-panels – awesome already has its own. On the right, there is a name/value pair with name ‘required_components_list’, containing “[windowmanager, panel, filemanager]“. Remove panel, so it becomes “[windowmanager, filemanager]“.

Next we actually tell gnome to load in awesome instead of compiz. On the list on the left, choose the folder required_components. Change the windowmanager field from ”compiz’ to ‘awesome’.

Finally, you’ll probably wan’t to disable nautilus’s desktop (where the desktop icons live etc.) as it can do funny things, and with your magical new tiling windows you will probably never see the desktop. To do this, from the list on the left choose

apps > nautilus > preferences

and when here, uncheck show_desktop.

Now you can kiss sweet goodbye to all the remnants of your old desktop – log out of your system and log back in again to see it take effect. WARNING: If something has gone wrong and awesome doesn’t load (maybe you mispelt it in gconf-editor or something), you should still be able to find a way to edit the gconf preferences, but it took me a while to figure out how to logout when the normal gnome logout button had disappeared. To logout in this situation, type gnome-session-save –kill.

Customising and Configuring

Due to the highly keyboard oriented nature of awesome, you may now want to install a launcher. A couple of good ones are Gnome-Do (if you opt for this, you will have to change the binding from Win+Space in the awesome preferences, or reconfigure awesome’s binding for this combination), an all singing all dancing affair which I used for a while, or dmenu which is quite a lot simpler and I’ve opted for in this case.

To install dmenu:

sudo apt-get install dmenu

Next we setup a keybinding for it to launch in the awesome config file. Underneath the line:

-- {{{ Keybindings

Add (here it is mapped to Win+P – change this if you like):

-- dmenu
keybinding({ modkey }, "p", function () awful.util.spawn("`dmenu_path | dmenu -b`") end):add()

Also, as awesome is aimed at uber geeks the time is displayed by default as…. unix time_t. Unless you’re some kind of magician, hunt down the section in the config file that looks like this, and comment/uncomment accordingly:

-- For unix time_t lovers
--mytextbox.text = " " .. os.time() .. " time_t "
-- Otherwise use:
mytextbox.text = " " .. os.date() .. " "

Finally, I missed my CPU monitor. There is however a set of widgets you can get that adds functionality like this called wicked.

Install wicked:

git clone git://git.glacicle.com/awesome/wicked.git
sudo cp wicked/wicked.lua /usr/share/awesome/lib/
sudo cp wicked/wicked.7.gz /usr/share/man/man7/

in config file, underneath:

-- {{{ Wicked Widgets

Add in:

-- {{{ Wicked Widgets
-- CPU Usage Graph
cpugraphwidget = widget({
type = 'graph',
name = 'cpugraphwidget',
align = 'left'
})
cpugraphwidget.height = 0.85
cpugraphwidget.width = 45
cpugraphwidget.bg = '#333333'
cpugraphwidget.border_color = '#0a0a0a'
cpugraphwidget.grow = 'right'

cpugraphwidget:plot_properties_set('cpu', {
fg = '#AEC6D8',
fg_center = '#285577',
fg_end = '#285577',
vertical_gradient = false
})
wicked.register(cpugraphwidget, wicked.widgets.cpu, '$1', 1, 'cpu')

Then add in the cpugraphwidget into the mywibox[s].widgets line:

mywibox[s].widgets = { mylauncher,
mytaglist[s],
mytasklist[s],
mypromptbox[s],
cpugraphwidget,
mytextbox,
mylayoutbox[s],

For full instructions on how to use wicked, and configure awesome, check out the awesome wiki. Have fun!

I have recently been working on a free cryptic crossword solver to be used by my sister and parents who are fanatics. It is linked to a database of around 250,000 words, with the word list from the UKACD. It lacks a few useful phrases, so if anyone has access to a free cryptic phrase list please let me know in the comments so I can add it to the database.

The solver allows you to get a list of words that match letters and space patterns that you may already have in the crossword, as well as easily get definitions for words. There is also an anagram solver – useful for cryptic crosswords.  It currently needs a bit of a makeover, something I’ll do at some point soon hopefully. Any other suggestions or improvements, let me know!

The gspca drivers are available from here, I was using a specific version dated 20071224 to work with a patch file I found – many thanks to redeye on the QuickCam team forums. If you use a different version of the drivers, you can just examine the patch file and insert the changes manually.

First, download the drivers and the patch:

wget http://mxhaard.free.fr/spca50x/Download/gspcav1-20071224.tar.gz
wget http://forums.quickcamteam.net/attachment.php?aid=86 -O patch.tar.gz

Then extract and apply the patch:

(UPDATE: For Ubuntu 8.10 users, this patch may no longer work. Try downloading the patch here instead, and then extract it using gzip -d gspcapatch.gz. Apply the extracted file in the same was as below, just neglect the -p1 switch, (so do: patch < gspcapatch), you can just ignore the tar -xvf patch.tar.gz command).

tar -xvf gspcav1-20071224.tar.gz
tar -xvf patch.tar.gz
cd gspcav1-20071224
patch -p1 < ../quickcamE2500.diff

There’s a handy build script included with the drivers so just run that (requires root):

sudo ./gspca_build

This generates the file

gspca.ko

which we use to replace the old gspca module.
Check to see if the old module is loaded, you should see something like:

dave@baracus:~$ lsmod | grep gspca
gspca                 680656  0
videodev               29440  1 gspca
usbcore               146028  9 gspca,snd_usb_audio,snd_usb_lib,usb_storage,usbhid,libusual,ehci_hcd,ohci_hcd

We want to find out where it is, so do the following:

sudo rmmod gspca
sudo modprobe -v gspca

You should see something like:

insmod /lib/modules/2.6.24-20-generic/ubuntu/media/gspcav1/gspca.ko

That is the location of the file we’re looking for, so, replacing where appropriate with what was output for you above, type:

sudo rmmod gspca
sudo rm /lib/modules/2.6.24-20-generic/ubuntu/media/gspcav1/gspca.ko
sudo mv gspca.ko /lib/modules/2.6.24-20-generic/ubuntu/media/gspcav1/
sudo modprobe gspca

This should have loaded the new module in place of the old one. See if you have a video device:

dave@baracus:~$ ls /dev/video*
/dev/video0

You can try and run Skype now, and in fact, if you’re not using the camera for Skype, this may well be enough. But for the Skype users: see if you get any picture by testing in the video devices option menu (be warned, it can take a little while to show up there after skype loads, and a little while for the picture to show when you press the test button, so be patient). If anything show’s up at all that’s a plus. (UPDATE: If you’re using Ubuntu 8.10, and have used the alternative patch I posted in the other “UPDATE:” bracket above, the webcam may still not work in Skype at this point. There seems to be some issue with permissions in this version of the driver, so you may need to run skype as root if it doesn’t appear to be working. In a terminal type “sudo skype” and hit enter. It’ll ask for your root password, then launch skype. See if the webcam works now).

Originally, I had a black image, so I assumed the camera wasn’t working, but I soon realised that the image was there, just very dark – shining a light on it showed this was the case. I tried fiddling around with gstfakevideo for a while to try and alter the output, but there was a much simpler solution. The gspca driver itself can take options, and an autoexposure setting was ruining my lighting. To fix this, edit the file /etc/modprobe.d/options, and add a line at the bottom:

options gspca gamma=1 autoexpo=0

The gamma=1 may not be necessary, but if it still appears too dark or too light for your taste you can change this parameter as you like. Finally, reload the module:

sudo rmmod gspca
sudo modprobe gspca

and try out skype again. Hopefully it works!

I ran into quite a lot of other problems while I was trying this out, so if you come across any errors, drop a comment below and I’ll try and get back to you asap.

UPDATE: I found a large problem when using the camera in Skype was that CPU usage would shoot up to 100%, causing things to freeze up and conversations to crash after a while. I had played around with gstfakevideo a bit when trying to get the camera to work originally, and it seems using this when the camera already ‘works’ means it uses up far less CPU. I haven’t had a chance to test it for a long period yet but it seems like it should do the trick. Here’s what I did:

First, download gstfakevideo using subversion (you may need to install the subversion package, sudo apt-get subversion probably does the trick, and then the command below will make a directory called gstfakevideo in your current location, so make sure it’s somewhere nice), then compile and install it:

svn checkout http://gstfakevideo.googlecode.com/svn/trunk/ gstfakevideo
cd gstfakevideo
make
sudo make install

gstfakevideo creates a new video stream using your webcam, which is formatted differently and skype seems to get along with it more. The only problem is, it outputs its stream to /dev/video0 which is where our webcam currently lives. So we have to move the webcam, but this is easy enough:

sudo mv /dev/video0 /dev/video1

(Actually, gstfakevideo seems to work for me with lower CPU without moving this – but try it moved first anyway). Watch out though, every time you reboot, your webcam will probably go to /dev/video0 by default, assuming you have no other video devices, so you will have to move stuff about to make a space in video0 each time. Now we see if it works:

gstfakevideo v4lsrc device=/dev/video1 ! ffmpegcolorspace

What this does is runs gstfakevideo, telling it that the source we’re using is a v4l source, and its from /dev/video1. The ffmpegcolorspace argument seems to be for making the stream YUV instead of RGB for some cameras so may not be necessary. It then launches skype, with hopefully the output below:

dave@baracus:~$ gstfakevideo v4lsrc device=/dev/video1 ! ffmpegcolorspace
gst.c create_pipeline (155): pipeline created
gst.c create_pipeline (159): pipeline linked

If you look in the skype video options now there will be no camera listed. You have to wait a while (it can take 30s or so), until you get some output, ending with something like:

gst.c shim_ioctl (201): request=803c7601 nr 1
gst.c shim_ioctl (208): VIDIOCGCAP
gst.c shim_ioctl (313): result=0 error=0 Success

Now a camera should show up in the video menu in skype, with a name like GStreamer fake video (/dev/video0). Try it out, and compare your CPU performance to before. Also try exiting skype, and moving your video source from /dev/video1 back to video0, and running gstfakevideo again, only with device=/dev/video0, and see if it works (and let me know your findings below!).

Finally if gstfakevideo works, we can clean it up so the command isn’t so long to type. The script should be stored in:

/usr/local/bin/gstfakevideo

(Can check this using):

dave@baracus:~$ whereis gstfakevideo
gstfakevideo: /usr/local/bin/gstfakevideo

So we edit this file (requires root):

sudo gedit /usr/local/bin/gstfakevideo

Now, find the line that looks like this:

export GST_PIPE="videotestsrc is-live=true ! video/x-raw-yuv,width=640,height=480,framerate=10/1 ! videoscale ! ffmpegcolorspace ! vertigotv ! ffmpegcolorspace"

and change it to (remember where you put your webcam source – if you moved it back to /dev/video0, change the device parameter accordingly):

export GST_PIPE="v4lsrc device=/dev/video1 ! ffmpegcolorspace"

and finally look a bit further down, and delete the line:

export GST_PIPE="$*"

Now Skype will launch with your faked video stream, just from the command gstfakevideo. Good luck! Let me know how you get on.

When adding posts to my TiddlyWiki, I oft found myself craving vi, rather than a simple textarea. There were a few options that involved using a plugin for Firefox such as mozEx, and using an external program to edit textareas. However, I found a nice ‘integrated’ option instead.

jsvi is an excellent javascript implementation of vi. I decided to try and integrate it into my TiddlyWiki, and the steps I took are shown below. To try out the final result, use the edit mode on my wiki.

Be warned: this is a bit of a dirty hack, and requires a few files external to the TiddlyWiki file, which makes TiddlyWiki a bit less portable. At some point it’d be nice if this was build as a TiddlyWiki plugin instead, but at the minute I’m not experienced enough with writing plugins for TW. There is also a slight bug which means you can’t scroll up while editing.

First of all, I installed the iFrameEditorPlugin from an old version of the VisualTW site. I don’t think VisualTW uses the plugin anymore, and has instead changed it’s wysiwig editors to using plugins rather than iFrames – a far superior solution, but one I didn’t have the time or ability for. The plugin alone is not quite enough though, and a few changes to it are required.

iFrameEditorPlugin loads an iFrame containing your editor, passes the editor the text from the body of the tiddler, you edit it, and then when you save the page, the plugin gets your changes and saves them to the tiddler. However, it expects you to use a custom field rather than the default text field, which is a slight problem in our case. The function getContent() is what actually performs this:

getContent=function(tiddler, field) {
    var t,f;
    t=store.getTiddler(tiddler);
    f = t ? t.fields[field] : "";
    f = f ? f : "";
    return f;
}

As you can see, it reads the field of the tiddler with t.fields[field]. To read the default text field instead, I added a new function to the plugin:

getContentText=function(tiddler) {
 var t,f;
 t=store.getTiddler(tiddler);
 f = t ? t.text : "";
 f = f ? f : "";
 return f;
}

Great. So that’s set up. There’s also another problem with the plugin – it was originally intended for use with wysiwig html style editors, but I enjoy editing my wiki content raw. Also, the content has to be passed in a URL to the editor, so strange characters in the URL will mess it up, so there were problem with escaping html entities and things like that. To get around this, I found a handy javascript function that converted html entities back to their original form, and added this to the top of the plugin (thanks to The JavaScript Source):

/* This script and many more are available free online at
The JavaScript Source!! http://javascript.internet.com
Created by: Ultimater | http://webdeveloper.com/forum/member.php?u=30185 */
function html_entity_decode(str) {
  var ta=document.createElement("textarea");
  ta.innerHTML=str.replace(/</g,"<").replace(/>/g,">");
  return ta.value;
}

Ok, now we actually have to use this function, so we edit the plugin a bit more. Look for the line that reads the data back from the iFrame:

if(f) fields[f] = e.contentWindow.getContent();

and change it to:

if(f) fields[f] = html_entity_decode(e.contentWindow.getContent());

The plugin is all ready to go now, so we have to make the actual external editor that’s gonna go in the iFrame, using jsvi. Download these three files, and put them in the same folder as your TiddlyWiki html file.

vi.js
vi.css
editor.html

The first two are the actual jsvi javascript file and it’s style sheet, the second is my own editor iFrame. Let’s have a look at the important lines of the editor.html file:

<script type="text/javascript" src="vi.js"></script>

This includes the jsvi javascript file.

<textarea style="width: 99%" name="theEditor" onfocus="editor(this);">
</textarea>

This builds the actual textarea that’s gonna be edited by jsvi. Ok, now the javascript “meat” of the page:

var oEditor = document.getElementsByName('theEditor')[0];
function getContent() {return oEditor.value;}
tiddlers=/[\?&]tiddler=([^&#]*)/.exec(unescape(window.location.href));
fields=/[\?&]field=([^&#]*)/.exec(unescape(window.location.href));
if (tiddlers&&fields) oEditor.value = parent.getContentText(tiddlers[1]);
oEditor.focus();

All that happens here is we write the getContent() function that the iFrameEditorPlugin calls to read your changes. The tiddlers line reads the URL to get which tiddler you’re editing, and the fields line does the same for the field (actually this isn’t even necessary with our getContentText() function). The last two lines read the tiddler’s content, so we can edit it, and set the focus to the textarea to launch jsvi automatically when the iFrame loads.

That’s everything setup now, so all we need to do is tell Tiddlywiki when we want to make our edits with the iFrameEditor instead of with it’s default text field. I made a plugin (based on code from VisualTW’s EasyEditPlugin – thanks a lot!). You can view the plugin here. Hopefully it should add a ‘vi’ button next to the edit button on each tiddler. If no button appears, add ‘jsvi’ to the first line of the ViewTemplate tiddler to look like this:

<div class='toolbar' macro='toolbar closeTiddler closeOthers +editTiddler jsvi > fields syncing ....

To make jsvi the default, remove the + from in front of editTiddler and put it in front of jsvi.

Now when you press the vi button, you should be presented with a rather gorgeous vi interface! One note, when you’re done editing a tiddler with jsvi, you must save it using the usual vi write command, :w, or press the “Save and Close” button. Otherwise the textarea does not get updated, and the iFrameEditorPlugin cannot read your changes. Also beware editing config shadow tiddlers with jsvi, as the line “macro=stuff” in some of the tooldbars etc. is interpreted by jsvi as it’s own command and it can end up destroying certain things.

Update: I found a small problem with focusing using this in Firefox (didn’t test in other platforms) – after editing a post I was unable to select other fields and items in the window. This was fixed by changing one line in the vi.js file, line 3588, which needs to be uncommented (the comment line before even refers to a bug in Firefox, possibly in an older version?) to look like this:

document.body.removeChild(backing);

Now it should work perfectly, apart from a few kinks: being able to edit the tiddler title the first time jsvi launches. Save and close vi, and it’s editable again, and still editable when you relaunch jsvi by clicking on the text area. If you cant get focus back on jsvi, right click it.

Hope you enjoy this as much as I do, and hopefully at some point soon when I have a bit more free time, I’ll have it in plugin format so it’s all incorporated into TW. Any problems, leave a comment and I’ll try and get back to you.

This uses LatexRender, my simple TiddlyWiki macro, LatexRenderPlugin, and a custom script I created for the purpose, render.php, which renders LaTeX fed to it as an argument. You’ll need imagemagick enabled on your server.

First you need access to a server with the ability to run LatexRender. Download the latexrender.zip, and extract the “otherPHP” directory. Copy the class.latexrender.php, and latex.php files to a folder on your webserver. Set up the directories in each file accordingly. For example, I have my wiki set up like so:

webroot/physiwiki/latexrender:
class.latexrender.php
latex.php

and two subdirectories (which the webserver needs write access to, chmod 777):

webroot/physiwiki/latexrender/pictures
webroot/physiwiki/latexrender/tmp

So in class.latexrender.php, I have:

var $_picture_path = "/absolue/path/to/physiwiki/latexrender/pictures";
var $_picture_path_httpd = "/physiwiki/latexrender/pictures";
var $_tmp_dir = "/absolute/path/to/physiwiki/latexrender/tmp";

Also, make sure the paths to latex, dvips, convert, identify are setup correctly on the lines below. You can also make changes to the other settings in this file if you want including image format. The default is gif, I changed it to png.

Now latex.php by default generates the html to show an image, like:

<img src="blah">

We dont want this. So some changes to latex.php are required. First adjust the paths in latex.php:

$latexrender_path = "/absolute/path/to/physiwiki/latexrender";
$latexrender_path_http = ".";

The ‘.’ is used as latex.php resides in the same directory as class.latexrender.php.
Next, scroll right to the bottom of the file, and you can comment out/delete the last few lines, and change the return value to $url instead of $text as below:

    $url = $latex->getFormulaURL($latex_formula);

    /*
    $alt_latex_formula = htmlentities($latex_formula, ENT_QUOTES);
    $alt_latex_formula = ...
    $alt_latex_formula = ..

        if ($url != false) {
            $text = substr_replace($text, "<img src='".$url."' title='".$alt_latex_formula."' alt='".$alt_latex_formula."' align=absmiddle>",$pos,strlen($tex_matches[0][$i]));
        } else {
            $text = substr_replace($text, "[Unparseable or potentially dangerous latex formula. Error $latex->_errorcode $latex->_errorextra]",$pos,strlen($tex_matches[0][$i]));
        }
    */
    }
    return $url;
}

Right, that’s LatexRender all setup. Now we need to make the render.php file. Put the code in a file and save it in the same directory as class.latexrender.php and latex.php.
render.php:

<?
header("Content-type: image/png");
include_once('latex.php');

if (isset($_GET['l'])){

        $text = $_GET['l'];
        $text = stripslashes($text);
        $text = "[tex]" . $text . "[/tex]";

        $latex_img_file = latex_content($text);
        $handle = fopen($latex_img_file, "r");
        $contents = fread($handle, filesize($latex_img_file));
        fclose($handle);

        echo $contents;
}
?>

Obviously change the header function to match the content type you specified in class.render.php. This file accepts LaTeX formula code as an argument render.php?l=<formula>, puts it between [tex] tags so it can be messed around by latex.php and then renders it as the image file.

Now all that is left is to incorporate this into TiddlyWiki, using a simple macro. (Just change the src= section to match the location of your script):

config.macros.tex = {};
config.macros.tex.handler = function (place,macroName,params,wikifier,paramString,tiddler) {

     var code = encodeURIComponent(params[0]);
     wikify("<html><img class="teximg" title="" + params[0] + "" src="latexrender/render.php?l=" + code + ""></html>", place);

}

To use this plugin just call it like so:

<<tex 'int_{-5}^{5} x^2 dx'>>

For some rendered examples just browse my wiki!
The macro also gives all equations the “teximg” css class, so they can be adjusted to be inline “nicely”, using the following CSS in the StyleSheet tiddler:

.viewer {line-height: 2.0 ;} .viewer img.teximg { vertical-align: middle;}

Hopefully you’ll now have easy LaTeX macro’s working on your TiddlyWiki! Any problems just leave me a comment.

Turns out I wasn’t the only one with the problem, and I found a solution here. (Thanks to wieman01 on the Ubuntu forums for this.)

What was happening was Ubuntu’s power management was a bit over zealous and was making the hard drive spin up and down far too often. By changing the power settings this can be fixed, using the command:

hdparm -B 254 /dev/xxx

replacing xxx with your drive name, in my case for my SATA drive it was /dev/sda.

254 here is the lowest level of power management, and 255 is off completely. You can try playing with higher values if you like some kind of power management.

To make this run every time the computer starts, add it to a startup script. For example, save a plain text file containing the above line to:

/etc/init.d/local_settings

Then:


cd /etc/init.d
sudo chmod +x local_settings
sudo ln -s local_settings /etc/rc2.d/S99local_settings


This makes the file executable, and creates a symbolic link to it in the folder which contains the start-up scripts, giving it priority 99.

Hopefully your clicking noise will now be gone!