I spend most of my day switching between languages. Sometimes I start the morning with an early dose of LUA, then I get a lot of Python and C++, followed by the yummy dessert that is Node.js. But there’s always room for PHP. So let’s talk about PHP today.

People often think that when you are coding PHP you have to do things “the PHP way”. Well, let me clear it up for you: there’s no such thing as “the PHP way”. If there’s something that defines PHP is its flexibility to be as ugly or as beautiful as you want it to be. With that in mind, what prevents you from taking the lessons learned in one language to another?

That’s the premise I always have when I’m coding. Let me give you a for instance. On Node.js, I normally use express.js as a framework. Check it out, it’s pretty awesome. One of the things I love in express.js, is its route middleware capabilities. When I code in any PHP framework, that’s one of the things I miss the most.

Not many PHP frameworks are flexible enough to support such concepts. One of them is, though. Lithium has many of the things I love about PHP (5.3+ obviously, as I consider anything < 5.3 a waste of my time lately), and some of the things I love about other languages. One of them is Lithium’s addiction to closures. I love it. They allowed me to take the concept of express.js’ route middleware and apply it to my PHP code.

Let’s start with a dummy application skeleton. A users table:

CREATE TABLE `users`(
    `id` INT NOT NULL AUTO_INCREMENT,
    `email` VARCHAR(255) NOT NULL,
    `password` VARCHAR(255) NOT NULL,
    PRIMARY KEY(`id`)
);

INSERT INTO `users`(`email`, `password`) VALUES(
    'test@email.com', '$2a$04$U7qYPVYq2YBxqfHL8F2pteERxQYwLTVtAjMIh48Lef9sLSiMVtGHy',
    'john@email.com', '$2a$04$U7qYPVYq2YBxqfHL8F2pteERxQYwLTVtAjMIh48Lef9sLSiMVtGHy'
);

In your app/config/bootstrap/connections.php, make sure you uncomment the default database and hook it up to the database owning the table we just created. We’ll also be using sessions, so uncomment the session.php reference in app/config/bootstrap.php. You may have noticed that our initial users have a password set to a specific value, which means a specific salt was used (the password hashed there in plain text is ‘password’, minus the quotes.). So go ahead and add the following to your app/config/bootstrap/session.php file:

use lithium\security\Auth;
use lithium\security\Password;

$salt = '$2a$04$U7qYPVYq2YBxqfHL8F2pte';
Auth::config(array(¬
    'adapter' => 'Form',
    'model' => 'Users',
    'filters' => array('password' => function($text) use($salt){
        return Password::hash($text, $salt);
    }),
    'validators' => array(
        'password' => function($form, $data) {
            return (strcmp($form, $data) === 0);
        }
    ),
    'fields' => array('email', 'password')
));

The salt was generated with a call to \lithium\security\Password::salt('bf', 4). I always use blowfish for password hashing (and 2^16 iterations in production). If you don’t use blowfish, here’s why you should. Anyway so you may want to store the hash on a better, configurable approach. I opted for a simple variable for this example. Once the salt is defined, I went ahead and configured Auth to use lithium’s Password::hash() method for hashing using the generated salt, and telling it how to compare hashed passwords against the database value. Pretty simple.

Let’s now build the Users model. It won’t have anything in there, really. So just create your app/models/User.php file with the following contents:

<?php
namespace app\models;

class Users extends \lithium\data\Model {
}
?>

Now the controller. Create a file named app/controllers/UsersController.php with the following contents:

<?php
namespace app\controllers;

use lithium\security\Auth;

class UsersController extends \lithium\action\Controller {
    public function login() {
        if (!empty($this->request->data)) {
            $user = Auth::check('default', $this->request);
            if ($user) {
                $this->redirect(array('action' => 'view', 'id' => $user['id']), array('exit' => true));
            }
        }
    }

    public function logout() {
        Auth::clear('default');
    }
}
?>

Nothing really complicated there. Don’t forget the view in app/views/users/login.html.php:

<?php
echo $this->form->create();
echo $this->form->field('email');
echo $this->form->field('password', array('type' => 'password'));
echo $this->form->submit('Login');
echo $this->form->end();
?>

That should give you a working login / logout. Add some dummy actions to the UsersController.php file:

public function view() {
    echo 'view';
    $this->_stop();
}

public function edit() {
    echo 'edit';
    $this->_stop();
}

Ok now we are ready to play with some route middleware. What we want to achieve is the following:

• No action named edit, on any controller, should be accessible without a logged in user.
• When accessing either the Users::edit or Users::view action, there should be an ID specified as a route parameter, and it should match an existing User record.
• When accessing the Users::edit action, the given user should match the currently logged in user.

These are pretty basic security checks that you would normally put on the controller. Not this time. Edit your app/config/routes.php file and add the following right below the use statements found at the beginning of the file:

use lithium\net\http\RoutingException;
use lithium\action\Response;
use lithium\security\Auth;
use app\models\Users;

These are all classes that we will use in our route middleware. Let’s start with the first checkpoint we want to achieve: “No action named edit, on any controller, should be accessible without a logged in user“. Add the following to the routes.php file, below the content we just added:

Router::connect('/{:controller}/{:action:edit}/?.*', array(), array(
    'continue' => true,
    'handler' => function($request) {
        if (!Auth::check('default')) {
            return new Response(array('location' => 'Users::login'));
        }
    }
));

The first parameter (continue) ensures that this route definition is treated as a continuation route. This is because we don’t want to interrupt any normal route / parameter processing in this definition. We just wanna “grab” all calls to any edit action, and check (using Auth) for a valid user. If none is found, we process the request by returning a Response, which in the end redirects the user to the login page. If there is indeed a logged in user, the router will continue looking for other route definitions to match the request. So now all edit actions require a logged in user. Cool.

Next in our list: “When accessing either the Users::edit or Users::view action, there should be an ID specified as a route parameter, and it should match an existing User record.” Add the following to the routes.php file, below the content we just added:

Router::connect('/{:controller:users}/{:action:edit|view}/{:id:\d*}', array('id' => null), function($request) {
    if (empty($request->params['id'])) {
        throw new RoutingException('Missing ID');
    } elseif (!Users::first(array('conditions' => array('id' => $request->params['id'])))) {
        throw new RoutingException('Invalid ID');
    }
});

We are now getting more serious. In this definition, we are only matching the Users controller, and actions named either edit or view, which may or may not contain an id parameter. The route handler first checks to make sure the id parameter is given (if not, a RoutingException is thrown.) If the parameter is specified, it is used to find a matching User record with the given ID. If none is found, yet another RoutingException is thrown (you may wish to do something different here, like ensuring a 404 status). If the user is found, the route is not handled, which means some other route definition will handle it (the default route, in this case.)

The final checkpoint we have is: “When accessing the Users::edit action, the given user should match the currently logged in user.” So add the following to the routes.php file, below the content we just added:

Router::connect('/{:controller:users}/{:action:edit}/{:id:\d+}', array('id' => null), function($request) {
    $user = Auth::check('default');
    if ($user['id'] != $request->params['id']) {
        throw new RoutingException('You can only edit your own account');
    }
    return $request;
});

This defines a specific match to the Users::edit action with a set id parameter. We use that parameter to make sure it matches the ID of the logged in user. If it doesn’t match, we throw a RoutingException. If it does match, we return the request as we have successfully processed it.

You can now try accessing the edit and view actions using different scenarios: with a logged in user, while being logged out, editing a user which is not the current logged in user, etc. Everything should be nicely protected. And yet our controller code remained untouched. Nice, huh? That’s routing middleware for you.

Just a few days ago, I was happy to see my first book published. Entitled CakePHP 1.3 Application Development Cookbook, it’s a book released in the form of a cookbook, with a series of solutions to common problems one faces when developing CakePHP applications.

While working on it, I tried to aim for developers at different levels of knowledge, yet a disclaimer has to be made: this is not a beginners book. It will not teach you how to install CakePHP, or how to get its friendly URLs working on Microsoft platforms (dodged that bullet.) It is written for CakePHP developers that are looking to solve different problems, and leverage their own applications. So no “building a blog” chapter in this book.

There are some recipes that deal with more complex topics, while others deal with what I consider interesting solutions to simple problems. Each recipe starts by proposing a problem, showing the solution, and giving an explanation of how the solution works. Most of the recipes include alternatives and extend the topic at hand beyond the scope of the problem they are solving, and some of them are based on open source packages that CakePHP community members (myself included) released.

This book also benefited from an unbelievably, super-cool, top of the world team of technical reviewers (the CakePHP 1.3 lead developer happens to be amongst them) that made its code shine (I am known for being humble.) They improved each recipe and proposed awesome alternatives to my original ideas. Because of that, this blog post is being written. I’m not sure sure I would’ve been as proud of the original version of the book

You should also know that the publishing company behind the publication of this book, Packt Publishing, is donating an important portion of the book earnings to the Cake Software Foundation, which is like The Force behind CakePHP. So I might not get rich, but at least the foundation will get some beers out of each sale. And trust me, nothing says thank you like a beer.

If you bought the book, I welcome any feedback you may have (you could also leave a review and tell others how super cool the book is.) If you are more of a bytes person and less of a paper person, and look forward to reading the digital version, you can also get the ebook.

If you program in Python and you are building web clients you need to know about Twisted. It is perhaps the most flexible and powerful Python framework for building web clients and servers, and has been proven to work wonderfully under heavy loads. So powerful, that the most basic tasks tend to be a bit of a pain. This is what I realized when I found myself in the need to upload large files to a web site using Twisted. I googled, and I googled, and I found no real answer to my problems.

You can of course find an easy solution: build a multipart request by building the request body yourself out of the files you are trying to upload. Sure, that works. But what happens when you are dealing with a 50 MB file upload? What about 500 MB? I’m sure you are not planning to encode the whole file as a string, right?

This is where Twisted’s body producers come handy. Implementing your own body producer, you have total control on how to build the request. In fact, Twisted will call you every time it needs data for the request, so you can be sure you won’t be building the whole chunk in one string. Instead, you will be sending chunks of bytes to what is known as the consumer. What is the consumer? Whatever is asking for a request body.
Continue Reading »

This post aims to be a very basic introduction to the world of Lithium, also known as li3. As such, it is mostly based on the ubiquitous blog sample. The idea is to learn, through the source code, the basic notions on Lithium and its integration with the Doctrine ORM mapper to build a very basic blog application. Unlike the blog example at rad-dev.org, this example is based on Doctrine 2.0, which is (at the time of this writing) in Alpha stage, and is built for PHP 5.3. After this tutorial, you should be able to jump start and build your own li3 powered applications.

Before we proceed, a disclaimer. This tutorial shows a rather quick and dirty integration with Doctrine (as you’ll see it’s all mostly done in a base model class), while the most clean approach would be to implement all this as an extension, using Datasources and Query parsing. I’m happy to say this is all being done as we speak (thanks kuja!), so very soon you’ll find an even better approach to Doctrine integration.

Continue Reading »

With the release of CakePHP 1.2 a whole set of new features were made available to us bakers. One of those features is custom find types, which is one of the coolest things that ever happened since I realized I was cooler than Maverick.

I’m not gonna go through custom find types, you can find more info about them at Matt’s blog, or at this article written by someone whose name I think I’ve heard somewhere. What I’m going to talk about is how to mix your custom find types with pagination, without having to use paginate and paginateCount in your models.

So let’s first start by building yet another posts table, and inserting some records:

CREATE TABLE `posts`(
	`id` INT NOT NULL AUTO_INCREMENT,
	`title` VARCHAR(255) NOT NULL,
	`body` TEXT NOT NULL,
	`published` TINYINT(1) NOT NULL default 0,
	`created` DATETIME,
	`modified` DATETIME,
	PRIMARY KEY(`id`)
);

INSERT INTO `posts`(`title`, `body`, `published`, `created`, `modified`) VALUES
	('Post 1', 'Body for Post 1', 1, NOW(), NOW()),
	('Post 2', 'Body for Post 2', 0, NOW(), NOW()),
	('Post 3', 'Body for Post 3', 0, NOW(), NOW()),
	('Post 4', 'Body for Post 4', 1, NOW(), NOW()),
	('Post 5', 'Body for Post 5', 1, NOW(), NOW()),
	('Post 6', 'Body for Post 6', 0, NOW(), NOW()),
	('Post 7', 'Body for Post 7', 1, NOW(), NOW()),
	('Post 8', 'Body for Post 8', 1, NOW(), NOW()),
	('Post 9', 'Body for Post 9', 1, NOW(), NOW());

Now let’s assume we want a find type called published to fetch only the published posts, and that we also want to be able to paginate using this find type. We will be approaching this through a generic approach, something that can be used throughout all our models. With this in mind, let’s first introduce a model based member variable called $_types, where we define the specific needs of each custom find type. Therefore, that variable will hold what we need as conditions, order, etc. for each custom find type. So let’s build our Post model:

<?php
class Post extends AppModel {
	public $name = 'Post';
	protected $_types = array(
		'published' => array(
			'conditions' => array('Post.published' => 1),
			'order' => array('Post.created' => 'desc')
		)
	);
}
?>

As you can see, we define options for each find type as if we would be calling find() directly. So with the above, instead of doing:

$posts = $this->Post->find('all', array(
	'conditions' => array('Post.published' => 1),
	'order' => array('Post.created' => 'desc')
));

We can now do:

$posts = $this->Post->find('published');

Now, what if we wanted to paginate with the above custom find type? Just as we set pagination parameters through the controller member variable $paginate, we can specify which find type pagination we’ll use. We do so by specifying the find type in the index 0 of the pagination settings. Like so:

$this->paginate['Post'] = array(
	'published',
	'limit' => 10
);

$posts = $this->paginate('Post');

Easy, huh? When this is specified, paginate() does the following:

1. It issues a find('count') on the Post model, specifying the custom find type (published) in the $options array, through an option named type. Therefore, we can use $options['type'] when our model is about to do the count to use the given options for our custom find type.
2. It fetches the records by calling find() with the custom find type, find('published') in our example.

So where’s that sexy code? Add the following in your AppModel, making the above available for all our models.

<?php
class AppModel extends Model {
	public function find($type, $options = array()) {
		if (!empty($this->_types)) {
			$types = array_keys($this->_types);
			$type = (is_string($type) ? $type : null);
			if (!empty($type)) {
				if (($type == 'count' && !empty($options['type']) && in_array($options['type'], $types)) || in_array($type, $types)) {
					$options = Set::merge(
						$this->_types[($type == 'count' ? $options['type'] : $type)],
						array_diff_key($options, array('type'=>true))
					);
				}
				if (in_array($type, $types)) {
					$type = (!empty($this->_types[$type]['type']) ? $this->_types[$type]['type'] : 'all');
				}
			}
		}
		return parent::find($type, $options);
	}
}
?>

Now ain’t CakePHP great? Don’t tell me, tell everyone at CakeFest #3.

Today I noticed my MySQL partition was taking over 86 GB of the available 120 GB. So I got worried and I wrote this little script to tell me how much space each DB I have is taking:

<?php
function format($size) {
	$unit = 'B';
	$units = array(
		'GB' => 1024 * 1024 * 1024
		, 'MB' => 1024 * 1024
		, 'KB' => 1024
	);

	foreach($units as $currentUnit => $value) {
		if ($size > 2 * $value) {
			$size /= $value;
			$unit = $currentUnit;
			break;
		}
	}

	return number_format($size, 1) . ' ' . $unit;
}

$settings = array(
	'host' => 'localhost'
	, 'user' => 'root'
	, 'password' => 'password'
);

$databases = array();

mysql_connect($settings['host'], $settings['user'], $settings['password']);

$result = mysql_query('show databases');
while($row = mysql_fetch_array($result)) {
	$databases[] = $row['Database'];
}

foreach($databases as $database) {
	$sizes[$database] = 0;

	mysql_select_db($database);
	$result = mysql_query('show table status');
	while($row = mysql_fetch_array($result)) {
		$sizes[$database] += $row['Data_length'] + $row['Index_length'];
	}
}

mysql_close();

foreach($sizes as $database => $size) {
	echo $database . ' = ' . format($size) . '<br />';
}

echo '<br />TOTAL: ' . format(array_sum($sizes));

?>

When I ran it, I saw all my DBs where taking a total of 10.8 GB, much less than the 86 GB occupied in the partition. So it hit me, it has to be the binary logs, a set of files that store log events (more about them here). Indeed, if you would list the contents of /var/lib/mysql I would find a ton of .bin files, a lot of them as old as from 2007. Therefore, I realized I had to flush the logs.

In order to flush the binary logs, I logged in to the MySQL console as an administrator, and issued (if you are on a server with replication, you want to purge the binary logs instead):

FLUSH LOGS;
RESET MASTER;

After doing so, the MySQL partition is now taking a total of 12 GB. Much better!

As a true programmer, I need fun projects to stay alive. Don’t get me wrong, my client work fulfills me, and eventhough I’ve been slacking lately in keeping up with its workload, CakePHP is also a lot of fun. However, true programmers are always looking for a fun project, one they can call their own. Meet CLAPP, a C++ MVC Web Framework.

I am not even close to finishing it, but so far I’m having LOTS of fun. What is amazing is that missing only the M in MVC (the database abstraction layer), CLAPP’s performance is already astonishing. Running as FastCGI, it outperforms the most basic PHP file by a ratio of 1000%. Amazing.

So what am I looking to gain from this? Nothing, just having fun going back to my absolute favourite language: C++. In the meantime, I get to play with speed comparisons, which gets particularly interesting as I enable more stuff in the framework. My ideal goal is to include a lot of the you-just-have-to-have-this kind of things available on real, serious frameworks such as CakePHP. This doesn’t mean that I will hereon start developing every web application in C++, that would just be dumb (if you are asking why, then that’s because you haven’t given CakePHP a try). It does mean, however, that I’ll be posting about CLAPP every now and then.

To calm your expectations, here’s a very, VERY small preview of the Dispatcher, which is directly attached to every controller:

#ifndef __CLAPP_DISPATCHER_HPP
#define __CLAPP_DISPATCHER_HPP

#include <clapp/cgi_stream.h>
#include <clapp/controller.h>

namespace clapp {
	template <class C>
	class Dispatcher {
		public:
			Dispatcher();
			~Dispatcher();
			void dispatch();

		private:
#ifdef CLAPP_WITH_FASTCGI
			CgiStreamFastCgi * cgiStream;
#else
			CgiStream * cgiStream;
#endif

			void execute();
	};
}

template <class C>
clapp::Dispatcher<C>::Dispatcher() {
#ifdef CLAPP_WITH_FASTCGI
	this->cgiStream = new CgiStreamFastCgi();
#else
	this->cgiStream = new CgiStream();
#endif
}

template <class C>
clapp::Dispatcher<C>::~Dispatcher() {
	delete this->cgiStream;
}

template <class C>
void clapp::Dispatcher<C>::dispatch() {
#ifdef CLAPP_WITH_FASTCGI
	FCGX_Request request;

	FCGX_Init();
	FCGX_InitRequest(&request, 0, 0);

	while (FCGX_Accept_r(&request) == 0) {
		this->cgiStream->setRequest(request);
		this->execute();
		FCGX_Finish_r(&request);
	}
#else
	this->execute();
#endif
}

template <class C>
void clapp::Dispatcher<C>::execute() {
	C *controller = NULL;

	try {
		controller = new C();

		controller->setStream(this->cgiStream);
		controller->dispatch();

		delete controller;
	} catch(...) {
		if (controller != NULL) {
			delete controller;
		}
		throw;
	}
}

#endif

As you can guess from the source code, CLAPP can produce FastCGIs and regular CGIs. It uses ClearSilver for its view / layout templates, the FastCGI development kit (when FastCGI mode is enabled), and GNU cgicc as a CGI / FastCGI input wrapper. More news coming soon!