The Deprecated Warning Across the Top of the Page

A line above the logo

Since the host upgraded PHP, every page of the site opens with a line of small text above the logo: Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead.

After it comes the full path to a file on the server and a line number. The rest of the page still loads, mostly.

Sites that show this are usually hand-built in PHP, the programming language WordPress is also written in: a booking system, a catalogue or a members' area, made for one business by one developer.

The warning is not a fault in the upgrade. It is PHP saying the site relies on parts of the language that are on their way out.

What the message means

PHP talks to a MySQL database, where a site keeps its products, bookings or members, through a set of functions. The original set, all named mysql_ something, dates from the early days of the language.

Two replacements arrived about ten years ago: mysqli, an improved version of the same idea, and PDO, which works with several kinds of database. Both support safer ways of sending queries.

From PHP 5.5 onward the old set is deprecated: it still works, but prints this notice, and PHP's developers say it will be removed in a future version.

So the message is advance notice, not a malfunction.

What the warning breaks today

• Logins and carts can fail, because text printed first blocks the cookie.
• Forms can stop forwarding visitors to their thank-you page.
• Your server's folder path, account name included, is shown to everyone.
• Search results may quote the warning instead of your description.
• Feeds and maps expecting clean data receive an error message first.

The first is the one that puzzles people. A page has to send certain instructions, such as setting a login cookie or redirecting, before any visible text.

Once the warning has been printed, it is too late. Depending on how the server is set up, the login quietly fails, or the visitor sees a second warning instead of the next page.

Why hiding it is not a fix

The quickest response is to switch off the display of warnings. On a live site they belong in a log file rather than on the screen anyway, so as a stopgap it is reasonable.

But nothing underneath has changed. The next time the host moves to a newer PHP, the pages break with no warning at all, because the warnings are switched off.

There is a second reason. Code old enough to use these functions often builds its database queries by pasting in whatever a visitor typed, a weakness automated attacks probe for constantly.

Not a search and replace

It is tempting to think the fix is renaming mysql_query to mysqli_query throughout. Some of the job is close to that, which is why it looks simple in an estimate.

The rest is not. The new functions expect the database connection to be passed in each time, some take their arguments in a different order, and a few old functions have no direct equivalent.

The real gain comes from rewriting queries as prepared statements, where the query and the visitor's input travel separately and cannot be confused. The connection's character set needs setting explicitly too, or accented names can turn into odd symbols.

What the work involves

A developer searches the code for every use of the old functions: perhaps a dozen on a small catalogue site, hundreds on an older booking system.

The rewrite happens on a copy of the site running the newer PHP. Each page and form is tested the way customers use them, with errors going to a log that is read rather than skimmed.

The live site switches over only when that log stays quiet.

A worked example

A cloth diaper service delivers clean diapers to families across several suburbs each week and collects the used ones from a bin on the porch.

Its site was written in PHP long ago by a developer who later moved away. Parents type a postal code to see their delivery day, and new families sign up through a form that saves to a database.

After the host's upgrade, the warning appeared above the logo on every page. The sign-up form still saved each family, then showed a page of warnings instead of the confirmation. Several parents signed up twice.

A developer moved the warnings into a log that afternoon, which stopped the visible damage and fixed nothing.

Over the next two weeks the postal code lookup and the sign-up were rewritten with PDO and prepared statements, tested on a copy, and switched over on a quiet evening. The host's next upgrade is no longer a threat.

Ask the host before it moves you

Hosts upgrade PHP on their own timetable, usually when an older version stops receiving security fixes. PHP 5.3, still common on shared hosting, has had none since last August.

Ask which version your account runs and which it can switch to. Many control panels let you choose per account, so a developer can try a copy of the site on the newest version and list every error in advance.

Repair or rebuild

If the site also fails Google's Mobile-Friendly Test ahead of the April 21 change, needs a developer for every edit and depends on one person, compare the rewrite with a rebuild on a current content system.

If it is otherwise sound and does something specific to the business well, the rewrite is usually the better spend.

The counter-case

Some sites use the old functions in only one or two places, such as a news list or a form that saves to a database. For them the rewrite is a small job, not a project.

A site already due to be replaced within months can reasonably have its warnings logged rather than displayed in the meantime, provided the replacement has a date.

Either way, do not leave the code waiting for someone else's upgrade to break it. Log the warnings now, and replace the old functions before the host's next move.

Before the next upgrade

1. Ask the host which PHP version your account runs.
2. Send errors to a log instead of the screen.
3. List every use of the old mysql functions.
4. Rewrite queries as prepared statements with mysqli or PDO.
5. Test on a copy running the newest PHP offered.
6. Try every form the way a customer would.
7. Read the log for a week after switching.

Step four is where the value is. Renaming functions only postpones the problem, while prepared statements also close the oldest weakness in hand-built PHP sites.

When hosts move accounts to newer servers, and on whose timetable, is covered in your account on the host's oldest server.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.