The CSS box model is a W3C standard that draws the basic principles on which a box is drawn in HTML/CSS. Since every HTML element is actually a box, this principle applies to every element. Basically it states that the screen estate a box takes up is defined by the following parameters, in this order from inside to outside:

1. width/height
2. padding
3. border
4. margin

Here the content area is defined by width/height.

Quirks mode, standards mode and almost standards mode

All these terms have to do with the issue of browser compatibility. It all started back in the dawn of browsers, where every browser laid down its own flavor of standards and tried to force it just for the sake of “I have a bigger audience and think things should happen my way”.

So, the interpretation of CSS box model was different for IE and Netscape (the big players back then). Since these differences became very inconvenient for webdevelopers it was obvious W3C standards (common standards) was the way to go. Still, many websites had already been created using the distorted rules existing so far, and if the browsers began displaying them according to standards many sites would break.

So developers had to be given a way to switch between the standards mode and quirks mode (the wild west of browsers). In quirks mode (the old way of displaying pages) different bugs are “available for public use”, the most notable difference in the box model being that the box size is defined by width/height, border and margin (no padding – padding actually is a part of with/height, and the content area is defined by width/height minus padding). This switch is the DOCTYPE definition that should be given in the start of every HTML document, which tells the browsers how to interpret the page – in standards or in quirks mode.

The “almost standards mode” is a hybrid interpretation employed by some browsers. It differs from standards mode only in the interpretation of laying out images in a table (which is in quirks mode), so that old websites using many sliced-up images laied out in a table structure are less likely to break.

Semantics

Probably you’ve heard this a bunch of times – “…using semantic code”. What does it actually say? Well, this is to say your code should be meaningful by itself. The code is not just there to accomplish the goal of presenting a certain piece of content on the screen in a specific way, but should be universally describing the content. Thus it would be a matter of CSS changes to make the content look in an entirely new way. Also, each content entity will be readable, described by its role – address, content, header, box, username, etc.

Let’s give a small example. What’s wrong with the following piece of code?

<span class="red">A message goes here.</span>

Technically – nothing. Semantically, however, the coder binds the class name to a specific website theme/look/skin, instead of keeping the code semantically meaningful. An important rule of web programming is to keep the three layers (action, design, content) separate. It would be better to use a class name like “emphasized”, for example. If we use .red we’re facing two major issues:

• when changing the site theme at a certain stage of development to one with green elements, for example, the .red class would look weird if it displays as green;
• semantically the code is richer when using meaningful class names (like “emphasized”, “date”, “section”), and thus the webpage will be more delicious a bite for search engines.

Classes vs. IDs

You can assign both attributes to an element, but which one should you use?

• From a CSS perspective IDs have higher priority. So, if you have both a class and an ID assigned to an element, the ID definition will take precedence:

<style>
#header { color:green; }
.myStyle { color:red; }
</style>
...
<div id="header" class="myStyle">Lorem Ipsum</div>

The text will show as green, despite the fact that .myStyle was defined on a later stage in the CSS.

• From HTML/JS perspective, you should only use unique IDs in a document, so it is appropriate to use IDs for major document elements like #header, #footer, #content, and classes for elements that are found repeating in a document (.box, .column, .emphasized).

The advantages of writing standard-based DIV based HTML

CSS-based layouts have been around for over 10 years now, so it is a sin not to use them. It has multiple advantages before the table-based layouts, and some of them are:

• you get everything done with a smaller amount of code, thus achieving a better code-to-text ratio, which affects SEO ranking, too;
• you get better control over separate elements (e.g. moving the logo around is much easier and does not require re-slicing the whole site layout); this is much like the ease of editing a layered Photoshop/GIMP file vs. editing a flattened JPG;
• you get better separation of content, design and behaviour; thus different team members can work separately and independently on different aspects of a site (design, development), without interfering; also, you get a much easier time at debugging issues and making changes;
• you get an easy way to make any design changes (effectively switch between themes) by not changing a single line of content code; all you have to edit is your CSS file;
• you get a thing to brag about in front of your friends – writing compact and standards-compatible code is certainly an accomplishment
• by writing standard code you make sure your site will work and look properly in a vast amount of browsers – even in future browsers, ones that will come out 2 years from now.

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:

Intro

Imagine the following: you have worked on a Photoshop project, spending hours on end over it. You may not have slept this night, but you know that every drop of sweat was worth it – after all you have created wonders! The result is quite impressive, and of course when you show it to the customer he is totally into it, and says:

“This is great! I love it! But what if we make the image of the little girl a bit bigger?… Just a bit – it shouldn’t be an issue, right?”

OR

“That tree you have cut out from the background… Let’s get it back and see if it is better”

Well… Let me hear you say “Arrghhh!!!”

How transformations change the image irreversibly

In order to illustrate that, let’s look at a simple case. We will get a simple image, rotate it 45 degrees, then rotate it back 45 degrees and compare the difference between the original, untransformed image, and the supposed-to-be-the-same, rotated back and forth, image. Here goes the three step process:

Rotating an image 45 degrees and back again.

As you can see, the image we ended up with is quite far from the one we started with. And this is the result of only two consecutive transformations that require interpolation (scaling/rotation). Quite a bunch of info is lost, since each transformation is irreversible, and the result serves as a base for any following transformation.

Going back to the scenario described in the intro: since you have manipulated the original images (rotated them, scaled them down, applied filters and color corrections to them), you cannot just go back, change a little something, and expect all the rest of the manipulations down the line to ‘re-apply’ and remain the same.

On the other hand, if you go back in history to the stage you want to change, you will lose all the undone actions. So what you will have to do it basically re-do everything from that moment on.

This is just one example when you would wish your image manipulations are adjustable even after they’ve been done.

Have no fear – the solution is here

Fortunately there is a way to achieve this – you have a series of tools in your hands that can help you make your actions reversible and adjustable, and the team working on Photoshop, as a leading product on the market, seems to think in the same direction, adding to these features in the latest releases.  Here is a quick list:

• masks / clipping masks
• adjustment layers
• smart objects / smart filters
• history brush

Masks: don’t delete – just hide

This is a quite basic technique. The idea is to just hide portions of the image you don’t need instead of erasing them. A mask layer is actually a grayscale “map overlay”, where white represents complete opaqueness, black – full transparency, and the shades of grey – levels of semi-transparency. Boy, does that help out in that “get-the-tree-back” situation – you just need to paint the mask white where the pixels of the hidden tree are and voila – there it is.

Adding a mask to a layer in Photoshop is just a click away – select the layer to add the mask to, and then click on the “Add layer mask” button in the “Layers” palette:

Adding a mask

Clipping Masks – another breed

Sometimes you need to restrain the visibility of a layer to the extent of a certain object that is on another layer.  Let’s say you want to achieve this effect:

This is an image seen through a ‘hole’ defined by a text layer. Achieving this through a regular mask on the image layer will do quite the same for you, but there will be two disadvantages:

• If you want to change the text, you will need to re-create the mask, too.
• You will have some redundancy by having an extra element – both a text layer and a mask.

Now let’s see how to get the same result through a clipping mask:

1. Create the text layer.
2. Drag the image layer over the text layer.
3. Alt-click (Option-click for Mac) on the border between the two layers to get the text layer act as a clipping mask for the image layer.

HINT: You can add as much clipped layers as needed.

Pros: You get a dynamically updated mask. You simplify things by having a single layer acting both as a layer and a mask for other layers.

Cons: Setting the opacity of the clipping mask influences the opacity of the clipped layers (note: there is no vice versa)

Adjustment layers: don’t harm your pixels

The most common image correction techniques involve tinkering with brightness/contrast, levels, hue/saturation, curves, exposure or converting to grayscale. All these operations change the original image, and in most cases you could lose information (like losing color with grayscale conversion, or losing detail in burnt-out areas when brightening an image). So it is a great thing all these (and more) are available as an adjustable alternative – the so-called ‘adjustment layers’.

Applying an adjustment is as easy as inserting a new layer (see the screenshot) in the layer stack. Click on the “Create new fill or adjustment layer” button in the “Layers” palette, and choose an adjustment to apply. The adjustment is then applied to all layers down the stack. If you later want to change the parameters of the adjustment (e.g. the brightness value), just double click on its thumbnail to get the adjustment settings dialogue. You can also move the layer up and down the stack, thus controlling which layers are affected by it. If you don’t want the adjustment anymore – you can temporarily hide it or delete it and everything will be as if it never existed.

So, an adjustment layer is like an instruction set for a change (e.g. ‘change the brightness level to +35),  and not the change itself. This allows us to change the parameters of the adjustment (in this case – brightness and contrast levels) anytime. This is why I call it ‘parametric’.

Constraining the effect of the adjustment to a certain portion of the image (like, in the image on the right, graying out the whole image except the flower), is a matter of drawing in the mask of the adjustment layer (see “Masks“).

The tricky part is if you want to apply an adjustment to a single layer / a group of layers in the middle of the stack.

Restrain the effect to a group of layers: Since the adjustment layer affects all layers below, a way to restrain its effect is group the layers with the adjustment layer on top of the the group stack (see left).

For restraining the effect to a single layer you can avoid creating an unnecessary group, but use the layer (Layer 2) as a clipping mask for the adjustment layer instead (see right). You can achieve that by Alt-clicking (Option-click for Mac) on the border between the two layers in the layer stack.

Pros: Transformations are not lossy, because they are undoable and adjustable.

Cons: None that I know of.

That’s it for now. The next couple of tools (smart objects/filters and history brush) will be coming up shortly in the “Non-destructive techniques in Photoshop image manipulation – part 2” article.

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