Database Manager Backoffice — Adminer für PrestaShop: Installation, Konfiguration, Fehlerbehebung

Das Modul Database Manager Back Office (interne Referenz dfdbmanager) integriert Adminer 5.4.2 direkt in das Backoffice von PrestaShop 8 und 9. Kein cPanel oder externes phpMyAdmin mehr nötig: ein Klick im Menü Erweiterte Parameter > Adminer und Sie verwalten Ihre Datenbank, bereits authentifiziert.

Voraussetzungen

• PrestaShop: 8.0.0 bis 9.99.99 (getestet auf 8.0, 8.1, 8.2, 9.0)
• PHP: 7.4 oder höher (kompatibel mit 8.0, 8.1, 8.2, 8.3)
• Datenbank: MySQL 5.7+ oder MariaDB 10.3+
• Mitarbeiterkonto: SuperAdmin-Profil (id_profile = 1), um Adminer zu öffnen
• Hosting: kompatibel mit Shared Hosting (o2switch, OVH, Infomaniak), VPS, dediziert

Keine ausgehende Verbindung von Ihrem Server ist erforderlich: Adminer 5.4.2 ist im Modul-ZIP gebündelt (508 KB, einzelne Datei).

Installation

1. ZIP hochladen

In Ihrem PrestaShop-Backoffice:

1. Gehen Sie zu Module > Modul-Manager
2. Klicken Sie oben rechts auf Modul hochladen
3. Ziehen Sie die Datei dfadminer-1.0.0.zip per Drag-and-Drop oder klicken Sie zum Auswählen
4. Warten Sie auf das Ende des Uploads (wenige Sekunden — das ZIP ist weniger als 400 KB groß)
5. Das Modul wird automatisch installiert

2. Menü-Tab prüfen

Die Installation erstellt automatisch einen Menü-Tab unter Erweiterte Parameter > Adminer, mit einem Material storage Icon. Der Tab wird in fünf Sprachen erstellt (Französisch, Englisch, Spanisch, Deutsch, Italienisch) — die aktive Sprache wird je nach Ihrem Mitarbeiterprofil angezeigt.

Erster Zugriff auf Adminer

Menü öffnen

Navigieren Sie zu Erweiterte Parameter > Adminer. Sie landen direkt auf der Tabellenliste Ihrer PrestaShop-Datenbank, ohne Authentifizierungsbildschirm, ohne auszufüllendes Formular.

Die Seite besteht aus:

• Einem fixen Banner oben, in Dark Navy, mit Ihrem Datenbanknamen links und einem blauen Back to PrestaShop BO Button rechts
• Der Adminer-Oberfläche darunter: Tabellen-Sidebar links, Hauptinhalt rechts

Auto-Login: so funktioniert es

Das Modul liest Ihre Datenbank-Anmeldedaten aus der PrestaShop-Konfiguration (die Konstanten _DB_SERVER_, _DB_USER_, _DB_PASSWD_, _DB_NAME_, die in config/parameters.php oder config/settings.inc.php definiert sind) und startet die Adminer-Session serverseitig mit diesen Anmeldedaten, bevor Adminer lädt. Es wird kein neues Passwort erstellt, keine MySQL-Berechtigung erweitert — Adminer verwendet genau die gleichen Rechte wie PrestaShop.

Modul-Konfigurationsseite

Von Module > Modul-Manager aus suchen Sie Database Manager Back Office und klicken auf Konfigurieren. Die Seite bietet drei Abschnitte.

Status

Zeigt an:

• Lokal installierte Adminer-Version (5.4.2 standardmäßig)
• Pfad der adminer.php-Datei im Modul
• Installierte Variante (vollständiges Adminer oder Adminer Editor)
• Dateigröße

Adminer aktualisieren

Wenn eine neue stabile Version von Adminer auf adminer.org veröffentlicht wird, können Sie sie direkt von dieser Seite herunterladen. Klicken Sie auf Update to latest Adminer — das Modul ruft die Datei von adminer.org/latest-en.php via cURL ab (oder file_get_contents als Fallback) und ersetzt die lokale Datei.

Zu Adminer Editor wechseln

Adminer veröffentlicht auch eine Editor-Variante — die Oberfläche ist identisch, aber das Roh-SQL-Ausführungsfeld ist entfernt. Nur Tabellennavigation und Zeilenbearbeitung bleiben verfügbar. Nützlich, wenn Sie einem weniger technischen Profil Zugriff geben möchten, ohne freies SQL ausführen zu lassen.

Klicken Sie auf Switch to Adminer Editor, um die Datei herunterzuladen und zu ersetzen. Sie können jederzeit mit Switch back to full Adminer zum vollständigen Adminer zurückkehren.

Sicherheitsmodell

SuperAdmin-Beschränkung

Adminer ist ein mächtiges Werkzeug: Wer Zugriff auf Ihre Datenbank hat, hat Zugriff auf alles (Bestellungen, Kunden, Zahlungen, gehashte Mitarbeiter-Passwörter). Aus diesem Grund beschränkt das Modul den Zugriff ausschließlich auf das SuperAdmin-Profil — also id_profile = 1 in PrestaShop.

Andere Profile (Logistiker, Übersetzer, Verkäufer, benutzerdefinierte Profile) erhalten eine Access Denied-Meldung, wenn sie versuchen, Adminer zu öffnen, selbst wenn sie die URL kennen.

Serverseitige Doppelprüfung

Die Beschränkung wird im Controller serverseitig zweimal angewendet:

• In postProcess() — bevor Adminer läuft
• In initContent() — beim Fallback-UI-Rendering

Diese Doppelprüfung stellt sicher, dass kein Code-Pfad das Gate umgeht, selbst bei unerwartetem Verhalten des PrestaShop-Routers.

Blockierung des direkten HTTP-Zugriffs auf adminer.php

Die Datei views/adminer/adminer.php ist vor direktem HTTP-Zugriff über eine .htaccess mit der Direktive Require all denied blockiert. Der direkte Versuch, die URL /modules/dfadminer/views/adminer/adminer.php zu öffnen, gibt einen 403 Forbidden zurück. Der einzige Weg, Adminer zu erreichen, führt über den PrestaShop-Controller, der das SuperAdmin-Gate durchsetzt.

Adminer für PrestaShop nutzen

Häufige Tabellen, die man kennen sollte

Einige Tabellen, die häufig für das PrestaShop-Debugging nützlich sind (Standard-Präfix ps_, kann je nach Installation variieren):

• ps_configuration — alle Konfigurationsvariablen (Schlüssel/Wert)
• ps_orders — Bestellungen
• ps_customer — Kunden
• ps_product + ps_product_lang — Produkte und ihre Übersetzungen
• ps_employee — BO-Mitarbeiter
• ps_log — PrestaShop-Fehlerprotokoll
• ps_cart + ps_cart_product — Warenkörbe
• ps_specific_price — Promotions und Preisregeln

Eine SQL-Abfrage ausführen

In der linken Sidebar klicken Sie auf SQL command. Geben Sie Ihre Abfrage ein, klicken Sie auf Execute. Adminer zeigt das Ergebnis darunter an, mit automatischer Paginierung für große Ergebnisse.

Eine Tabelle exportieren

Auf einer beliebigen Tabelle klicken Sie auf Export. Adminer bietet mehrere Formate an: SQL (mit oder ohne Daten), CSV, TSV. Bei sehr großen Tabellen erfolgt der Export im gechunkten Streaming — kein PHP-Speicherproblem.

Eine Zeile direkt bearbeiten

Auf einer beliebigen Tabelle klicken Sie auf Select data, dann auf den Stift links von einer Zeile. Sie bearbeiten alle Felder in einem Formular und speichern mit einem Klick. Adminer generiert automatisch die UPDATE-Abfrage.

Mehrere SuperAdmin-Mitarbeiter

Wenn Sie mehrere Mitarbeiter mit dem SuperAdmin-Profil haben, hat jeder seine eigene unabhängige Adminer-Session. Konkret:

• Mitarbeiter A öffnet Adminer in seinem Browser — seine adminer_sid-Session wird erstellt
• Mitarbeiter B macht dasselbe in seinem — seine eigene adminer_sid-Session wird erstellt
• Beide können Adminer parallel ohne gegenseitige Beeinflussung navigieren
• Wenn A sich vom PrestaShop-BO abmeldet, bleibt seine Adminer-Session bis zum Schließen des Browsers gültig (dann läuft sie ab)

Alle Mitarbeiter verbinden sich mit derselben Datenbank mit denselben System-Anmeldedaten — es gibt keine separaten Adminer-Konten zu verwalten.

Modul aktualisieren

Um das Modul auf eine neuere Version zu aktualisieren:

1. Laden Sie das neue ZIP aus Ihrem DataFirefly-Kundenbereich herunter
2. Im BO, Module > Modul-Manager
3. Klicken Sie auf Modul hochladen und laden Sie das neue ZIP hoch
4. PrestaShop erkennt, dass bereits eine Version existiert, und schlägt eine Aktualisierung vor
5. Bestätigen Sie — das Modul wird aktualisiert, ohne die Konfiguration zu verlieren

Da keine Datenbanktabellen erstellt werden, gibt es keine Schema-Migration zwischen Versionen zu verwalten.

Deinstallation

Um das Modul sauber zu deinstallieren:

1. Gehen Sie zu Module > Modul-Manager
2. Finden Sie Database Manager Back Office
3. Klicken Sie im Dropdown-Menü auf Deinstallieren

Die Deinstallation:

• Entfernt den Menü-Tab Erweiterte Parameter > Adminer
• Entfernt die Moduldateien (einschließlich der gebündelten adminer.php-Datei)
• Berührt keine Tabelle — Ihre PrestaShop-Datenbank bleibt intakt
• Ändert keine PrestaShop-Konfiguration, keine Passwörter, keine Berechtigungen

Die Deinstallation ist vollständig reversibel: Installieren Sie das Modul einfach neu, um Adminer in demselben Zustand wieder zu erhalten.

Fehlerbehebung

Der Adminer-Authentifizierungsbildschirm erscheint statt der Tabellenliste

Symptom: Sie öffnen das Adminer-Menü und sehen Adminers Authentifizierungs-Formular (Felder System, Server, Username, Password, Database) statt der Tabellenliste.

Wahrscheinliche Ursache: Ein alter Adminer-Cookie (von einer vorherigen Installation oder einer anderen Adminer-Site) stört die vorbefüllte Session.

Lösung:

1. Öffnen Sie die DevTools Ihres Browsers (F12)
2. Gehen Sie zum Tab Application (Chrome) oder Speicher (Firefox)
3. Im Bereich Cookies wählen Sie Ihre Domain aus
4. Löschen Sie die Cookies adminer_sid, adminer_permanent, adminer_key und adminer_version
5. Laden Sie die Adminer-Seite mit Strg+Shift+R neu

403 Forbidden Fehler beim Laden

Symptom: Die Adminer-Seite gibt HTTP-Status 403 zurück, manchmal mit darunter sichtbarem Authentifizierungsformular.

Wahrscheinliche Ursache: Adminer erkennt die vorbefüllte Session nicht und fällt in seinen auth_error-Code-Pfad, der explizit HTTP/1.1 403 Forbidden hinzufügt, wenn $_GET[username] gesetzt ist, aber die Authentifizierung fehlschlägt.

Lösung: gleiche Vorgehensweise wie oben — leeren Sie die Adminer-Cookies aus dem Browser. Wenn das Problem weiterhin besteht, überprüfen Sie, dass die PrestaShop-Anmeldedaten in config/parameters.php (PS9) oder config/settings.inc.php (PS8) korrekt sind und dass PrestaShop sich tatsächlich mit MySQL verbinden kann (funktioniert das PrestaShop-BO normal?).

Adminer-Links leiten zum PrestaShop-Dashboard um

Symptom: Sie klicken auf einen Tabellennamen in der Adminer-Sidebar und landen auf dem PrestaShop-Dashboard statt auf der Tabellenseite.

Wahrscheinliche Ursache: Das URL-Post-Processing (das controller=AdminDfAdminer in die internen URLs von Adminer injiziert) hat nicht funktioniert. Meistens: ein HTML-Cache oder ein zwischengeschalteter Proxy, der eine veraltete Version der Seite ausliefert.

Lösung:

1. Leeren Sie den PrestaShop-Cache (Erweiterte Parameter > Performance > Cache leeren)
2. Leeren Sie den Browser-Cache (Strg+Shift+R)
3. Wenn ein CDN oder HTTP-Cache vorgeschaltet ist (Cloudflare, Varnish), leeren Sie dessen Cache für die URLs /admin*/index.php

Dark Mode: der Banner oder Adminer passen sich nicht an

Der Modul-Banner passt sich automatisch dem System-Dark-Mode über die Media Query @media (prefers-color-scheme: dark) an. Adminer 5 hat ebenfalls seinen eigenen integrierten Dark-Mode, der derselben Systempräferenz folgt.

Wenn das Rendering Ihrem Systemmodus nicht folgt:

• Überprüfen Sie, dass Ihr OS tatsächlich im Dark-Mode ist (Windows: Einstellungen > Personalisierung > Farben > Dunkler Modus; macOS: Systemeinstellungen > Allgemein > Erscheinungsbild: Dunkel)
• Der Browser muss diese Präferenz übermitteln — standardmäßig tun das Chrome und Firefox, aber einige Theme-Management-Erweiterungen können sie überschreiben
• Überprüfen Sie mit DevTools Rendering > Emulate CSS media feature prefers-color-scheme, dass die Präferenz tatsächlich dark ist

Invalid Security Token bei einer Adminer-Aktion

Symptom: Sie führen eine SQL-Abfrage aus oder bearbeiten eine Zeile, und PrestaShop zeigt Invalid Security Token an.

Wahrscheinliche Ursache: Diese Meldung erscheint normalerweise nie mit dem Modul — der Controller überschreibt checkToken(), um den PrestaShop-CSRF bei Adminer-internen Aktionen zu umgehen. Wenn Sie sie sehen, greifen Sie auf eine URL zu, die nicht über unseren Controller läuft.

Lösung: Überprüfen Sie, dass die URL in der Browser-Leiste mit index.php?controller=AdminDfAdminer&token=... beginnt. Wenn sie mit index.php?select=... ohne den controller-Parameter beginnt, wurde das URL-Post-Processing umgangen — leeren Sie die PrestaShop- und Browser-Caches und öffnen Sie Adminer erneut über das Menü.

Technische Architektur

Für Entwickler oder neugierige Administratoren, die verstehen möchten, wie das Modul intern funktioniert.

Auto-Login: Session-Vorbefüllung

Der Loader views/adminer/loader.php startet die Adminer-Session, bevor adminer.php lädt:

1. Schließt jede laufende PHP-Session via session_write_close() (PS9 kann eine via Symfony gestartet haben)
2. Startet eine neue Session mit session_name('adminer_sid')
3. Befüllt $_SESSION[pwds][server][host][user] vor mit dem echten Datenbank-Passwort, das aus _DB_PASSWD_ gelesen wird
4. Befüllt $_SESSION[db][server][host][user][dbname] = true vor
5. Setzt $_GET[username], $_GET[db], $_GET[server] auf die PrestaShop-Werte
6. Lädt adminer.php

Wenn Adminer initialisiert, sieht es, dass die SID-Konstante bereits definiert ist und überspringt seinen eigenen session_start(). Es sieht $_SESSION[pwds] nicht-leer und überspringt auch die Permanent-Cookie-Wiederherstellung. Die Auth-Prüfung wird sofort bestanden, Driver::connect() verwendet das echte Passwort via der credentials()-Methode unserer Klasse, und login() gibt true zurück.

PrestaShop CSRF-Bypass

Adminers interne POST-Formulare (SQL-Abfrage-Ausführung, Zeilenbearbeitung, Tabellenlöschung) tragen nicht das PrestaShop-CSRF-Token pro Controller. Ohne Eingriff lehnt PS diese Anfragen mit einem Invalid Security Token-Bildschirm ab.

Der Controller AdminDfAdminerController überschreibt die Methode checkToken(), um ohne Verifizierung true zurückzugeben. Es ist sicher, weil das SuperAdmin-Gate (id_profile === 1) upstream strikt stärker ist als ein CSRF-Token: Ein Angreifer, der bereits eine gestohlene SuperAdmin-Session hat, hat sowieso vollen Backoffice-Zugriff.

Adminer-URL-Rewriting

Adminer baut seine internen Links wie index.php?select=table_name&db=ps. Ohne Rewriting tragen diese URLs nicht controller=AdminDfAdminer, und PrestaShop würde sie zum Dashboard routen.

Der Controller ruft ob_start() mit einem Callback auf, der die HTML-Ausgabe von Adminer post-processed: Injektion des BO-Rückkehr-Banners am Anfang des Body und Umschreiben aller href-, action– und src-Attribute, die auf index.php?... verweisen, um controller=AdminDfAdminer& direkt nach dem ? einzufügen.

Überleben von Adminers exit;-Aufrufen

Adminer macht 19 exit;-Aufrufe an verschiedenen Stellen (page_footer, file= serving für die Assets, Fehlerende). Ein einfaches ob_get_clean() am Ende des Controllers würde in diesen Fällen nie erreicht.

Die Lösung: den Post-Processing-Callback direkt an ob_start() übergeben. Der Callback wird von PHP automatisch beim finalen Flush des Buffers aufgerufen, selbst wenn exit; aufgerufen wurde. Alle Adminer-Ausgaben durchlaufen daher das Post-Processing, ohne Ausnahme.

PrestaShop 9 Kompatibilität

Das Modul ist auf PrestaShop 8.0, 8.1, 8.2 und 9.0 getestet. Die PS 9 Kompatibilität wird durch die ausschließliche Verwendung von Legacy-Patterns erreicht, die von beiden Versionen unterstützt werden:

• ModuleAdminController statt Symfony-Controller — auf PS 8 und PS 9 unterstützt
• Smarty für das Konfigurations-Template — nativ unterstützt
• Tab-Installation über die Tab-Klasse — versionsstabile API
• Keine spezifischen Symfony-Klassen, kein Bundle erforderlich
• PSR-4 Autoload ohne Composer (geladen via require_once im Main-Modul)

Auf PS 9 funktioniert das Modul ohne Änderung, ohne Neukompilierung, ohne composer install.

Lizenz und Quellcode

Das DataFirefly-Modul unterliegt einer kommerziellen Lizenz (DataFirefly Limited, Ireland). Der Quellcode wird unverschlüsselt im ZIP geliefert — Sie können ihn auditieren, die Hooks erweitern oder das Verhalten anpassen (z.B. andere zur Öffnung von Adminer autorisierte Profile hinzufügen).

Adminer selbst steht unter Apache 2.0 / GPL 2.0 Doppellizenz, erstellt von Jakub Vrana. Die gebündelte adminer.php-Datei ist die unveränderte stabile Version 5.4.2 — Sie können sie durch jede kompatible Adminer-Version unter Beachtung der Originallizenz ersetzen.

Support

Der Support ist 12 Monate nach dem Kauf inklusive (24h Werktage, FR/EN). Bei Fragen:

• E-Mail: support bei datafirefly.com
• Kundenbereich: datafirefly.com/de/mein-konto

Geben Sie bei Bugs oder Weiterentwicklungsanfragen bitte Ihre PrestaShop-Version, PHP-Version, Ihren Hoster und die installierte Modulversion an.