# 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…

- Page: <https://www.datafirefly.com/en/documentation/database-manager-adminer-prestashop/>
- Language: en
- Last updated: 2026-06-29
- Other languages: [fr](https://www.datafirefly.com/documentation/database-manager-adminer-prestashop/index.md), [es](https://www.datafirefly.com/es/documentation/database-manager-adminer-prestashop/index.md), [de](https://www.datafirefly.com/de/documentation/database-manager-adminer-prestashop/index.md), [it](https://www.datafirefly.com/it/documentation/database-manager-adminer-prestashop/index.md), [pl](https://www.datafirefly.com/pl/documentation/database-manager-adminer-prestashop/index.md), [pt](https://www.datafirefly.com/pt/documentation/database-manager-adminer-prestashop/index.md), [nl](https://www.datafirefly.com/nl/documentation/database-manager-adminer-prestashop/index.md)
- Index: <https://www.datafirefly.com/en/documentation/llms.txt>

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.

**In one sentence** — install the ZIP, open the Adminer menu, manage your database. Auto-login uses the shop credentials, access is restricted to the SuperAdmin profile.

## 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.

**If the tab doesn't appear** — clear the PrestaShop cache (_Advanced Parameters > Performance > Clear cache_) then reload the menu. On PrestaShop 9, log out and log back in to the back office.

## 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.

**Per-employee Adminer sessions** — each SuperAdmin employee will have their own Adminer session (PHP sessions are per browser cookie), but all connect to the same database with the same system credentials. No Adminer accounts to manage.

## 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.

**Outgoing connection required** — the download requires your server to reach `adminer.org` over HTTPS. On some very restrictive shared hosts, outgoing connections are blocked. In that case, manually download the file from `adminer.org` and replace it in `modules/dfadminer/views/adminer/adminer.php` via FTP.

### 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.

**Tip** — Adminer remembers your SQL query history in the session. You can navigate the history via the _History_ menu at the bottom of the page, and re-run a query in one click.

### 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](https://www.datafirefly.com/en/my-account/)

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