Skip to main content
common mistakes made by PHP developers

Common Mistakes that PHP Developers Make

One of the best things about PHP is that it is  a great language to just `dive into’. Thanks to its wide-ranging popularity, anyone with the ability to hit “Search” on Google can quickly create a program. However, this also lends to a major criticism of PHP, i.e. it is almost too easy to find and reproduce bad code.

Here are some mistakes that any PHP programmer, regardless of skill level, might make at any given time. Some of the mistakes are very basic, but unfortunately, they can trip up even the best PHP programmer! Other mistakes are hard to spot (even with strict error reporting). However, all  these mistakes have one thing in common: They are  easy to avoid.!

 Single quotes, double quotes

It is easy to just use double quotes when concatenating strings because it parses everything neatly without having to deal with escaping characters and using dot values. However, using single quotes has considerable performance gains, as it requires less processing.

Consider this string:

# $howdy = ‘everyone’; # $foo = ‘hello $howdy’; # $bar = “hello $howdy”;

$foo outputs to “hello $howdy” and $bar gives us “hello everyone”. That is one less step that PHP has to process. It is a small change that can add significant gains to code performance.

NOT Using database caching

If you use a database in your PHP application, it is strongly advised that you at least use some sort of database caching. Memcached has emerged as the most poplar caching system, with mammoth sites like Facebook endorsing the software.

Memcached is free and can provide very significant gains to your software. If your PHP is going into production, it is strongly advised to use the caching system.

Not Using E_ALL Reporting

Error reporting is a very handy feature in PHP, and if you are not already using it, you should really turn it on. Error reporting takes much of the guesswork out of debugging code, and speeds up your overall development time.

While many PHP programmers may use error reporting, many aren’t utilizing the full extent of error reporting. E_ALL is a very strict type of error reporting, and using it ensures that even the smallest error is reported. (That’s a good thing if you’re wanting to write great code.)

When you  are done developing your program, be sure to turn off your reporting, as your users probably will not want to see a bunch of error messages on pages that otherwise appear fine. (Even with the E_ALL error reporting on they hopefully won’t see any errors anyway, but mistakes do happen.)

Not Setting Time Limits On PHP Scripts

When PHP scripts run, it is assumed that they will eventually finish in a timely manner. But every good programmer knows that nothing should be assumed in a piece of code. Nothing makes a program crankier than an unresponsive script.

You can get around this issue by simply setting a time limit on the script (set_time_limit). While it may seem like a trivial thing, it’s always clever to prepare for the worst.

Not Protecting Session ID’s

A very common PHP security mistake is not protecting session ID’s with at least some sort of encryption. Not protecting these Session ID’s is almost as bad as giving away a user’s passwords. A hacker could swoop in and steal a session ID, potentially giving him sensitive information. An example of how to protect Session ID’s with sha1:

if ($_SESSION[‘sha1password’] == sha1($userpass)) {           // do sensitive things here}

Adding the shai1 to the ($userpass) gives an added bit of security to the session. Sha1 is not a bulletproof method, but it is a nice barrier of security to keep malicious users at bay.

Not Validating Cookie Data

How much trust do you put into cookies? Most people do not think twice about the seemingly-harmless bit of data that is passed by a cookie. If you are not validating cookie data, you are opening your code to potential harmful data. You should use htmlspecialchars() or mysql_real_escape_string() to validate the cookie before storing it in a database.

Not Escaping Entity

Often times PHP programmers are too trusting with data, especially data generated by user. It is imperative to sanitize data before it goes into any sort of storage, like a database.

Source Rally shows us how to correctly escape entities in things like forms. Instead of using this:

echo $_GET[‘username’];

You can validate the data by using htmlspecialchars() (or htmlentities()) like so:

echo htmlspecialchars($_GET[‘username’], ENT_QUOTES);

Using Wrong Comparison Operators

While comparison operators are an extremely basic part PHP programming, mixing these up in your code is certain to bork your program. As the German proverb states, the devil is in the details!

Being familiar with the often-misused operators like =, ==, != , are absolutely critical to PHP programming. Taking the time to really understand the differences will greatly speed up your programming and yield less bugs to debug.

Not cleaning up user input

A rule of thumb is to never trust user input. Every string must be validated using server-side PHP. This is better then using JavaScript. This is key to protecting your site from SQL injection attacks. Let’s go over a common scenario:

$username = $_POST[“name”];$password = $_POST[“password”];$sql = “SELECT userid FROM usertable WHERE username=’$username’ AND password=’$password’;”;// run query…

This can be cracked by entering “admin’; –” in the username field. The SQL string will equate to:

SELECT userid FROM usertable WHERE username=’admin’;

The devious hacker can log in as `admin’; they need not know the password because it is commented out of the SQL. Protect yourself against such attacks by developing your own function to check all string input.

Using MyISAM instead of InnoDB

Are you experiencing lag on your website? It may be due to your chosen database engine.

MyISAM is the default database engine for MySQL. However, for production systems, it is the wrong choice.  You place your performance and data integrity at risk when you operate in this mode. This is because MyISAM doesn’t support foreign key constraints or transactions, and locks the entire table when records are inserted or updated!

There is an easy  solution:  use InnoDB.

Using PHP’s mysql functions

PHP has built in MySQL library functions. You know:  mysql_connect, mysql_query, mysql_fetch_assoc, etc. but the PHP manual says:

If you are using MySQL versions 4.1.3 or later it is strongly recommended that you use the mysqli extension instead.

mysqli, or the MySQL improved extension, has several advantages:

  • an (optional) object-oriented interface
  • prepared statements
  • multiple statements and transaction support

Look into this. It will be worth the change.

Favoring PHP over SQL

When you are new to MySQL, it is tempting to solve problems in the language you know. That can lead to unnecessary and slower code. For example, rather than using MySQL’s native AVG() function, you use a PHP loop to calculate an average by summing all values in a record-set.

Watch out also for SQL queries within PHP loops. Normally, it is more effective to run a query then loop through the results.

In general, utilize the strengths of your database when analyzing data. A little SQL knowledge goes a long way.

Not optimizing your queries

99% of PHP performance problems will be caused by the database, and a single bad SQL query can play havoc with your web application. MySQL’s EXPLAIN statement, the Query Profiler, and many other tools can help you find that rogue SELECT.

Using the wrong data types

MySQL offers a range of numeric, string, and time data types. If you’re storing a date, use a DATE or DATETIME field. Using an INTEGER or STRING can make SQL queries more complicated, if not impossible.

It’s often tempting to invent your own data formats; for example, storing serialized PHP objects in string. Database management may be easier, but MySQL will become a dumb data store and it may lead to problems later.

Using * in SELECT queries

Never use * to return all columns in a table–it’s lazy. You should only extract the data you need. Even if you require every field, your tables will inevitably change.

Under or over-indexing

As a general rule of thumb, indexes should be applied to any column named in the WHERE clause of a SELECT query.

For example, assume we have a usertable with a numeric ID (the primary key) and an email address. During log on, MySQL must locate the correct ID by searching for an email. With an index, MySQL can use a fast search algorithm to locate the email almost instantly. Without an index, MySQL must check every record in sequence until the address is found.

It is tempting to add indexes to every column, however, they are regenerated during every table INSERT or UPDATE. That can hit performance; only add indexes when necessary.

Forgetting to back up

It may be rare, but databases fail. Hard disks can stop. Servers can explode. Web hosts can go bankrupt. Losing your MySQL data is catastrophic, so ensure you have automated backups or replication in place.

Sreenath V N

Sreenath V N

Sreenath VN is a Module Lead at Trigent. He has more than 9 years of experience in building Web Applications with PHP, MySql, MSSql, Neo4j and so forth.