cakePHP : Fatal error: Class 'Controller' not found

Last Friday, just before turning off my computer and going home, the cake project I'm working on was displaying a scary Fatal error: Class 'Controller' not found in /var/www/project/app/app_controller.php on line 5

Today, I'm getting back to work and here's what happened. After a morning of trial and error, I finally reverted back to a previous svn commit, then re- updated to the latest one and it seemed to solve the issue.

But later on the day, after another update, it started bugging again and the error message wasn't very helpful.

After much googling, this bug report gave me a hint : I had new models but didn't create the corresponding tables. Strangely, creating the missing logs table for my Log class solved the issue.

Hope this blog post will be usefull for anyone else struggling with this error message.

Working on Wednesday #2 : Why I want to quit PHP

Here it is : my first Wednesday off. Well, not completely off because I had a technical meeting this whole morning, and my cousin dropped by in the evening so... I finally didn't have as much time reading and learning as I wanted to.

Anyway, those past weeks I started thinking about what I intended to learn, and why. The main reason is that I want to be able to build website and apps faster, with less hassle and better overall quality. And the more I thought about that, the more it became obvious that PHP was the main bottleneck.

My journey accross PHP land

I've been writing PHP for the last 12 years. I started as a script kiddy, putting things together, hacking strings, saving stuff in databases, building my own toolbox and finally making websites out of it.

Then, as I started my first job in a web development company, I started to organize stuff to be able to use and reuse code accross projects.

Later, when I started as a freelancer, I learned cakePHP, and it let me much more time to focus on each project while still reusing the common code of previous projects easily.

PHP is just so easy

I can be considered a PHP coder. I have some years of experience to consolidate that. Nevertheless, I don't consider myself "good" at PHP. I just write PHP, and that's all.

I think there isn't any flavour in writing PHP : it is so easy anyone can do it. I don't feel like I know those special stuff that can make one an "expert". PHP just feels so easy, you just write code and it works.

The only area where I can think that my years of experience can be used is in tracking PHP bug or weird error messages (If you haven't read this website, go now).

It just does not feel right to be able to say "Yeah, you should work with me. Why ? Because my strength is that I'm very good at understanding PHP bugs".

There is no "PHP Philosophy", no good practices that were kept in mind by PHP lead developers when they wrote the language and they wanted us to follow. Instead, we just have a bunch of functions, and play with it as in a sandbox.

Adding some pattern in this mess

Over the years you learn (the hard way) how to organise your code. PHP5 gives a little hope by adding more OO features. No need to get back on the namespace delimiter choice, this is one more example of the PHP weirdness we'll have to work with.

The best thing that happened to me in PHP world over those years is cakePHP. It took me quite some time to get it, having to learn the whole MVC pattern (and deal with some of cake internal inconsistencies/limitations) but the result was worth it.

A clear separation of model structure, controller logic and view rendering gave me my sanity back. I does abstract a lot of things, and makes things cleaner on the outside, you can just concentrate on writing your app code.

But even with cakePHP, you still have to write PHP.

Summing up

So, to sum up, here are my feelings about PHP

• No peculiar love for the PHP syntax and (non-)patterns
• Growing list of bugs/inconsistencies you have to work with
• Don't feel like I'm any better than any new PHP coder, no skill required
• Best thing in PHP is cakePHP, an external framework

That's why PHP is the first language I'll drop in my new learning, and I'll replace it with Ruby.

Ruby seems to fit more in my vision of a language that tells its developers what are the good and bad way of writing code. And as cakePHP is largely based upon Rails, I think catching up won't be too difficult.

Also, Rails just realease it's version 3, so now the best time to learn it from scratch.

Next week

This first day off was much shorter than I expected it to be. I wanted to start coding some Rails code, following the Rails for Zombies tutorial. I also had plans for using vim a little more.

Next week I might write about vim, or maybe how to organize javascript code, depending on the time I had.

Ghost posting on FB.ui streams

We had a bit of an issue when launching our app a few weeks ago. Everything was working fine on our test apps, but when live, all the stream messages we posted (we call them "Sharings") had a random text appended.

Most of the time it was a generic Facebook text, but sometimes it was a creepier SQL request just displayed plain on the user feed.

The Facebook text was (for the sake of search engine goodness):

Facebook is a social utility that connects people with friends and others who work, study and live around them. People use Facebook to keep up with friends, upload an unlimited number of photos, post links and videos, and learn more about the people they meet.

As the issue only occurs in production mode and never on any of our test environments, this was pretty difficult to debug.

Here was the code used to post the Sharing :

FB.ui({
  [...],
  'title' : 'Title of the Sharing',
  'caption' : 'Text of the Sharing'
});

As I later found out, the captionkey is not supposed to hold the Sharing text. The descriptionkey should be used for that. I'm not exactly sure was captionwas for, but it seems that if you let the descriptionkey empty, then Facebook fills it automatically with a placeholder text.

The solution simply was to put the text in the descriptiontext, and leaving the captionkey empty :

FB.ui({
  'title' : 'Title of the Sharing',
  'caption' : '',
  'description' : 'Text of the Sharing'
});

As this behaviour is counter-intuitive, undocumented and random, I think posting it here could help other lost souls like me.

SWF caching issues accross browsers

Here are some quick notes on various browser caching behavior. I was fiddling with Wireshark to optimise my caching strategy and found some quirks one should be aware of.

First, let's define some reload vocabulary.

• initial load is the first time the page is loaded, when the cache is empty.
• hard reload is the classical reload. Clicking the Reload icon, or pressing Ctrl+R / F5.
• link reload is when the page is loaded again after you click on a link to it
• soft reload will be loading the page again by pressing enter in the address bar
• navigational reload is the reloading of a page that occurs while using the previous/next buttons.

For the rest of this blog post, we will assume an HTML page loading the same .jpg file multiple times and the same swf file multiple times too (we will use both IE specific and general swf markup).

The html itself is not cached.

Also, all those static assets will have a Cache-Control:max-age=29030400 header.

All the network tests have been made using Wireshark.

Chrome

Initial load : Download of jpg and swf once each. Perfect.

Link reload & navigational reload: Nor jpg nor swf is loaded again. Perfect.

*Soft reload & hard reload *: The jpg is downloaded again but not the swf. Chrome sends a Cache-Control:max-age=0 header to the jpg request, to force loading it again.

Reloading images is a standard behavior on images, but I wouldn't have expected it on soft reloads.

Safari 5 Win

Safari behaves much like Chrome, with one important difference. It does not cache swf files at all.

Initial load : The jpg gets downloaded perfectly, but the swf gets downloaded multiple times, one per instance.

Link reload & navigational reload : The jpg is correctly fetched from cache, but the swf are all downloaded again. No swf is ever cached.

Soft reload & hard reload : Much as Chrome, Safari forces the reload of the jpg here. As you might guess, it also reload all the swf too, multiple times.

It means that Safari 5 does not cache any swf file at all. That's pretty impressive.

This same caching bug is talked about on this other blog. I've also tried including flash files from within another flash file (much like the Satay method). The results are the same : no swf flash is ever cached, even in the same html request.

It is supposed to have been fixed in Safari Mac (anyone can confirm this? I don't own a Mac) but the issue is still here on Safari Windows.

IE6, IE7 and IE8

IE6, IE7 and IE8 behaves the same here. They have a less severe version of the bug than Safari 5. At the time of writing I didn't have IE9 to test on it.

Initial load : Same bug as Safari here. The swf are downloaded multiple times, once for each instance. The jpg is only download once.

Link reload, navigational reload and soft reload : This time, everything is fetched from the cache. Actually, even the html is seems fetched from cache (I didn't investigate that much)

Hard reload : Html and jpg are fetched from the server, swf file stays in the cache.

It appears that (surprisingly) IE behaves quite well. Its caching behavior is more aggressive than the others (soft reload is really soft). However, it still have a nasty side effect of loading swf files multiple times on the same page. Shouldn't happen a lot in the real world, but still nice to know.

Firefox 4.0

Initial load : No issue arising. It does fetch each resource once.

Link reload, navigational reload and soft reload : Fetches everything from cache, nice.

Hard reload : Re-request jpg and swf files by adding a Cache-Control: max-age=0 request header. This feels like the expected behavior.

Take care of that favicon

Even if you are not referencing it in your HTML markup, browsers will try to get a file named /favicon.ico on your server root. Let's see some good practice regarding this file.

Make it small

The smaller the file, the faster it will get downloaded. As it is a less than important file, we don't want to delay the loading of our page for such a tiny graphic. The default file format for such a file is image/x-icon, meaning the .ico extension.

I think it's a Microsoft legacy format, but well understood by every browser. Be careful when putting your favicon, don't just find a cool .ico file and drop it here. Icon files are containers, they hold various image format ranging from 16x16 to 512x512.

You clearly don't need the bigger one and the 16x16 will be highly enough. So, be careful.

The best way of creating the favicon I've found is to first create it as a .gif, then running ImageMagick upon it. On Linux, this means running

convert favicon.gif -resize 16x16! favicon.ico

Make it cacheable

This file will be requested by the browser on every request, so you'd better make it cacheable to limit the number of requests.

Also, note that you can't change the name of the file, favicon.ico will always be fetched.

I choose to cache mine for a year, like any other static asset. I could have gone for a month, to allow updating them more often but I've never ever changed a favicon, so a year seems better.

A note on Safari Win

From the tests I've done, almost all browsers behave the same regarding favicon fetching and caching : the fetch it last, and do not issue a Cache- Control:max-age=0 on a refresh to force redownloading it.

Except Safari Win. It fetch it along other downloads and re-dewnload it on a page refresh.