Zenji Web Development

Since I got the Mac a couple of months ago there is one thing that keeps bugging me; connecting to my server is not particularly reliable. Dropped connections seemed to be pretty much guaranteed half way through a job that involves anything more than a couple of Mb of data. Since I tend to use the server for automated backups of my other machines it just hasn’t been happening for the Mac. Slowly I’ve got more and more concerned about having no regular backups.

A chance comment I came across whilst Googling for something else seems to have cleared up the issue. It seems my technique of using the Network utility in the Finder was the main issue. It is certainly the simplest option and most people seem to use it for that very reason. The trouble is it doesn’t always get the protocol right. You can check this by creating a connection to your server (in the finder choose Network and then browse to your server and connect to a share), selecting the new connection and then checking the info (Apple key and I). Mine shows up as:

cifs://my_server/backup

Since my Linux server uses Samba for the network shares it’s far better to connect using the Samba protocol:

smb://my_server/backup

The easiest way to set this up is through the ‘Connect to Server’ utility in the Finder. This also stores your server connections for easy future access. You should be able to simply type the connection string in and then connect at will. Hopefully you’ll see a much more stable connection in future.

(An extra tip - once you have the connection set up you can automatically connect at login by adding it to the list in System Preferences->Accounts->Login Items)

Now don’t get me wrong - I love CakePHP and I know there’s a good reason for the controller/action format of urls. In fact I often find it helps to have a framework that forces that sort of thinking on me all the time since most of the sites I write are more application than website. It’s a bit like the good old days when I was struggling to get my head around the concept of OO after coming from a very procedural background. I could probably have done with a framework then too.

So I do think that it’s great for web applications, but not necessarily for web sites. Clean urls have many touted advantages over controller/action urls for a web site. I’m not sure how many are true (things like Google favouring them seem like a good reason, if that is actually the case) but for me it’s best simply because they are not controller actions. A ‘contact me’ page is a ‘contact me’ page. It’s not really an action on a particular controller in your application. An ‘about’ page is similar - it just seems wrong to say ‘about’ is an action on ‘pages’. Well, it does to me anyway. Whilst I usually write web applications there is almost always a web site component like this to them and I think it’s fine to seperate those two concepts even when they’re on the same site.

Now it’s true that you can write static pages directly to the webroot, but my clients almost always want some management control over those pages. As much as I’d like them to have to come back to me every time they want to change a word it just doesn’t seem particularly fair and just harms my chances of repeat business! All of the other solutions I came across just seemed rather complex and often slightly dodgy. So I came up with a simple solution of my own that works fine.

Basically you add an entry to routes.php for each of these pages:

$Route->connect('/contact/*', array('controller' => 'pages', 'action' => 'contact'));

This will redirect any call to ‘/contact’ to ‘/pages/contact’, but without giving that fact away to the user. It’s true that you can’t now have a controller called ‘contact’ but then you wouldn’t want one anyway (the main reason being controller names should be plural when following the Cake conventions!). You can add as many of these lines as you like. If you end up with more than 2 or 3 you might want to question whether those pages should have been part of a controller!

Something that’s had me confused for a couple of hours today is using a checkbox in my CakePHP application. I’ve been using the html helper to create the relevant html and was initially confused by the fact that it not only creates the input element but also a preceding hidden input element.

<input type="hidden" name="data[Item][big_rock]" value="0" id="ItemBigRock_" />
<input type="checkbox" name="data[Item][big_rock]" id="ItemBigRock" value="1" />

So I did the best thing I could think of and ignored it, but when I came to creating the form to edit existing values I just ended up getting strange results. The checkboxes seemed to have a life of their own, checking and un-checking at will between post-backs. Google came up with several posts about the general problem most people come across with checkboxes - the fact that they post back nothing if they are not checked, but it took me far too long to actually put the strange hidden input field and this standard behaviour together. In my defence, there is very little documentation on this (that I could find) for CakePHP.
(more…)

I’ve been using CakePHP for quite a while now with no .htaccess issues at all, either running locally or on hosted sites. That all changed last night when I couldn’t get it to work at all on one of my budget hosting sites. Instead of my application all I saw were 500 Internal Server Errors.

I found that the issue was definitely down to one line in the root .htaccess (which was unmodified from the original CakePHP download):

RewriteRule (.*) app/webroot/$1 [L]

Unfortunately my cheaper hosting doesn’t allow me access to the error logs so it was difficult to diagnose the problem. By 11:00 last night I was certainly not in a good mood and no closer to an answer. I managed to Google plenty of references to similar issues but none solved my problem.

This morning I resorted to the hosting company themselves and within an hour they came up trumps! My thanks to Rob at VirtualNames support who not only worked it out, he even changed the file for me!

It looks like the problem is that the mod_rewrite rules don’t like fastcgi, which is the preferred option for this hosting account - it seems to try and redirect the internal URLs for fast cgi causing a rewriting loop. VirtualNames support felt it would probably work if the PHP mode is switched back to module mode, but they also came up with a fix to the .htaccess in the domain folder to (the root .htaccess for the CakePHP installation):

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteRule ^$ app/webroot/ [L]
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteRule (.*) app/webroot/$1 [L]
</IfModule>

This stops it trying to redirect the fastcgi internal access urls, and appears to cure the problem. It looks like the other .htaccess files do not need changing. .htaccess and rewrite rules are still a bit of a black art to me. After this they are going on my list of things to pick up!

I can also recommend VirtualNames as a budget hosting solution should you need one. Their support people actually do…erm…’support’