Catalogue and modules missing in Backoffice after port changes

[ROE]

Hi there,

Our hosting company recently updated the Mysql version on their servers to 8.4 and since we are running an older Prestashop installation, 1.7.2.1 and php 7.0, we were told to change our database server port to 6033 to maintain compatibillity. I have done so and frontend seems to be running fine again, but in backoffice I no longer have access to the catalogue and modules sections (i get Error 500) and I am now unable to add or edit any modules or items through the Backoffice. Any help or suggestions would be very much appriciated.

I have tried to enter debug mode, but the installation becomes unstable and eventually crashes.

//Best regards

Rasmus

 

[El Patron]

Hey @ROE no rest for the weary

Capture the real 500 error (don’t guess)

Do not rely on “debug mode” in BO if it makes the shop unstable. Instead, pull the error from logs.

Find your error log location first (before testing anything)

In your hosting panel (Plesk/cPanel or similar), locate:

• Domain → Logs (Apache/Nginx)
• PHP error log / PHP-FPM log
• If your host provides “Live log” or “Follow log,” open it now.

With the log open, replicate the problem

• In a new tab, go into Back Office and click the exact menu that triggers the 500:
• Catalog → Products / Categories
• Modules → Module Manager
• Do not change settings yet. Just reproduce the error once.
• Immediately re-check the log (this is the important part)
• Look for the first relevant entry at the exact time you clicked:

PHP Fatal error

Uncaught PDOException

SQLSTATE[...]

memory/timeouts like Allowed memory size exhausted or Maximum execution time exceeded

Post the first error line + the next few lines

The first fatal line is usually enough to identify whether this is:

• SQL mode / MySQL compatibility
• ProxySQL (port 6033) limitations/rules
• PHP 7.0 compatibility/fatal error
• permissions / missing extension / memory

If you paste that error snippet (redacting domain/usernames), people can tell you quickly whether you need the host to adjust sql_mode, ProxySQL rules on 6033, or whether the legacy PS/PHP stack is now failing on specific BO queries.

[ROE]

Hi El Patron, thank you so much for your detailed guidance.

I found the server log and replicated the error. When I click Catalogue/Products I get the following:

Backend fatal error: PHP Fatal error: Uncaught PDOException: PDO::__construct() [<a href='http://php.net/manual/en/pdo.construct'>pdo.construct</a>]: The server requested authentication method unknown to the client [caching_sha2_password] in /var/www/MYSITE.dk/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:43\nStack trace:\n#0 /var/www/MYSITE.dk/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php(43): PDO->__construct('mysql:host=mysq...', 'DATABASE_NAME', 'PASSWORD', Array)\n#1 /var/www/MYSITE.dk/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOMySql/Driver.php(44): Doctrine\\DBAL\\Driver\\PDOConnection->__construct('mysql:host=mysq...', 'DATABASE_NAME', 'PASSWORD', Array)\n#2 /var/www/MYSITE.dk/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(360): Doctrine\\DBAL\\Driver\\PDOMySql\\Driver->connect(Array, 'DATABASE_NAME', 'PASSWORD', Array)\n#3 /var/www/MYSITE.dk/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(833): Doctrine\\ in /var/www/MYSITE.dk/public_html/app/bootstrap.php.cache on line 3225\n

 

[El Patron]

What the error means
o Your shop is running PrestaShop 1.7.2.1 + PHP 7.0
o Your database server is MySQL 8.x (often via ProxySQL on port 6033)
o MySQL 8 defaults users to caching_sha2_password
o PHP 7.0 cannot authenticate with that plugin
o Result: Back Office pages that rely on PDO/Doctrine (Catalog, Modules, etc.) throw 500 errors

This explains why parts of the Front Office may still load while major Back Office sections are missing or broken.

Immediate fix (fastest)

Option 1 – change the existing DB user auth plugin
o Ask your host to switch the DB user to mysql_native_password
o If the username and password stay the same, no PrestaShop change is required
o If the password changes, update it in PrestaShop

CLI example (host or root access):
o ALTER USER 'db_user'@'%' IDENTIFIED WITH mysql_native_password BY 'new_password';
o FLUSH PRIVILEGES;

Same fix via phpMyAdmin (if you have access)

• Log in to phpMyAdmin
• Go to User accounts
• Click Edit privileges on the DB user used by PrestaShop
• Click Change password
• Re-enter the password and ensure authentication is set to
• mysql_native_password
• Save

(Some hosts expose the auth plugin selector directly; others apply it automatically when resetting the password.)

Option 2 – create a new DB user
o Create a new user using mysql_native_password
o Grant it full privileges on the PrestaShop database
o Update PrestaShop to use the new DB credentials

Where to update PrestaShop (only if needed)
o /app/config/parameters.php (PrestaShop 1.7)

• database_user
• database_password
• host / port (if changed)

What to confirm with your host
o Are you connecting through ProxySQL (port 6033) or directly to MySQL?
o What authentication plugin is assigned to the DB user used by PrestaShop?
o Can they switch that user (or create a new one) using mysql_native_password?

Root cause (important)
o PrestaShop 1.7.2.1 and PHP 7.0 are long end-of-life
o They are increasingly incompatible with modern MySQL defaults
o This will keep happening unless:

the DB engine is aligned to legacy compatibility (e.g. MariaDB), or

the shop is upgraded to a supported PrestaShop + PHP stack

This is a server compatibility issue, not a module or PrestaShop bug.

and now the rant:

Note to whom it may concern

When selecting hosting, it is critical that you control PHP and MySQL versioning.

Many issues like this are not caused by PrestaShop itself, but by hosting providers that:
o upgrade PHP or MySQL automatically
o do not check what applications are hosted
o provide no warning before breaking compatibility

This is why using a hosting environment where you explicitly control PHP and MySQL versions is essential. A control panel such as Plesk makes this straightforward and prevents surprises.

Without that level of control, many users eventually discover their hosting “suddenly broke” after an upgrade they did not request or approve.

In short: hosting choices matter, especially for legacy or long-running PrestaShop installations.