Database Manager Back Office — Adminer pour PrestaShop : installation, configuration, dépannage

Le module Database Manager Back Office (référence interne dfdbmanager) intègre Adminer 5.4.2 directement dans le back office PrestaShop 8 et 9. Plus besoin de cPanel ni de phpMyAdmin externe : un clic dans le menu Paramètres Avancés > Adminer et vous gérez votre base de données, déjà authentifié.

Pré-requis

• PrestaShop : 8.0.0 à 9.99.99 (testé sur 8.0, 8.1, 8.2, 9.0)
• PHP : 7.4 ou supérieur (compatible 8.0, 8.1, 8.2, 8.3)
• Base de données : MySQL 5.7+ ou MariaDB 10.3+
• Compte employé : profil SuperAdmin (id_profile = 1) pour ouvrir Adminer
• Hébergement : compatible mutualisé (o2switch, OVH, Infomaniak), VPS, dédié

Aucune connexion sortante n’est requise depuis votre serveur : Adminer 5.4.2 est bundlé dans le ZIP du module (508 KB, fichier unique).

Installation

1. Uploader le ZIP

Dans votre back office PrestaShop :

1. Allez dans Modules > Gestionnaire de modules
2. Cliquez sur Installer un module en haut à droite
3. Glissez-déposez le fichier dfadminer-1.0.0.zip ou cliquez pour le sélectionner
4. Attendez la fin de l’upload (quelques secondes — le ZIP fait moins de 400 KB)
5. Le module s’installe automatiquement

2. Vérifier l’onglet de menu

L’installation crée automatiquement un onglet de menu sous Paramètres Avancés > Adminer, avec une icône de stockage Material. L’onglet est créé en cinq langues (français, anglais, espagnol, allemand, italien) — la langue active s’affichera selon votre profil employé.

Premier accès à Adminer

Ouvrir le menu

Naviguez vers Paramètres Avancés > Adminer. Vous arrivez directement sur la liste des tables de votre base PrestaShop, sans écran d’authentification, sans formulaire à remplir.

La page se compose de :

• Une bannière fixe en haut, en dark navy, avec le nom de votre base à gauche et un bouton bleu Back to PrestaShop BO à droite
• L’interface Adminer en dessous : sidebar des tables à gauche, contenu principal à droite

Auto-login : comment ça marche

Le module lit les credentials de votre base depuis la configuration PrestaShop (les constantes _DB_SERVER_, _DB_USER_, _DB_PASSWD_, _DB_NAME_ définies dans config/parameters.php ou config/settings.inc.php) et démarre la session Adminer côté serveur avec ces credentials avant qu’Adminer ne se charge. Aucun nouveau mot de passe n’est créé, aucune permission MySQL n’est étendue — Adminer utilise exactement les mêmes droits que PrestaShop.

Page de configuration du module

Depuis Modules > Gestionnaire de modules, cherchez Database Manager Back Office et cliquez sur Configurer. La page propose trois sections.

Statut

Affiche :

• Version d’Adminer installée localement (5.4.2 par défaut)
• Chemin du fichier adminer.php dans le module
• Variante installée (Adminer complet ou Adminer Editor)
• Taille du fichier

Mettre à jour Adminer

Quand une nouvelle version stable d’Adminer sort sur adminer.org, vous pouvez la télécharger directement depuis cette page. Cliquez sur Update to latest Adminer — le module récupère le fichier depuis adminer.org/latest-en.php via cURL (ou file_get_contents en fallback) et remplace le fichier local.

Basculer vers Adminer Editor

Adminer publie aussi une variante Editor — l’interface est identique mais le champ d’exécution SQL brut est retiré. Seule la navigation dans les tables et l’édition de lignes restent disponibles. Utile si vous voulez donner accès à un profil moins technique sans risquer qu’il exécute du SQL libre.

Cliquez sur Switch to Adminer Editor pour télécharger et remplacer le fichier. Vous pouvez revenir à Adminer complet à tout moment avec Switch back to full Adminer.

Modèle de sécurité

Restriction SuperAdmin

Adminer est un outil puissant : qui a accès à votre base a accès à tout (commandes, clients, paiements, mots de passe hashés employés). Pour cette raison, le module restreint l’accès au profil SuperAdmin uniquement — c’est-à-dire id_profile = 1 dans PrestaShop.

Les autres profils (Logisticien, Traducteur, Vendeur, profils personnalisés) reçoivent un message Access Denied s’ils tentent d’ouvrir Adminer, même s’ils connaissent l’URL.

Double vérification serveur

La restriction est appliquée deux fois côté serveur dans le contrôleur :

• Dans postProcess() — avant qu’Adminer ne tourne
• Dans initContent() — au rendu UI de fallback

Cette double vérification garantit qu’aucun chemin de code ne contourne le gate, même en cas de comportement inattendu du routeur PrestaShop.

Blocage HTTP direct du fichier adminer.php

Le fichier views/adminer/adminer.php est bloqué à l’accès HTTP direct via un .htaccess avec la directive Require all denied. Tenter d’ouvrir directement l’URL /modules/dfadminer/views/adminer/adminer.php retourne un 403 Forbidden. La seule façon d’atteindre Adminer est de passer par le contrôleur PrestaShop, qui applique le gate SuperAdmin.

Utilisation d’Adminer pour PrestaShop

Tables courantes à connaître

Quelques tables fréquemment utiles pour le debug PrestaShop (préfixe ps_ par défaut, peut varier selon votre installation) :

• ps_configuration — toutes les variables de configuration (clés/valeurs)
• ps_orders — commandes
• ps_customer — clients
• ps_product + ps_product_lang — produits et leurs traductions
• ps_employee — employés du BO
• ps_log — journal d’erreurs PrestaShop
• ps_cart + ps_cart_product — paniers
• ps_specific_price — promotions et règles de prix

Exécuter une requête SQL

Dans la sidebar gauche, cliquez sur SQL command. Tapez votre requête, cliquez sur Execute. Adminer affiche le résultat en bas, avec pagination automatique pour les gros résultats.

Exporter une table

Sur une table donnée, cliquez sur Export. Adminer propose plusieurs formats : SQL (avec ou sans données), CSV, TSV. Pour les très grosses tables, l’export se fait en streaming chunked — pas de problème de mémoire PHP.

Éditer une ligne en place

Sur n’importe quelle table, cliquez sur Select data, puis sur le crayon à gauche d’une ligne. Vous éditez tous les champs dans un formulaire, vous sauvegardez d’un clic. Adminer génère automatiquement la requête UPDATE.

Multi-employés SuperAdmin

Si vous avez plusieurs employés avec le profil SuperAdmin, chacun aura sa propre session Adminer indépendante. Concrètement :

• Employé A ouvre Adminer dans son navigateur — sa session adminer_sid est créée
• Employé B fait pareil dans le sien — sa propre session adminer_sid est créée
• Les deux peuvent naviguer dans Adminer en parallèle sans interférence
• Quand A se déconnecte du BO PrestaShop, sa session Adminer reste valide jusqu’à la fermeture du navigateur (puis expire)

Tous les employés se connectent à la même base avec les mêmes credentials système — il n’y a pas de comptes Adminer séparés à gérer.

Mise à jour du module

Pour mettre à jour le module vers une version plus récente :

1. Téléchargez le nouveau ZIP depuis votre espace client DataFirefly
2. Dans le BO, Modules > Gestionnaire de modules
3. Cliquez sur Installer un module et uploadez le nouveau ZIP
4. PrestaShop détecte qu’une version existe déjà et propose de la mettre à jour
5. Confirmez — le module est mis à jour sans perdre la configuration

Aucune table BDD n’étant créée, il n’y a pas de migration de schéma à gérer entre versions.

Désinstallation

Pour désinstaller proprement le module :

1. Allez dans Modules > Gestionnaire de modules
2. Trouvez Database Manager Back Office
3. Cliquez sur Désinstaller dans le menu déroulant

La désinstallation :

• Supprime l’onglet de menu Paramètres Avancés > Adminer
• Retire les fichiers du module (y compris le fichier adminer.php bundlé)
• Ne touche à aucune table — votre base PrestaShop reste intacte
• Ne modifie aucune configuration PrestaShop, aucun mot de passe, aucune permission

La désinstallation est totalement réversible : réinstallez le module pour retrouver Adminer dans le même état.

Dépannage

L’écran d’authentification Adminer s’affiche au lieu de la liste des tables

Symptôme : vous ouvrez le menu Adminer et voyez le formulaire Authentification d’Adminer (champs System, Server, Username, Password, Database) au lieu de la liste des tables.

Cause probable : un ancien cookie Adminer (de l’installation précédente ou d’un autre site Adminer) interfère avec la session pré-populée.

Solution :

1. Ouvrez les DevTools de votre navigateur (F12)
2. Allez dans l’onglet Application (Chrome) ou Stockage (Firefox)
3. Section Cookies, sélectionnez votre domaine
4. Supprimez les cookies nommés adminer_sid, adminer_permanent, adminer_key et adminer_version
5. Rechargez la page Adminer avec Ctrl+Shift+R

Erreur 403 Forbidden au chargement

Symptôme : la page Adminer retourne un statut HTTP 403, parfois avec le formulaire d’authentification visible en dessous.

Cause probable : Adminer ne reconnaît pas la session pré-populée et tombe dans son code-path auth_error qui ajoute explicitement HTTP/1.1 403 Forbidden quand $_GET[username] est défini mais que l’authentification échoue.

Solution : même procédure que ci-dessus — videz les cookies Adminer du navigateur. Si le problème persiste, vérifiez que les credentials PrestaShop dans config/parameters.php (PS9) ou config/settings.inc.php (PS8) sont corrects et que PrestaShop arrive bien à se connecter à MySQL (le BO PrestaShop fonctionne-t-il normalement ?).

Les liens Adminer ramènent au dashboard PrestaShop

Symptôme : vous cliquez sur un nom de table dans la sidebar Adminer et vous arrivez sur le dashboard PrestaShop au lieu de la page de la table.

Cause probable : le post-processing des URLs (qui injecte controller=AdminDfAdminer dans les URLs internes d’Adminer) n’a pas fonctionné. Le plus souvent : un cache HTML ou un proxy intermédiaire qui sert une version stale de la page.

Solution :

1. Videz le cache PrestaShop (Paramètres Avancés > Performances > Vider le cache)
2. Videz le cache navigateur (Ctrl+Shift+R)
3. Si un CDN ou un cache HTTP est en amont (Cloudflare, Varnish), purgez son cache pour les URLs /admin*/index.php

Mode sombre : la bannière ou Adminer ne s’adaptent pas

La bannière du module s’adapte automatiquement au mode sombre du système via la media query @media (prefers-color-scheme: dark). Adminer 5 a aussi son propre mode sombre intégré qui suit la même préférence système.

Si le rendu ne suit pas votre mode système :

• Vérifiez que votre OS est bien en mode sombre (Windows : Paramètres > Personnalisation > Couleurs > Mode sombre ; macOS : Préférences Système > Général > Apparence : Sombre)
• Le navigateur doit transmettre cette préférence — par défaut Chrome et Firefox le font, mais certaines extensions de gestion de thèmes peuvent overrider
• Vérifiez avec DevTools Rendering > Emulate CSS media feature prefers-color-scheme que la préférence est bien dark

Invalid Security Token sur une action Adminer

Symptôme : vous exécutez une requête SQL ou éditez une ligne, et PrestaShop affiche Invalid Security Token.

Cause probable : ce message n’apparaît normalement jamais avec le module — le contrôleur override checkToken() pour bypasser le CSRF PrestaShop sur les actions internes d’Adminer. Si vous le voyez, c’est que vous accédez à une URL qui ne passe pas par notre contrôleur.

Solution : vérifiez que l’URL dans la barre du navigateur commence bien par index.php?controller=AdminDfAdminer&token=.... Si elle commence par index.php?select=... sans le paramètre controller, le post-processing des URLs a été contourné — videz les caches PrestaShop et navigateur, et rouvrez Adminer depuis le menu.

Architecture technique

Pour les développeurs ou les administrateurs curieux qui veulent comprendre comment fonctionne le module en interne.

Auto-login : pré-population de session

Le loader views/adminer/loader.php démarre la session Adminer avant que adminer.php ne se charge :

1. Ferme toute session PHP en cours via session_write_close() (PS9 peut en avoir démarrée une via Symfony)
2. Démarre une nouvelle session avec session_name('adminer_sid')
3. Pré-populate $_SESSION[pwds][server][host][user] avec le vrai mot de passe de la base, lu depuis _DB_PASSWD_
4. Pré-populate $_SESSION[db][server][host][user][dbname] = true
5. Définit $_GET[username], $_GET[db], $_GET[server] aux valeurs PrestaShop
6. Charge adminer.php

Quand Adminer s’initialise, il voit que la constante SID est déjà définie et skip son propre session_start(). Il voit $_SESSION[pwds] non-vide et skip la restauration via cookie permanent. La vérification d’authentification passe directement, Driver::connect() utilise le vrai mot de passe via la méthode credentials() de notre classe, et login() retourne true.

Bypass du CSRF PrestaShop

Les formulaires POST internes d’Adminer (exécution de requête SQL, édition de ligne, suppression de table) ne portent pas le token CSRF par contrôleur de PrestaShop. Sans intervention, PS rejette ces requêtes avec un écran Invalid Security Token.

Le contrôleur AdminDfAdminerController override la méthode checkToken() pour retourner true sans vérification. C’est sûr parce que le gate SuperAdmin (id_profile === 1) en amont est strictement plus fort qu’un token CSRF : un attaquant qui aurait déjà une session SuperAdmin volée a déjà accès à tout le back office de toute façon.

Réécriture des URLs Adminer

Adminer construit ses liens internes comme index.php?select=table_name&db=ps. Sans réécriture, ces URLs ne portent pas controller=AdminDfAdminer et PrestaShop les routerait vers le dashboard.

Le contrôleur appelle ob_start() avec un callback qui post-process la sortie HTML d’Adminer : injection de la bannière de retour BO en début de body, et réécriture de tous les attributs href, action et src qui pointent vers index.php?... pour y injecter controller=AdminDfAdminer& juste après le ?.

Survie aux exit; d’Adminer

Adminer fait 19 appels à exit; à divers endroits (page_footer, file= serving pour les assets, fin d’erreur). Un simple ob_get_clean() à la fin du contrôleur ne serait jamais atteint dans ces cas.

La solution : passer le callback de post-processing directement à ob_start(). Le callback est appelé automatiquement par PHP au moment du flush final du buffer, même si exit; a été appelé. Toutes les sorties d’Adminer passent donc par le post-processing, sans exception.

Compatibilité PrestaShop 9

Le module est testé sur PrestaShop 8.0, 8.1, 8.2 et 9.0. La compatibilité PS 9 est obtenue en utilisant exclusivement les patterns legacy supportés par les deux versions :

• ModuleAdminController au lieu de Symfony controllers — supporté en PS 8 et PS 9
• Smarty pour le template de configuration — supporté nativement
• Installation d’onglet via la classe Tab — API stable entre versions
• Pas de classes Symfony spécifiques, pas de bundle requis
• PSR-4 autoload sans Composer (chargé via require_once dans le main module)

Sur PS 9, le module fonctionne sans modification, sans recompilation, sans composer install.

Licence et code source

Le module DataFirefly est sous licence commerciale (DataFirefly Limited, Ireland). Le code source est livré non chiffré dans le ZIP — vous pouvez l’auditer, étendre les hooks, ou adapter le comportement (par exemple ajouter d’autres profils autorisés à ouvrir Adminer).

Adminer lui-même est sous double licence Apache 2.0 / GPL 2.0, créé par Jakub Vrana. Le fichier adminer.php bundlé est la version stable 5.4.2 inchangée — vous pouvez le remplacer par n’importe quelle version d’Adminer compatible en respectant la licence d’origine.

Support

Le support est inclus pendant 12 mois après l’achat (24h ouvrées, FR/EN). Pour toute question :

• Email : support à datafirefly.com
• Espace client : datafirefly.com/mon-compte

Pour les bugs ou demandes d’évolution, précisez votre version PrestaShop, votre version PHP, votre hébergeur et la version du module installée.