Database Manager Back Office — Adminer for PrestaShop: installation, configuration, troubleshooting

The Database Manager Back Office module (internal reference dfdbmanager) integrates Adminer 5.4.2 directly into the PrestaShop 8 and 9 back office. No need for cPanel or external phpMyAdmin: one click in the Advanced Parameters > Adminer menu and you manage your database, already authenticated.

Requirements

• PrestaShop: 8.0.0 to 9.99.99 (tested on 8.0, 8.1, 8.2, 9.0)
• PHP: 7.4 or higher (compatible with 8.0, 8.1, 8.2, 8.3)
• Database: MySQL 5.7+ or MariaDB 10.3+
• Employee account: SuperAdmin profile (id_profile = 1) to open Adminer
• Hosting: compatible with shared hosting (o2switch, OVH, Infomaniak), VPS, dedicated

No outgoing connection is required from your server: Adminer 5.4.2 is bundled in the module ZIP (508 KB, single file).

Installation

1. Upload the ZIP

In your PrestaShop back office:

1. Go to Modules > Module Manager
2. Click Upload a module at the top right
3. Drag and drop the dfadminer-1.0.0.zip file or click to select it
4. Wait for the upload to finish (a few seconds — the ZIP is less than 400 KB)
5. The module installs automatically

2. Check the menu tab

Installation automatically creates a menu tab under Advanced Parameters > Adminer, with a Material storage icon. The tab is created in five languages (French, English, Spanish, German, Italian) — the active language will display according to your employee profile.

First access to Adminer

Open the menu

Navigate to Advanced Parameters > Adminer. You land directly on your PrestaShop database table list, with no authentication screen, no form to fill in.

The page consists of:

• A fixed banner at the top, in dark navy, with your database name on the left and a blue Back to PrestaShop BO button on the right
• The Adminer interface below: table sidebar on the left, main content on the right

Auto-login: how it works

The module reads your database credentials from PrestaShop configuration (the constants _DB_SERVER_, _DB_USER_, _DB_PASSWD_, _DB_NAME_ defined in config/parameters.php or config/settings.inc.php) and starts the Adminer session server-side with these credentials before Adminer loads. No new password is created, no MySQL permission is extended — Adminer uses exactly the same rights as PrestaShop.

Module configuration page

From Modules > Module Manager, find Database Manager Back Office and click Configure. The page offers three sections.

Status

Shows:

• Locally installed Adminer version (5.4.2 by default)
• Path of the adminer.php file in the module
• Installed variant (full Adminer or Adminer Editor)
• File size

Update Adminer

When a new stable version of Adminer is released on adminer.org, you can download it directly from this page. Click Update to latest Adminer — the module fetches the file from adminer.org/latest-en.php via cURL (or file_get_contents as fallback) and replaces the local file.

Switch to Adminer Editor

Adminer also publishes an Editor variant — the interface is identical but the raw SQL execution field is removed. Only table navigation and row editing remain available. Useful if you want to give access to a less technical profile without risking free SQL execution.

Click Switch to Adminer Editor to download and replace the file. You can switch back to full Adminer at any time with Switch back to full Adminer.

Security model

SuperAdmin restriction

Adminer is a powerful tool: whoever has access to your database has access to everything (orders, customers, payments, hashed employee passwords). For that reason, the module restricts access to the SuperAdmin profile only — that is, id_profile = 1 in PrestaShop.

Other profiles (Logistician, Translator, Salesman, custom profiles) get an Access Denied message if they try to open Adminer, even if they know the URL.

Server-side double check

The restriction is applied twice server-side in the controller:

• In postProcess() — before Adminer runs
• In initContent() — at fallback UI rendering

This double check ensures no code path bypasses the gate, even with unexpected PrestaShop router behavior.

Direct HTTP access blocked on adminer.php

The views/adminer/adminer.php file is blocked from direct HTTP access via a .htaccess with the Require all denied directive. Trying to open the URL /modules/dfadminer/views/adminer/adminer.php directly returns a 403 Forbidden. The only way to reach Adminer is through the PrestaShop controller, which enforces the SuperAdmin gate.

Using Adminer for PrestaShop

Common tables to know

A few tables frequently useful for PrestaShop debugging (default ps_ prefix, may vary by installation):

• ps_configuration — all configuration variables (key/value)
• ps_orders — orders
• ps_customer — customers
• ps_product + ps_product_lang — products and their translations
• ps_employee — BO employees
• ps_log — PrestaShop error log
• ps_cart + ps_cart_product — carts
• ps_specific_price — promotions and pricing rules

Run an SQL query

In the left sidebar, click SQL command. Type your query, click Execute. Adminer displays the result below, with automatic pagination for large results.

Export a table

On any table, click Export. Adminer offers several formats: SQL (with or without data), CSV, TSV. For very large tables, export is done in chunked streaming — no PHP memory issue.

Edit a row in place

On any table, click Select data, then the pencil to the left of a row. You edit all fields in a form and save with one click. Adminer automatically generates the UPDATE query.

Multiple SuperAdmin employees

If you have several employees with the SuperAdmin profile, each will have their own independent Adminer session. Concretely:

• Employee A opens Adminer in their browser — their adminer_sid session is created
• Employee B does the same in theirs — their own adminer_sid session is created
• Both can navigate Adminer in parallel without interference
• When A logs out of the PrestaShop BO, their Adminer session remains valid until they close the browser (then expires)

All employees connect to the same database with the same system credentials — there are no separate Adminer accounts to manage.

Updating the module

To update the module to a newer version:

1. Download the new ZIP from your DataFirefly customer area
2. In the BO, Modules > Module Manager
3. Click Upload a module and upload the new ZIP
4. PrestaShop detects an existing version and offers to update it
5. Confirm — the module is updated without losing the configuration

Since no database tables are created, there’s no schema migration to handle between versions.

Uninstallation

To cleanly uninstall the module:

1. Go to Modules > Module Manager
2. Find Database Manager Back Office
3. Click Uninstall in the dropdown menu

The uninstallation:

• Removes the Advanced Parameters > Adminer menu tab
• Removes the module files (including the bundled adminer.php file)
• Touches no table — your PrestaShop database remains intact
• Modifies no PrestaShop configuration, no passwords, no permissions

The uninstallation is fully reversible: just reinstall the module to get Adminer back in the same state.

Troubleshooting

The Adminer authentication screen appears instead of the table list

Symptom: you open the Adminer menu and see Adminer’s Authentication form (fields System, Server, Username, Password, Database) instead of the table list.

Likely cause: an old Adminer cookie (from a previous installation or another Adminer site) interferes with the pre-populated session.

Solution:

1. Open your browser DevTools (F12)
2. Go to the Application tab (Chrome) or Storage (Firefox)
3. Cookies section, select your domain
4. Delete the cookies named adminer_sid, adminer_permanent, adminer_key and adminer_version
5. Reload the Adminer page with Ctrl+Shift+R

403 Forbidden error on load

Symptom: the Adminer page returns HTTP status 403, sometimes with the authentication form visible below.

Likely cause: Adminer doesn’t recognize the pre-populated session and falls into its auth_error code-path which explicitly adds HTTP/1.1 403 Forbidden when $_GET[username] is set but authentication fails.

Solution: same procedure as above — clear the Adminer cookies from the browser. If the problem persists, check that the PrestaShop credentials in config/parameters.php (PS9) or config/settings.inc.php (PS8) are correct and that PrestaShop is actually connecting to MySQL (does the PrestaShop BO work normally?).

Adminer links redirect to the PrestaShop dashboard

Symptom: you click a table name in the Adminer sidebar and you land on the PrestaShop dashboard instead of the table page.

Likely cause: URL post-processing (which injects controller=AdminDfAdminer into Adminer’s internal URLs) didn’t run. Most often: an HTML cache or an intermediate proxy serving a stale version of the page.

Solution:

1. Clear the PrestaShop cache (Advanced Parameters > Performance > Clear cache)
2. Clear the browser cache (Ctrl+Shift+R)
3. If a CDN or HTTP cache is upstream (Cloudflare, Varnish), purge its cache for the /admin*/index.php URLs

Dark mode: the banner or Adminer don’t adapt

The module banner automatically adapts to system dark mode via the @media (prefers-color-scheme: dark) media query. Adminer 5 also has its own built-in dark mode that follows the same system preference.

If rendering doesn’t follow your system mode:

• Check that your OS is actually in dark mode (Windows: Settings > Personalization > Colors > Dark mode; macOS: System Preferences > General > Appearance: Dark)
• The browser must transmit this preference — by default Chrome and Firefox do, but some theme-management extensions can override it
• Check with DevTools Rendering > Emulate CSS media feature prefers-color-scheme that the preference is indeed dark

Invalid Security Token on an Adminer action

Symptom: you run an SQL query or edit a row, and PrestaShop displays Invalid Security Token.

Likely cause: this message normally never appears with the module — the controller overrides checkToken() to bypass PrestaShop CSRF on Adminer’s internal actions. If you see it, you’re accessing a URL that doesn’t go through our controller.

Solution: check that the URL in the browser bar starts with index.php?controller=AdminDfAdminer&token=.... If it starts with index.php?select=... without the controller parameter, URL post-processing was bypassed — clear the PrestaShop and browser caches, and reopen Adminer from the menu.

Technical architecture

For developers or curious administrators who want to understand how the module works internally.

Auto-login: session pre-population

The loader views/adminer/loader.php starts the Adminer session before adminer.php loads:

1. Closes any in-progress PHP session via session_write_close() (PS9 may have started one via Symfony)
2. Starts a new session with session_name('adminer_sid')
3. Pre-populates $_SESSION[pwds][server][host][user] with the real database password, read from _DB_PASSWD_
4. Pre-populates $_SESSION[db][server][host][user][dbname] = true
5. Sets $_GET[username], $_GET[db], $_GET[server] to PrestaShop values
6. Loads adminer.php

When Adminer initializes, it sees that the SID constant is already defined and skips its own session_start(). It sees $_SESSION[pwds] non-empty and also skips the permanent-cookie restoration. The auth check passes directly, Driver::connect() uses the real password via our class’s credentials() method, and login() returns true.

PrestaShop CSRF bypass

Adminer’s internal POST forms (SQL query execution, row editing, table deletion) don’t carry PrestaShop’s per-controller CSRF token. Without intervention, PS rejects these requests with an Invalid Security Token screen.

The AdminDfAdminerController controller overrides the checkToken() method to return true without verification. It’s safe because the SuperAdmin gate (id_profile === 1) upstream is strictly stronger than a CSRF token: an attacker who already has a stolen SuperAdmin session already has full back office access anyway.

Adminer URL rewriting

Adminer builds its internal links like index.php?select=table_name&db=ps. Without rewriting, these URLs don’t carry controller=AdminDfAdminer and PrestaShop would route them to the dashboard.

The controller calls ob_start() with a callback that post-processes Adminer’s HTML output: injection of the BO return banner at the start of the body, and rewriting of all href, action and src attributes that point to index.php?... to inject controller=AdminDfAdminer& right after the ?.

Surviving Adminer’s exit; calls

Adminer makes 19 exit; calls at various points (page_footer, file= serving for assets, error end). A plain ob_get_clean() at the end of the controller would never be reached in those cases.

The solution: pass the post-processing callback directly to ob_start(). The callback is automatically called by PHP at the time of the buffer’s final flush, even if exit; was called. All Adminer output therefore goes through post-processing, without exception.

PrestaShop 9 compatibility

The module is tested on PrestaShop 8.0, 8.1, 8.2 and 9.0. PS 9 compatibility is achieved by exclusively using legacy patterns supported by both versions:

• ModuleAdminController instead of Symfony controllers — supported on PS 8 and PS 9
• Smarty for the configuration template — supported natively
• Tab installation via the Tab class — API stable across versions
• No specific Symfony classes, no bundle required
• PSR-4 autoload without Composer (loaded via require_once in the main module)

On PS 9, the module works without modification, without recompilation, without composer install.

License and source code

The DataFirefly module is under commercial license (DataFirefly Limited, Ireland). The source code is delivered unencrypted in the ZIP — you can audit it, extend the hooks, or adapt the behavior (for example to add other profiles authorized to open Adminer).

Adminer itself is under Apache 2.0 / GPL 2.0 dual license, created by Jakub Vrana. The bundled adminer.php file is the unchanged stable 5.4.2 version — you can replace it with any compatible Adminer version while respecting the original license.

Support

Support is included for 12 months after purchase (24h business days, FR/EN). For any question:

• Email: support at datafirefly.com
• Customer area: datafirefly.com/en/my-account

For bugs or evolution requests, please specify your PrestaShop version, PHP version, host, and installed module version.