PHP is one of the most common languages on the web, so as a developer, it helps to have it in your tool kit. You don’t have to know it perfectly to dive into the language—PHP is similar to C and Java in some ways, so if you know these two languages, you can jump into it more easily. However, when learning any new language, chances are you’ll make some mistakes as you’re getting up to speed. Here’s a list of the most common mistakes PHP developers may face and ways to help avoid them.

1. Not Securing SQL Code

Some of the top cyber attacks on the web are SQL injections. In a SQL injection attack, a hacker will insert SQL code you haven’t authorized into your database, causing it to execute commands like leaking, altering, or deleting data. However, there are ways that better PHP programming can minimize the risk of SQL injection attacks.

PHP is the backbone for several out-of-the-box solutions such as WordPress. When writing new extensions and plugins for WordPress sites, developers will likely create inline SQL statements. These statements are built from the front-end and sent back to the SQL database. If these statements are malformed, you run the risk of leaving your site open to SQL injection.

There are two ways to avoid this. The first way (and the most preferred) is by using prepared statements. The second is by using parameterized queries.

The following statement builds on user input from a form:

$stmt = ("SELECT * FROM users WHERE firstname = '".$firstname."';");

This might leave your site vulnerable since it leaves your site open to SQL injection. A safer bet is to use parameterized and prepared statements like the following:

$stmt = $dbConnection->prepare('SELECT * FROM users WHERE firstname = ?');

$stmt->bind_param('s', $firstname);
$stmt->execute();

These are better methods because the tick mark the opens and closes a string value in SQL is processed as a literal and not an opening or terminating character.

2. Suppressing Errors

PHP has different error levels, but you can manually suppress them in your code. This is useful if you have errors that aren’t critical and don’t cause any serious effects. For instance, you could suppress warning messages regarding PHP versions.

The “@” symbol is used to suppress errors when you don’t need them, but use it with caution— it can sometimes cause some unforeseen issues. Suppose you have an include file that isn’t necessary when running the application. It could be optional for users who only have a specific component in their browser. In that case, you could use the following code in your PHP file:

(@include("animation.php"))

In the above code, even if the animation.php file has errors, they will not be displayed or logged. This error suppression should be used sparingly as you can have errors that aren’t being logged and won’t be found until something critical occurs in the application. In the long run, it’s better to handle errors rather than suppress them for convenience.

3. Printing Data Directly from User Input

This mistake is somewhat directly related to the first mistake we listed. The first mistake—not securing SQL code—can lead to SQL injection security flaws. This mistake references cross-site scripting (XSS) security flaws that can occur when the developer prints data directly from a user.

Suppose you have a form input text box named “firstname.” You want your script to display “Hello, $firstname” to the viewer. You can do this using the following code:

Welcome <?php echo $_POST["firstname"]; ?>

However, what happens if a user inputs “<script>alert('hello');</script>“? This might seem like a minor, insignificant annoyance that no one would bother doing, but the problem is that you’re allowing JavaScript to run indiscriminately in the browser. When JavaScript can run on the browser from user input, an attacker can use XSS to perform any number of events such as stealing passwords and sessions. A hacker could get very creative with the script and perform a number of attacks including session hijacking, phishing, and sneaky redirects.

Instead of printing user input, make sure you scrub any HTML tags out of the output, especially script tags. This will prevent rogue JavaScript code from running on your user’s computer. This type of attack is called an XSS attack, and it allows the attacker to run JS code that could potentially put the entire application at risk.

4. Don’t Forget to Remove Development Configurations

It’s important for any developer to have a development environment—a staging environment that mimics the production environment, which houses the live code. In some cases, a developer might be rushed and forget to remove development variables and configurations, then upload these by accident to the production environment. This can be a disaster for a live application.

Many new developers try to skip the staging environment and go straight from development to production in an effort to save time. This is a mistake because staging can help you identify problems that you didn’t catch in development (remember, staging mimics production). If you accidentally forget to remove configurations or don’t find bugs until staging, you can still catch them before they hit the production environment.

Always have a staging environment, and use it even if you’re just making minimal changes. It’s also a good idea to have QA testers test the code in staging before it’s moved to production.

5. Accidentally Using the Assignment Operator Rather Than the Comparison for a Condition

It’s easy to accidentally use the wrong operator when writing condition statements. After all, developers can spend several hours assigning values to variables. However, if you accidentally use the assignment operator instead of the conditional comparison, you run the risk of introducing bugs.

Take this code for example:

if ($condition = 'value')
//do something

In the above code, the developer mistakenly assigns the value “value” to the $condition variable. The condition should read like this:

if ($condition == 'value')
//do something

To avoid this type of mistake, some developers prefer to use “yoda syntax.” Yoda syntax switches the order of the condition and value. This is what the above code would look like in yoda syntax:

if ('value' == $condition)
//do something

Now, if you accidentally use the assignment operator instead of a comparison, the compiler will give you an error and you can correct it.

6. Forgetting to Run Backups

It might seem like an easy step, but many developers have poor backup practices. You don’t need to back up every hour, but you should run backups each day if you do significant work on a project. Just remember that your backups save you hours of recoding should you lose your data in the event your drive fails.

If you have a difficult time figuring out a problem in your code, back up the system so you don’t lose the solution—and hours of work—and have to recode it. A backup can also save you from missing a deadline if something happens to go awry.

You should also create backups for your clients in the rare case that a client has a critical failure and no backup. It’s a nice gesture, and you can help your client out of a potentially sticky situation.

Conclusion

Many developers encounter these common mistakes when learning PHP. It’s part of the learning process when learning a new language. Like with anything, practice makes perfect. Once you make a mistake, you can learn from it and take a course of action to avoid making the same mistake again in your future applications. Some will be critical while others will be minor, but this list can help you avoid some of the more common ones.