Issue 1: Browser cache

As you know, visitors to a site would get served the latest version of a file only if it already doesn’t exist in the local browser cache (or the local copy is old enough to expire). So only a first-time visitor would surely get the latest CSS version, but what about returning visitors? I needed to make sure they get the new CSS file without having to manually hard-refresh their browser. This is where the CSS timestamp technique comes into place.

Issue 2: Continuous updates

In any future updates of the CSS file, I would need to change the timestamp each time, which brings in a bit of inconvenience. This is where generating an automatic timestamp on file change comes in quite handy, if not priceless.

Issue 3: Updating the Thematic stylesheet call function

The site used Thematic as a base parent theme, and the child theme of the site contained just a few files – an index.php file, a css file, a functions.php file, and an /images folder. This is the beauty of child themes introduced recently in WordPress – you can base your theme on an existing one and add only the files you need to change in your child theme folder. As opposed to directly changing the main theme, this technique protects your changes from any future updates of the main theme, which would overwrite your changes. By using a child theme you effectively preserve your changes in a separate theme folder.

However this also prevents you from directly editing PHP code that includes the stylesheet without adding too much excess code. This is where we will use WordPress filters to do the task.

Now let’s see the solutions to these issues.

Solution to issue 1 (Browser cache)

Here is how a normal call to a CSS file looks like in HTML:

<link href="style.css" type="text/css" rel="stylesheet" />

As mentioned before, an elegant solution to the browser cache issue is appending a unique string to the filename call as a parameter passed on to the CSS file:

<link href="style.css?some_unique_string" type="text/css" rel="stylesheet" />

Usually a version number is used, e.g.:

<link href="style.css?ver=12" type="text/css" rel="stylesheet" />

or a date:

<link href="style.css?20100829" type="text/css" rel="stylesheet" />

The idea is generally the same. CSS does not make use of that parameter, but the browser gets tricked that you’re making a call to a different file (due to the different value of the href attribute), so it downloads it from the server. Voila!

Solution to issue 2 (Continuous updates)

Applying the CSS timestamp trick is great, but leaves room for error. Sometimes I might forget to change the version / timestamp, or I may just get tired of constantly changing it. This is why the solution I found published here really made my day. What it does is automatically append a unique number based on the actual date / time the CSS file was changed on the server by using a PHP function ( filemtime() ) to check for it.

Here is how a line of HTML/PHP code using this method would look:

<link href="style.css?<?php echo filemtime('/server/path/to/css/file/style.css'); ?>"

 rel="stylesheet" type="text/css" />

This will result in a unique number appended to the CSS call each time the file is changed. No more need to worry you forgot anything.

Solution to issue 3 (Tinkering with the CSS call function in Thematic)

I opened the header.php file of the Thematic parent theme to see how the CSS file is being included. I only saw a bunch of PHP functions being called, going like this:

    // Creating the doctype
    thematic_create_doctype();
    echo " ";
    language_attributes();
    echo ">\n";

    // Creating the head profile
    thematic_head_profile();

    // Creating the doc title
    thematic_doctitle();

    // Creating the content type
    thematic_create_contenttype();
...

Not a line of HTML. But I noticed one of the functions was this:

    // Loading the stylesheet
    thematic_create_stylesheet();

It would obviously take care of inserting the stylesheet. A short run through the Thematic file structure showed this function was defined in /wp_thematic_folder /library /extensions /header-extensions.php:

// Located in header.php
// creates link to style.css
function thematic_create_stylesheet() {
    $content = "\t";
    $content .= "<link rel=\"stylesheet\" type=\"text/css\" href=\"";
    $content .= get_bloginfo('stylesheet_url');
    $content .= "\" />";
    $content .= "\n\n";
    echo apply_filters('thematic_create_stylesheet', $content);
}

It clearly shows how the HTML code for including the CSS file is built and assigned to a $content variable. What I needed is to change the output of this function. I accomplished that by adding a filter that would replace the output of the existing thematic_create_stylesheet() function with what I need. Adding a filter is easy – just edit the functions.php file of your theme (in this case – the child theme). This is how it looks:

function timestampCSS($content) {
    $content = "\t";
    $content .= "<link rel=\"stylesheet\" type=\"text/css\" href=\"";
    $content .= get_bloginfo('stylesheet_url');
    $content .= '?' . filemtime( get_stylesheet_directory() . '/style.css');
    $content .= "\" />";
    $content .= "\n\n";
    return $content;
}
add_filter ('thematic_create_stylesheet', 'timestampCSS');

What I did was create a new function ( timestampCSS() ) which would return the output I need, and then hook it as a filter to the old function ( thematic_create_stylesheet() ), so that each time the old function is executed my new function will be, too. The last line ( add_filter() ) effectively tells WordPress to use the output of timestampCSS() instead of the one of thematic_create_stylesheet().

So this is how you can use a combination of handy techniques to make your work on styling Thematic a bit less tedious and make it work independently of the updates of the parent theme.

The recipe

Here are the ingredients we have:

1. client: students startup
2. application: online store
3. product: customizable male and female business shirts
4. no flash
5. budget: limited
6. materials: none
7. deadline: tight
8. expectations: high

So, we have to mix all these and get something delicious in the end.

The online store app

Since the whole site has to be clean and straightforward, we decided it would be best to design it from scratch using CakePHP instead of trying to bend any existing open-source solution. We don’t need all the stuff ZenCart provides but we need that shirt builder which we can hardly implement into any OSS shop.

Raw materials

None. The client didn’t have any materials to provide us with except for some low-resolution, all-messed-up pictures from their shirt-sewing factory. They didn’t have time or budget for 3D modeling (which could prove to be quite fancy and realistic) and we had to

Photoshoot

We hired this fella for the project and I think he did quite well.

The pictures don’t look fancy (to me) but I was amazed what good job they did for us.

Customizable Product Visualization Technology

For the shirt builder we needed a solution which would allow us to generate images on the server so that we don’t have to create all the gazillion possible visualizations. We had to be able to “apply” all fabrics to all shirt elements ( fit, sleeves, cuffs, etc ). And the client wanted a fast and smooth experience for the end-user with no Flash!

We came up with the idea to create a mask for all shirt elements like in photoshop, use it to “cut out” the fabric in the particular shape and then add another layer which would represent shades and folds.

WideImage was chosen for the server processing part. However, it turned out we were jumping in the dark.

Fabric material

Well, ok, I lied – the client gave us some picture of the fabrics they wanted to use. They were good enough and after some processing we got this

We had to make a canvas and tile that image in there. That was an easy task for WideImage.

We first load the fabric image and resize it on the fly – otherwise it would look too big on the final image. We then create the canvas and fill it with repeating instances of the fabric image – finally, cut out a shirt shape.

But we have a small problem here – we need to add the layer for folds and shades now and with this approach it has to reside in a separate file. That’s not elegant enough…

We came up with the idea to

combine the image mask and folds layer into one file

How to do that? We use the RGB channels of the image to hold the mask and the alpha channel to hold the folds and shades layer. This way we can have just one file to hold all the information we need to generate our image.

Performance

Nothing is as easy as it sounds. WideImage has some wonderful methods like getChannels() to get the RGB and alpha channels into different image resources and applyMask() to cut out the shirt element shape from the fabric-tiled canvas but these come with enormous performance hits. Unfortunately, PHP and GD2 do not offer native functions for these tasks and WideImage uses “for” loops to go through all pixels of the image to do the necessary processing. So, the algorithm goes like that

1. go through the image pixel by pixel go get its RGB channels and alpha channels and store them in different image resources (mask and folds layer)
2. once again go through the mask image (which has same size) pixel by pixel to cut out the fabric canvas
3. apply the folds layer on top of the cut out image

This averaged at 8 seconds on our server for a 350×500 image!

Cache

We decided we could use some caching which would save us troubles – we calculate we would need around 1GB of space for that cache which is not a big deal but 8 seconds is still a monster.

Solution

We came up with a solution which was similar to what WideImage does but we now do all the processing in a single for loop which saves quite a lot of time. We managed to keep the figure down to 2-3secs for an uncached image which is bearable. In he end the image looks like that

This is still a work in progress and we need a few more things to enhance, so if you have any suggestions, go ahead and shoot!

Update: We launched the website some time ago. Here are some final images:

Smooth background image swap – jQuery Background-Image Transition Plugin

I will show you an example right now, so you know what I am talking about.

Here is a working example

What we basically do is:

1. Create an additional hidden <div> element on top ( using z-index ) of the element we want to animate
2. Load the new image in the in the cache in the background, so that the effect is smooth
3. Set the new src to the new <div> element
4. fadeIn() the new <div> element so that it creates the illusion that the background image of our initial div is smoothly changing
5. Optional step – if we need to change the image once again, go from 2 to 5 but setting the new src to our initial <div> and then using fadeOut() on the new element, so that it disappears and the new image is set as background to the old <div>. This way we won’t have an infinitive increase of the z-index and won’t actually change the z-index of the initial <div>

OK, let’s get to work, we will start with the HTML markup:

<div id=”backImage”></div>

Well, that was pretty easy: we have a simple <div> element with some demo text and just next to it we add that additional <div> which we will need for the animation.

So, here is the CSS:

#backImage {
    z-index: -2;
    height:600px;
    width:800px;
    background-image: url('path/to/initial/img');
}

We just set a height and width of the element so that we are sure the image will actually be shown. It is generally a good idea to have the z-index set to a negative number while other elements have a greater z-index value.

We will use jQuery’s Background-Image Transition Plugin for our example.

First, add jQuery and the plugin

<script lang=”Javascript” src=”path/to/jQuery.js” type=”text/javascript”> </script>
<script lang=”Javascript” src=”path/to/jQuery.bgImageTransition.js” type=”text/javascript”> </script>

Then, at the end of the document, add the following lines:

jQuery( function(){
    jQuery('#backImage').bgImageTransition( 'path/to/new/image', {
        duration: 'slow',
        easing: 'linear',
        helperElementId: 'backImage2',
        zindex: -1
        callback: function(){
           //do sth
        }
    });
});

The only mandatory argument is the path to the new image. The optional second argument is an object holding some tweaks. You can set the desired duration, easing, helperElementId ( which is generated by the plugin ), z-index of the helperElement ( by default it will take the selected element’s zindex and increment by 1 ) and a callback function in case you want to execute some functionality when the transition is over.

Adobe Flash is no doubt a favorite tool for a lot of web front-end developers and designers. It is widely supported on a variety of platforms and browsers and features a rich and cohesive set of tools and instruments. Some people even say it is the next evolutionary step of the Web.

Why not then?

Even though Flash is great, it has its drawbacks ( of course, I wouldn’t be writing this blog post otherwise ). Here I am talking about a completely Flash made website, not just small fragments of it.

• It is extremely SEO unfriendly. Although Google stated back in the middle of 2008 that they have improved readability of Flash sites, this still isn’t enough compared to a well-made HTML website.
• There are no links. If you want to send a link to a friend – no dice. If Google actually learns how to crawl such websites, what links is the crawler going to give? There is only one URL in such a site – the domain name. Best case scenario in Google listings would be a single-page website with a lot of heterogeneous information
• The web is all about content over design not vice versa. Traditional technologies today are so good that what people usually do with Flash ( and can’t with other stuff ) is make something which looks more like an art gallery than a website. This is extremely counter-productive for any business – end-users visit a site not to experience eye-candies but to get some content. Just like a fashion review – you need to pay attention to the clothes, not to the models. The focus should stay on the content and not on the decoration. Period.
• Browsers are not really made for that. Yes, you know what I am talking about – when I go to a site and have to wait 7-10 secs just for the Flash to load and then start-up, this makes me a bit nervous. And as I have previously stated on this blog, loading time is crucial for web visitors. Each second can be costly.
• Background music. Well, OK, it may be just me but I hate background music. Yes, I can stop it but I didn’t want it in the first place! I have 10 tabs running right now and I really don’t want some strange music streaming from somewhere without even notifying me. Yes, this is not just a Flash flaw but it looks like it is easy enough for Flash designers to get tempted by this option.
• “Let’s reinvent the web!” Hmmm… this sounds a bit like Microsoft but it is actually Adobe trying to do it. Correct me, if I am wrong, but isn’t “flashy” a bad term for a website? You get crazy, incoherent navigation, strange things popping out of nowhere, all kinds of elements moving, resizing and changing shapes all over the place. Long live vector animation! But wait, where did the visitor go… ?

I am sure you can think of many more reasons not to prefer Flash but these were my top list. These are also not too technical – we could talk about inter-compatibility with other technologies for too long.

Enough ranting already – I will show you some tricks which can make Flash history. Our goal is to create a website which is both visually compelling and SEO-friendly – a simple 5-pager with some help from PHP.

Back to basics

Good ‘ol Javascript. It needs some polishing from a well-known library, of course – otherwise you risk banging your head against the wall for some time. In short, we will use traditional html + css + javascript technology which will help us get some really nice effects. We will then add some nifty AJAX to maintain a good and flowing experience for the user but still making a SEO-friendly site with active links and most importantly – a graceful degradation. If the visitor is using a stone age computer without JS support ( or is simply using some JS blocking browser extension ), they will still be able to get to the content. They won’t experience all the sweetness but they will get what they wanted after all – the content.

Javascript Libraries

You can find tons of them out there. I have personally used PrototypeJS and jQuery but have had a good look at YUI, MooTools and Rico, too. Good things are told about Dojo, but I haven’t really looked into it. Some time ago jQuery was much lighter than PrototypeJS and that made many people switch. Today the difference is not so great as jQuery can get down to ~18k and PrototypeJS to ~20k ( gzipped and minified ) but let’s not forget that PrototypeJS’ effects’ library Scriptaculous ( scriptaculous and effects only – no builder, slider, sound, controls and drag&drop ) add another 15k. So, jQuery turns out to be twice lighter.

So, I chose

jQuery

Go get the most recent version from here. The version I am going t use is 1.3.2  as it is the most recent right now. And some additional plugins – we will talk more about them later but I can recommend Color, Timers and fxQueue. The first one gives you the ability to smoothly change colors ( including background and border ) of elements via animate(). I am taking a minimalistic approach and some may argue that the Color plugin is not that much needed, but if we want some candies, we’ll have to use it. The Timers plugin is not an overkill either – it is a nice wrapper for setTimeout() and setInterval() and does some good garbage collection so that no memory leaks from the browser. You can, of course, use a variety of great plugins from jQuery’s plugins’ repository.

And because this post is getting too long, I will begin with the actual stuff in my next blog entry – stay tuned!

It is no secret that CakePHP was born to implement the ideas of Ruby on Rails to the world of PHP – wonderful ideas, indeed, and I think we should pay tribute to the guys at 37signals.

But what CakePHP still lacks, in my opinion, is pure and complete DB abstraction. It is true that most recent versions of Cake ( v.2 RC3 as of now ) have done a lot in that area – the framework is now strongly decoupled from MySQL, although I personally have never heard of study cases that use Oracle, for example.

To the point – in a multi-developer environment it is critical to have a versioning control system ( you know you should be using git, right? ) and a database ‘versioning’ system – that is where Rails is much more powerful than CakePHP – it has database migrations.

Some migrations’ background

If you know what migrations are – skip that part and go directly to the next one. Otherwise – here is a simple explanation: they are related to the database like git ( or svn or cvs ) is related to the source. They simple provide a way to go back or forth to a previous or succeeding state ( or version ) of the database schema. The features of migrations are:

• They are DB agnostic – this means that they are not affected by the type of the DB server you’re using and help you in deploying your apps on different environments
• They help you with your agile development – you can put info in and out without affecting the rest of the project
• They provide you with a quick way to revert back to a previous state of the DB in case something went wrong
• DB migrations can save your life if you work in a team

To illustrate the all said, I have a simple example: You create a blog ( of course a blog – that’s probably the most often used example in the world ). Let’s split the development into three simple parts – development of blog posts CRUD; adding ACL; adding Comments to posts and.. that’s it – we want a simple example, after all.

So, first – blog posts Create, Read, Update, Delete. You begin by creating your DB schema. You need a simple posts’ table with a few fields – id, title, body, created. Then you write your PHP code, of course ( out of scope here ).

But one beautiful day you decide more than one person should be able to add posts and modify their own posts only – that’s when you read about Access Control Lists. Now you need a few more tables – users, aros, acos, acl and you need to add a field to the posts’ table ( user_id, for example ). Our small blog is getting just a bit more complex.

Finally, you want comments! But you have no time and ask your cousin for a favor ( he is a good dev, after all ). He adds another table for that. And then decides only registered users ( who cannot write new posts ) can add comments. And, of course, writes some more code. And inserts some more data in the db.

You ( and your cousin ) have went through 3 distinctive phases of agile development. You have, of course, used git ( oh, well, maybe svn or cvs ) to keep track of your code and make sure everything is ok and that you can revert back to a previous, stable version, if anything goes wrong. But then, one day – something really goes wrong. And you need to revert from state 3 to state 2 – i.e. remove the comments. But … your cousin is

• out of town
• mad at you because you behaved badly on his last birthday party
• has no idea what he did for you so many months ago

No problem – you use your source versioning system and do the reversal. But.. something is still wrong – your database stays unchanged. What did you add from v2 to v3? Did you remove something? And you know nothing about Database Server X – can you write the SQLs to revert the schema?

That is where DB migrations come in and save your life. Well, maybe not that important with your blog but imagine 100+ development iterations and 10+ developers working simultaneously on your project and maintaining it on many different platforms – this can turn into a small nightmare.

Joel Moss and his migrations

In his article at the Bakery Joel Moss describes how to use his CakePHP migrations shell. Although that project was my inspiration and I highly respect his work, his approach has several drawbacks:

• it uses PEAR – I don’t like it – that’s why I use CakePHP. I do not find necessary to explain this – I guess it is highly subjective.
• it is non-modular – you cannot use it to deploy applications – it is just a shell with no ‘core’
• it cannot make a snapshot of your already existing schema – you haven’t used migrations yet? That’s something you will need.
• it cannot merge your tables – that can be crucial when you already have different versions of the schema on different platforms and you just want them all to be standardized

So, I proudly present you with

My CakePHP Yaml Migrations and Fixtures

The idea was born when Eelco and I started working on PagebakeryCMS some time ago and was later further developed when we decided we needed a standardized CakePHP App Installer. You can get a copy of the project and follow it, too. What I personally find useful in it:

• no external libraries – only the SPYC class used to parse YAML files ( that is authored by Chris Wanstrath )
• can easily complement your source versioning system – use it for team collaboration
• can be used for DB abstraction installers – when deploying your applications on different platforms you don’t want to modify your SQLs – and the project is DB agnostic. The package also has fixtures ( well, the terms is not used correctly – this is for adding initial data to your database )
• can be used to standardize already installed applications on different platforms
• can help you make your apps DB agnostic by generating a YAML structure of your schema from where you can go on with the agnostic aproach

How it works

Just put all files in your CakePHP vendors folder.

If you want to use the API only, simply include the classes in your code

App::Import('vendor', 'migrations' )

and/or

App::Import('vendor', 'fixtures' )

And then, for example

$migrations = new Migrations();
$migrations->load('comments.yml');
$migrations->up();

For more usages – dig into the code a bit

Like many things in our Universe, web performance obeys Pareto’s 80-20 principle – 20% of the elements of a website cause 80% of the effects on the performance. And if we try to slightly reduce the time spent on loading those 20% of the elements, we can get much more than 20% increase in speed.

Are servers the root of all evil?

And as most of you probably already guessed – most of the server-side elements are not within those 20%. If you slightly improve ( or think you have ) your PHP algorithms or your SQL queries, you will probably gain benefits which are close to the statistical error. ( Here we are not talking about drastic changes or bug fixes in faulty software which shouldn’t have been there in the first place ).

Speed up the browser

What turns out to have the greatest impact on loading times and user experiences are the elements which load into the browser. And writing speed enhancements for the browser is out of our scope right now – we can just try to adapt our web pages, so that it is easier for it to parse and display. Here are my top 5 rules which have given me fantastic results.

Number of HTTP requests

If we are to believe Yahoo!, 80% of the time spent loading a web page is taken by downloading the entities of that page – mainly css, javascripts and images. The problem here is that we have too much unimportant (for the users) data sent back and forth, also known as headers. Even the smallest image has its request and response headers traveling with it across the Net. So, my advice is – combine your javascript and css files and use css sprites’ images. These are image maps which hold all of your images in one file and thus only this single file is sent over with its headers. Read more on css sprites here.

Expires header

This technique is very simple, yet very powerful and rarely used. Expires headers tell the browser that the entity it has requested *will not be changed* until some date. In practice, this means that the browser will not download that entity, if it already has it in its cache – 0 bytes transfered. Be careful, though, if you need to change something on the fly ( especially when still developing a site ), you will have to change the name of that file, so that the browser doesn’t think it already has it in the cache. This can easily be avoided using a simple versioning technique ( a link to some-file.js can look like some-file.js?version=1.0 and can later be changed to some-file.js?version=1.1 which will instantly make the browser fetch the file again as the url has changed ).

So, here – simply set a far-future Expires header on static content.

GZip

Also very useful, especially on large text files (like css and javascript files). This will effectively compress your content on the server, then send it to the browser which will uncompress it and use it. But be careful – don’t use this on images as it can be counter-productive. All A grade browsers support gzipped responses, so no worries about compatibility here.

Javascript and CSS

You should already know this but just in case – compress and minify your javascript and css files; put css at the top and javascript at the bottom. Simple, heh?

Flush it!

Well, the only server-side technique in my top 5 – flush your output buffer early ( just after the <head> tag ). This is very helpful on sites rich in html and text content because it will send the <head> of the html document fast enough so that the browser may start downloading the respective css files ( which you have put in the head, as described in the previous rule ) and underlying css images before the rest of the document has been transfered. Otherwise, you may end up in a situation where the whole HTML document needs to be received before css and the images can start being fetched.

This is just a sneak overview of the techniques – for a thorough list and technical help, please visit yahoo’s site

If you have ever tried to develop a robust ajax application, you have probably reached a point where you want the client to be notified about a change on the server in “real time”. The most simple example – you need to create a chat application and want the client to instantly receive new messages upon their arrival on the server. And, if you like me, are not a fan of Flash ( which may be one of your major flaws ) and want to achieve this using only ajax techniques, you have found out that is not that simple.

There is no real channel between the server and the client

In that case you have no real permament connection between the server and the client and there is no real way of “triggering” events or sending data from the server to the client in any traditional way. Moreover, ajax does not support the client “listening” and waiting for a server’s call ( well, that’s a client after all ). You googled for some time, asked some fellow developers and almost all you could find was – “Just use javascript’s (notorious) setTimeout() or setInterval() function to repeatedly poll the server and check whether there is new data for the client”.

Like, for example ( using jQuery ) :

function read(){
  jQuery.ajax( {
    'url'     : 'chat/read/',
    'cache'   : false,
    'dataType': 'json',
    'success' : function(messages){
      //if there are new messages - write them on the wall
      if( messages ){
	//write messages to the chat wall
      }
    } );
  }
}
 
setTimeout( function(){ read() }, 2000 );

( I will not show any server-side code examples as they are simple enough – the method being /chat/read/ would just read from the database and return new records. Moreover, what we have here is not what we’re trying to achieve – the example here is for descriptive purposes only. )

Is that what we call highly-responsive, flexible applications, you’d ask? No. This technique has several drawbacks:

• it sends http requests from the client to the server and gets response ( most of the time empty ones ) on every X number of seconds. X usually is a far too small number and that can translate into way too much wasted bandwidth, if we are talking about a high-traffic website and if we need that polling done for multiple actions
• it can eventually make the client hang-up as most modern browsers ( except for Chrome – or at least – what Chrome pleads ) don’t have smart javascript garbage collection and all those requests can be quite costly.
• it is not really highly-responsive – it has a lag of 2 seconds which may be enough to make the users nervous
• this just doesn’t feel like the right way of doing things

Comet

Well, I need to be honest – the Comet technique ( also known as long-polling ) seems like nothing new but I personally was not aware of it’s power till recently ( Eelco pointed it to me ). But you will be amazed how many open- and closed-source projects have no idea that it is out there and do not try to use it. And it is simple – you make a request to the server, it gets it and just… waits. Waits till there is meaningful data to be returned or returns something less useful ( like null ), if the request is about to timeout. On a standard apache configuration that would mean 5 minutes – you can make just one single request on every 5 minutes, not on every 2 seconds ( which a traditional ajax app would do ). That is 150+ times less requests, less bandwidth, less javascript functions’ calls and the application would feel much more responsive.

There is, however, a small side note to mention…

PHP Sessions are not keen on long-polling

And, if you hadn’t read this post, you’d have had some hard time finding this out. It is just that in every normal application, you can be 97% sure you will be using sessions. And in most of the time, you will rely on the built-in php sessions’ handler. So far, so good. But the small problem is that you cannot simultaneously be running different scripts ( or more than one instantiation of a script ) which use one and the same user session ( that, again, was a discovery by Mr. Pagebaker ). PHP will just queue all subsequent requests which try to interact with that session, until the first one has been closed. Well, that is not much of an asynchroneous technique either then. Getting back to our chat application – if you want to long-poll the server and wait for new messages ( what we will call read() ) and simultaneously send new messages to the server ( write() ), the application will not write() until the read() request has finished ( which we have set to 5 mins, if in the worst case there is no new data to be received ) – that is absolutely not what we need.

Frameworks to the rescue

But, as all self-respectful developers, you have adopted a php framework which provides an alternative to the native php sessions’ handler – be it file, database or any other geeky approach. I’d prefer CakePHP where it is simple – just open your /app/config/core.php and find

Configure::write('Session.save', 'php');

change that to

Configure::write('Session.save', 'database');

and uncomment the few lines below that line with respective data.

So, now let’s see what we have:

Our client-side script ( jQuery again ):

function read(){
  jQuery.ajax({
    'url'     : '/chat/read/',
    'cache'   : false,
    'dataType': 'json',
    'success' : function(messages){
      if( messages.length ){
	//write to chat wall
      }
      read();
    }
  });
}

It is important to notice that even though I have not shown the write() function, you should use jQuery’s Ajax Queue Plugin, so that our write requests are kept in good order. That is not needed when we read() as no subsequent read() requests will be fired before the first one has ended.

And, our cakephp chat controller method:

public function read(){
  $lastMessage_id = $this->Session->read('Conversation.lastMessage_id');
  if( $lastMessage_id === null ){
    echo $this->Json->encode( array() );
    $this->Session->write( 'Conversation.lastMessage_id', 0 );
    exit(0);
  }
  $now = time();
  $timeout = 300;
  while(!connection_aborted()){
    $messages = $this->Conversation->read( $lastMessage_id );
    if( !empty( $messages ) ){
      $this->Session->write( 'Conversation.lastMessage_id', $messages[ count( $messages ) - 1]['Message']['id'] );
      echo $this->Json->encode( $messages );
      exit(0);
    }
    elseif( time() > $now + $timeout ){
      echo $this->Json->еncode( array() );
      exit(0);
    }
    sleep(1);
  }
}

In short – we get the last message id from the user session then use it to fetch newer records from the model. If there are none and the user hasn’t left our webpage, we start looking for new messages once again and so on. We also keep track on the time we have spent so far in that iteration – we don’t want an ugly timeout, that is why we just send an empty response, if we have reached a critical level ( $timeout = 300 in that case ).

For simplicity, I do not use views in that example but it is highly recommended that you avoid using the JSON component and use views instead ( who knows, you might need a different format in the future ).

Notice the sleep(1) line – we don’t want our CPU to burn out after a few hours of work, so some time for rest is highly recommended. You may, of course, use smaller intervals but at your own risk.

That is it for now – feel free to comment and thanks for reading