Biased PHP By Tom from TBB Polska


Tom's PHP Commandments - Take heed

1. ALWAYS do the simplest thing that will work

Using variable variables? Single lines with multiple ternary operators on them? Heck, considering variable functions?

Stop, take a step back, and think: there's probably a simpler way to do this. Variable variables in particular are a sign that you're going about something the wrong way.

Go back and work out a simpler solution; it'll be both easier to read and easier to maintain.

2. NEVER hash passwords with MD5/SHA-1/Hash-of-the-day

I will not accept any arguments about this: hashing passwords, salted or not, via hash functions such as MD5 is not, was not, and never will be acceptable.

PHPass will make life easy for yourself and keep your users' passwords secure.

PHP version 5.5 (not yet released) will support Bcrypt natively via its password_hash() function. Use it.

3. NEVER put variables directly in your SQL

Do you write SQL statements like this?

$sql = "SELECT columns FROM table WHERE value='".$input_value."' ";


If you do, I am not amused. You're either abusing a perfectly good system or, for reasons known only to yourself, using mysql_query()-type functions.

Stop. Doing. This. Right. Now.

With code like this, your site is vulnerable to SQL Injection. This is a really easy way for the socially disatisfied to hack your site and/or steal your data.

You need to be using "prepared statements" instead. Hunt down how to do so in your framework's documentation.

Alternatively, use MeekroDB. If you insist on writing your own database layer, use PDO and its prepared statements

4. NEVER trust anything that comes from the user

Do you ever display a user's name on the screen? Consider the following:

echo $user_name;


Looks pretty harmless on its own, right?

Noooooooo! Be warned, be warned, be warned!

What if a user entered their name as the following?

<script>alert(document.cookie);</script>


Well uh-oh - instead of calling alert(), they could just as easily have written an image tag to the document, sending your page cookies to their server. Painful.

The rule to prevent Cross-site Scripting (XSS) is simple, if not severe: sanitize any and all data that is displayed. HTML Purifier's not bad.

Note: this applies equally to all external data. If you're displaying a Twitter stream or an RSS feed on your site, make sure you're sanitizing it.

5. NEVER use CakePHP

  • Cake's model system is broken; there's no way to call models like so:
$cows = $this->Cows->findByStatus(COW_STATUS_NOT_MOOING);
foreach($cows as $cow)
{
  $cow->moo();
}


You'd have to do something like this instead:

$cows = $this->Cows->findByStatus(COW_STATUS_NOT_MOOING);
foreach($cows as $cow)
{
  $this->Cows->mooCow($cow['Cow']['id']);
}


Yuck! So many extra ways of failing! But that's a pretty minor complaint, especially compared to...

  • Cake's model system is seriously broken: all data is returned as an associate array! There is no lazy-loading of the data as you e.g. seek through it, which means it's very easy for people to pass around huge arrays with thousands upon thousands of rows and associations without even thinking about it. Ouch!

  • Judging from the number of broken CakePHP projects I help to rescue, writing well-formed projects using this framework is incredibly difficult.

Choose a framework that works with you - not one that fights against your every move.

6. NEVER use include for controlling logic

if ($earth_explodes) {
  include "../logic_files/hidden_meanings/end_times.php";
}
else
{
  include "../logic_files/normal/carry_on_mooing.php";
}


The include and require statements are not there to control logic. Heck, with Autoloading you should hardly ever be using them.

Everyone knows that goto should be considered harmful, and using includes in this way is just a glorified goto statement.

I'm choosing to ignore PHP's decision to pollute its namespace with Goto as of version 5.3, just to support a minority of use cases.

7. NEVER send emails directly from web page code

Sending emails is slow. Incredibly slow. Don't tie up a precious web front-end process with doing so.

Use a message queue instead.

8. NEVER create a file of useful functions, even if it's called helpers.php

This smacks of such a broken thinking process, it makes my teeth itch.

If you have commonly-used functions, they should be integrated with the commonly-used parts of your code.

Having logic orphened in a "logic here be good!" file is less than ideal.

9. NEVER use Apache when Nginx is an option

How do you set up Nginx so that it won't die or kill your server when you receive a big burst of traffic?

You install it.

How do you set up Apache so that it won't die or kill your server when you receive a big burst of traffic?

You configure it.

The argument is easy: if you're an Apache expect, use Apache; otherwise use nginx.