Tag Archives: tips

Debugging a blank PHP page

Posted on by

I’m writing this post because I’ve had this problem three times in the past two weeks. Each time it’s soaked up more hours of my life than it should.

The problem is that you load you script and nothing is output. Not even an error to tell you where you’ve gone wrong. This must be a PHP bug, but I guess we’ll just have to live with it for now, and try debug around it.

The weird thing is the error that’s causing the page to be blank might not even be a fatal error. Twice for me it was just a warning, which should definitely not halt the processing of the script.

Without a line number or even which include the error is on it’s pretty hard to find out what the problem is to start fixing it.

Ultimately what I end up doing each time is echoing a string, and on the next line exiting. Put this right after the opening <?php on the first line.

echo "got to here.";
exit;

You should see the string output now. If you don’t it indicates that the hidden error is a fatal error, which will probably mean something to do with the syntax of your code, not the logic an undefined method or some such.

To fix that just carefully look through your code. If you don’t see any obvious problems then unindent everything. Now start indenting again if-by-if (or while-by-while, for-by-for, etc). Hopefully before the end of the file you’ll notice that you’ve had to indent twice, or you have left over braces. Delete or add as appropriate.

If you did see the “got to here.” text though, you can start moving those two lines down line by line. When you stop seeing the text you know the line above is the problem line. If you’re unfortunate enough to get to an include and it stops outputting, you’ll have to go through that too.

Once you’ve found the problem line, start debugging the relevant variables. You’ll likely find the problem there. (90% of all programming errors are variable related.)

How to make sure you don’t fuck up

Posted on by

I’ve been doing a lot more freelance stuff lately, and I feel like I’ve learnt something new (or a lesson has been stressed a lot more unto me) with every client.

Work off-line.

This definitely feels like more trouble than it’s worth, but trust me on this. I work with WordPress addons and fixes mostly, and I’ve found it’s always best to just grab their copy of WordPress, including their plugins and database, and run that on your localhost (or where ever). That way you’re running their installation warts and all (in case they changed some of the WordPress code without noticing or something),  so you’ll even have the same bugs as them.

Although WordPress mostly looks after itself with respect to the php.ini settings, if you’re working on something that doesn’t you may even want to yoink those settings and change your localhost to those. Same for .htaccess.

This way you know when you upload your changes it’ll work exactly the same way on their server as it did yours. There’ll be no nasty surprises because they have magic quotes turned on or their pages are redirected through another.

Whilst you’re at it, back all that stuff up.

Drag and drop all their files over FTP, export their database, nab their settings. Before you even start work, archive all of that. Put it in a /clients/ClientName/ folder and leave it there.

That serves two purposes; first you’re definitely not going to break their entire website accidental. And if you do, you’ll be able to restore, hopefully before they even notice. Second, you don’t have to keep nipping into their FTP server to find out how that old file was, or to revert back to the server version. Some people have tight bandwidth options and they won’t be happy about you using all that up.

Even after you’ve finished, keep the back up.

Honestly, you’ll be thankful you have. After you’ve done the job and your fix works perfectly on the live site you should still keep all the backups you made of their data for a little while. I’m planning on keeping mine for about a month or so. You might have missed a dire circumstance that you’ve broken, and in a few weeks you’ll get an “URGENT: YOU BROKE SOMETHING” entitled email.

Remember to encrypt that backup somehow. Just a simple password when you archive the file is enough. If your laptop gets stolen with hundreds of client’s MySQL passwords and things it’ll be fairly embarrassing phoning them all up and telling them they need to change them. I’d imagine that’d be more embarrassing than telling an ex you have herpes.

Whilst we’re talking about encryption, most servers have SFTP enabled and you should take advantage of that. I should expect most FTP clients have that feature, but I use WinSCP. It’s just the added extra security you can give your customers, and covering your back if anyone is ever listening in on your connection.

Keep track of your changes.

When you’ve finished your work do a diff or something similar on the work you’ve done compared with your old backup. If you’re client comes to you and says that since you’ve done your work some abstract thing on their blog has broken, you can go through that diff and either use it as evidence that it wasn’t you that broke it, or see specifically where you went wrong, and how you can fix it.

Also, it might be comforting to the client to see what work you’ve actually done. And you can always use it as a reference later on in other projects (“how did I make the post title change a few clients back..?”).

There are some others that I’ll add later.