mysql_connect() missing after a PHP upgrade

Before you start

Save the complete error line and its timestamp in a private note. Record the action that failed, the current PHP versionA PHP version is a numbered edition of PHP, like 8.3. Each edition is looked after for a limited time, then gets security fixes only, then nothing. and any components updated at the same time. Share only information needed for the investigation.

Public support forums are not suitable places for customer details, access credentials or complete server paths.

Back up both files and the database before making changes. Check that the backupA backup is a separate copy of your website's files and database, so you can bring the site back after a mistake, a hack or a failed update. is usable. Work on a restricted test copy with the same PHP version and relevant settings.

Disable real payments and outgoing customer emails there. Agree who will make the change and who will check the result. These steps are an investigation guide, not a diagnosis of your particular website.

What changed? The PHP migration guideA PHP migration guide describes changes to consider when moving to a different PHP version. records removal of the old mysql extension in PHP 7.0. This removal did not start with PHP 8.

Moving a legacy application directly to PHP 8 can reveal a call left in the code. The function name identifies the interface the code expects. It does not tell you whether the database server is reachable or whether credentials are correct.

Choosing the correct repair

Treat a move to MySQLi or PDO as a change to the database layer. Renaming mysql_connect alone is not a complete repair plan. Ask the developer to review connections, queries, result handling and error handling together.

Identify other files using the same interface and check for a maintained release from the supplier. Otherwise, fixing the first visible page can leave another route broken.

Five steps to a repair

1. Locate the first mention of mysql_connect in the error report. Record whether the failure starts during login, when opening a product or when saving an order. This narrows the initial investigation.
2. Identify the application or extension that supplies the call. Ask the administrator where the file comes from. Avoid editing a stray copy without knowing how it reaches the running website.
3. Inventory the related database calls. Separate actions that only read information from actions that change it. Use a separate test database containing invented records for this investigation.
4. Test the chosen replacement with a read operation and then a write. Check that text containing accents returns correctly. Compare an empty search result with a successful query as separate cases.
5. Repeat a complete visitor action. Inspect the saved record and the log at the new test time. Record which database code changed and who checked the resulting behavior.

A practical check

Use a small address book as a test scenario. Open an existing address, add an invented address and search for a name that does not exist. Write down the expected screen for each action before testing.

Also reject invalid input without leaving a partial record. This is a suggested test design, not a diagnosis of your website. It explains why a working homepage alone is insufficient evidence that database behavior has been repaired.

Getting help and checking the repair

Use the help form below if you cannot access the logs or do not know who maintains the affected code. Describe one failed action and the expected result. Ask for a proposal that separates the cause, the change and the acceptance check.

Do not include passwords with your request.

After the repair, repeat the original action on the test copy. Also check a normal visitor journey, an empty result and invalid input where relevant. Review fresh log entries at the new test time.

Keep versions and outcomes in your maintenance notes. Let the responsible administrator decide when the tested change can be applied to the live website.

Choosing the next step

Use the links below this article to choose the next step. The PHP update page helps you discuss maintenance with the administrator. The Exposure Check is a separate public check; do not treat its result as evidence that this programming error is repaired.

Use the status page for current security information. Keep the repair of the visitor action and the assessment of the server as separate checks in your notes. When requesting help, include the error text, the failed action and the expected result, but no passwords.

Ask for one responsible person to oversee both the change and its acceptance.