Database Manager Back Office: Adminer dla PrestaShop, instalacja, konfiguracja, rozwiązywanie problemów

Moduł Database Manager Back Office (referencja wewnętrzna dfdbmanager) integruje Adminer 5.4.2 bezpośrednio z back office PrestaShop 8 i 9. Koniec z cPanelem i zewnętrznym phpMyAdmin: jedno kliknięcie w menu Parametry zaawansowane > Adminer i zarządzasz swoją bazą danych, już uwierzytelniony.

Wymagania

• PrestaShop: 8.0.0 do 9.99.99 (testowane na 8.0, 8.1, 8.2, 9.0)
• PHP: 7.4 lub nowsze (zgodne z 8.0, 8.1, 8.2, 8.3)
• Baza danych: MySQL 5.7+ lub MariaDB 10.3+
• Konto pracownika: profil SuperAdmin (id_profile = 1), aby otworzyć Adminera
• Hosting: zgodny ze współdzielonym (o2switch, OVH, Infomaniak), VPS, dedykowanym

Żadne połączenie wychodzące z Twojego serwera nie jest wymagane: Adminer 5.4.2 jest dołączony do pliku ZIP modułu (508 KB, pojedynczy plik).

Instalacja

1. Wgranie ZIP

W back office PrestaShop:

1. Przejdź do Moduły > Menedżer modułów
2. Kliknij Zainstaluj moduł u góry po prawej
3. Przeciągnij i upuść plik dfadminer-1.0.0.zip albo kliknij, aby go wybrać
4. Poczekaj na zakończenie wgrywania (kilka sekund, ZIP waży mniej niż 400 KB)
5. Moduł instaluje się automatycznie

2. Weryfikacja zakładki menu

Instalacja tworzy automatycznie zakładkę menu w Parametry zaawansowane > Adminer, z ikoną Material storage. Zakładka jest tworzona w pięciu językach (francuski, angielski, hiszpański, niemiecki, włoski), a wyświetlany będzie język aktywny dla Twojego profilu pracownika.

Pierwszy dostęp do Adminera

Otwarcie menu

Przejdź do Parametry zaawansowane > Adminer. Lądujesz od razu na liście tabel swojej bazy PrestaShop, bez ekranu uwierzytelnienia i bez formularza do wypełnienia.

Strona składa się z:

• Stałego banera u góry, w ciemnym granacie, z nazwą bazy po lewej i niebieskim przyciskiem Back to PrestaShop BO po prawej
• Interfejsu Adminera poniżej: sidebar z tabelami po lewej, treść główna po prawej

Automatyczne logowanie: jak to działa

Moduł odczytuje dane dostępowe bazy z konfiguracji PrestaShop (stałe _DB_SERVER_, _DB_USER_, _DB_PASSWD_, _DB_NAME_ zdefiniowane w config/parameters.php albo config/settings.inc.php) i uruchamia sesję Adminera po stronie serwera z tymi danymi, zanim Adminer się załaduje. Żadne nowe hasło nie jest tworzone, żadne uprawnienie MySQL nie jest rozszerzane: Adminer używa dokładnie tych samych praw co PrestaShop.

Strona konfiguracji modułu

W Moduły > Menedżer modułów wyszukaj Database Manager Back Office i kliknij Konfiguruj. Strona zawiera trzy sekcje.

Status

Wyświetla:

• Wersję Adminera zainstalowaną lokalnie (domyślnie 5.4.2)
• Ścieżkę pliku adminer.php w module
• Zainstalowany wariant (pełny Adminer albo Adminer Editor)
• Rozmiar pliku

Aktualizacja Adminera

Gdy na adminer.org ukaże się nowa stabilna wersja Adminera, możesz pobrać ją bezpośrednio z tej strony. Kliknij Update to latest Adminer: moduł pobiera plik z adminer.org/latest-en.php przez cURL (albo file_get_contents jako fallback) i podmienia plik lokalny.

Przełączenie na Adminer Editor

Adminer publikuje też wariant Editor: interfejs jest identyczny, ale pole wykonywania surowego SQL zostało usunięte. Dostępna pozostaje wyłącznie nawigacja po tabelach i edycja wierszy. Przydatne, jeśli chcesz dać dostęp mniej technicznemu profilowi bez ryzyka, że wykona dowolny SQL.

Kliknij Switch to Adminer Editor, aby pobrać i podmienić plik. Do pełnego Adminera możesz wrócić w każdej chwili przyciskiem Switch back to full Adminer.

Model bezpieczeństwa

Ograniczenie do SuperAdmina

Adminer to potężne narzędzie: kto ma dostęp do Twojej bazy, ma dostęp do wszystkiego (zamówienia, klienci, płatności, zahaszowane hasła pracowników). Dlatego moduł ogranicza dostęp wyłącznie do profilu SuperAdmin, czyli id_profile = 1 w PrestaShop.

Pozostałe profile (Logistyk, Tłumacz, Sprzedawca, profile własne) otrzymują komunikat Access Denied przy próbie otwarcia Adminera, nawet jeśli znają adres URL.

Podwójna weryfikacja serwerowa

Ograniczenie jest stosowane dwukrotnie po stronie serwera w kontrolerze:

• W postProcess(), zanim Adminer się uruchomi
• W initContent(), przy renderowaniu UI fallback

Ta podwójna weryfikacja gwarantuje, że żadna ścieżka kodu nie ominie bramki, nawet przy nieoczekiwanym zachowaniu routera PrestaShop.

Blokada bezpośredniego dostępu HTTP do pliku adminer.php

Plik views/adminer/adminer.php jest zablokowany przed bezpośrednim dostępem HTTP przez .htaccess z dyrektywą Require all denied. Próba otwarcia adresu /modules/dfadminer/views/adminer/adminer.php zwraca 403 Forbidden. Jedyną drogą do Adminera jest kontroler PrestaShop, który stosuje bramkę SuperAdmin.

Używanie Adminera z PrestaShop

Przydatne tabele

Kilka tabel często przydatnych przy debugowaniu PrestaShop (prefiks ps_ domyślnie, może się różnić w Twojej instalacji):

• ps_configuration: wszystkie zmienne konfiguracji (klucze i wartości)
• ps_orders: zamówienia
• ps_customer: klienci
• ps_product i ps_product_lang: produkty i ich tłumaczenia
• ps_employee: pracownicy BO
• ps_log: dziennik błędów PrestaShop
• ps_cart i ps_cart_product: koszyki
• ps_specific_price: promocje i reguły cenowe

Wykonanie zapytania SQL

W lewym sidebarze kliknij SQL command. Wpisz zapytanie, kliknij Execute. Adminer wyświetla wynik na dole, z automatyczną paginacją przy dużych wynikach.

Eksport tabeli

Na wybranej tabeli kliknij Export. Adminer proponuje kilka formatów: SQL (z danymi lub bez), CSV, TSV. Przy bardzo dużych tabelach eksport odbywa się strumieniowo w porcjach, bez problemów z pamięcią PHP.

Edycja wiersza w miejscu

Na dowolnej tabeli kliknij Select data, a następnie ołówek po lewej stronie wiersza. Edytujesz wszystkie pola w formularzu i zapisujesz jednym kliknięciem. Adminer sam generuje zapytanie UPDATE.

Wielu pracowników SuperAdmin

Jeśli masz kilku pracowników z profilem SuperAdmin, każdy będzie miał własną niezależną sesję Adminera. Konkretnie:

• Pracownik A otwiera Adminera w swojej przeglądarce, tworzona jest jego sesja adminer_sid
• Pracownik B robi to samo u siebie, tworzona jest jego własna sesja adminer_sid
• Obaj mogą nawigować po Adminerze równolegle bez wzajemnych zakłóceń
• Gdy A wyloguje się z BO PrestaShop, jego sesja Adminera pozostaje ważna do zamknięcia przeglądarki (potem wygasa)

Wszyscy pracownicy łączą się z tą samą bazą tymi samymi systemowymi danymi dostępowymi: nie ma osobnych kont Adminera do zarządzania.

Aktualizacja modułu

Aby zaktualizować moduł do nowszej wersji:

1. Pobierz nowy ZIP ze swojego konta klienta DataFirefly
2. W BO przejdź do Moduły > Menedżer modułów
3. Kliknij Zainstaluj moduł i wgraj nowy ZIP
4. PrestaShop wykrywa, że wersja już istnieje, i proponuje aktualizację
5. Potwierdź: moduł zostaje zaktualizowany bez utraty konfiguracji

Ponieważ żadna tabela nie jest tworzona, między wersjami nie ma migracji schematu do obsłużenia.

Deinstalacja

Aby czysto odinstalować moduł:

1. Przejdź do Moduły > Menedżer modułów
2. Znajdź Database Manager Back Office
3. Kliknij Odinstaluj w rozwijanym menu

Deinstalacja:

• Usuwa zakładkę menu Parametry zaawansowane > Adminer
• Wycofuje pliki modułu (łącznie z dołączonym plikiem adminer.php)
• Nie rusza żadnej tabeli: Twoja baza PrestaShop pozostaje nietknięta
• Nie modyfikuje żadnej konfiguracji PrestaShop, żadnego hasła, żadnego uprawnienia

Deinstalacja jest w pełni odwracalna: zainstaluj moduł ponownie, aby odzyskać Adminera w tym samym stanie.

Rozwiązywanie problemów

Zamiast listy tabel wyświetla się ekran uwierzytelnienia Adminera

Objaw: otwierasz menu Adminer i widzisz formularz Authentication Adminera (pola System, Server, Username, Password, Database) zamiast listy tabel.

Prawdopodobna przyczyna: stare cookie Adminera (z poprzedniej instalacji albo z innej witryny z Adminerem) koliduje ze wstępnie wypełnioną sesją.

Rozwiązanie:

1. Otwórz DevTools przeglądarki (F12)
2. Przejdź do zakładki Application (Chrome) albo Storage (Firefox)
3. W sekcji Cookies wybierz swoją domenę
4. Usuń cookies o nazwach adminer_sid, adminer_permanent, adminer_key i adminer_version
5. Przeładuj stronę Adminera przez Ctrl+Shift+R

Błąd 403 Forbidden przy ładowaniu

Objaw: strona Adminera zwraca status HTTP 403, czasem z widocznym poniżej formularzem uwierzytelnienia.

Prawdopodobna przyczyna: Adminer nie rozpoznaje wstępnie wypełnionej sesji i wchodzi w swoją ścieżkę kodu auth_error, która jawnie dodaje HTTP/1.1 403 Forbidden, gdy $_GET[username] jest ustawione, ale uwierzytelnienie zawodzi.

Rozwiązanie: ta sama procedura co wyżej, wyczyść cookies Adminera w przeglądarce. Jeśli problem nie ustępuje, sprawdź, czy dane dostępowe PrestaShop w config/parameters.php (PS9) albo config/settings.inc.php (PS8) są poprawne i czy PrestaShop faktycznie łączy się z MySQL (czy BO PrestaShop działa normalnie?).

Linki Adminera odsyłają do pulpitu PrestaShop

Objaw: klikasz nazwę tabeli w sidebarze Adminera i trafiasz na pulpit PrestaShop zamiast na stronę tabeli.

Prawdopodobna przyczyna: post-processing adresów URL (który wstrzykuje controller=AdminDfAdminer do wewnętrznych adresów Adminera) nie zadziałał. Najczęściej: cache HTML albo pośredniczące proxy serwujące nieaktualną wersję strony.

Rozwiązanie:

1. Wyczyść cache PrestaShop (Parametry zaawansowane > Wydajność > Wyczyść cache)
2. Wyczyść cache przeglądarki (Ctrl+Shift+R)
3. Jeśli przed witryną stoi CDN albo cache HTTP (Cloudflare, Varnish), wyczyść jego cache dla adresów /admin*/index.php

Tryb ciemny: baner albo Adminer się nie dostosowują

Baner modułu dostosowuje się automatycznie do systemowego trybu ciemnego przez media query @media (prefers-color-scheme: dark). Adminer 5 ma też własny wbudowany tryb ciemny, który podąża za tą samą preferencją systemową.

Jeśli wygląd nie podąża za trybem systemowym:

• Sprawdź, czy Twój system operacyjny faktycznie jest w trybie ciemnym (Windows: Ustawienia > Personalizacja > Kolory > Tryb ciemny; macOS: Preferencje systemowe > Ogólne > Wygląd: Ciemny)
• Przeglądarka musi przekazywać tę preferencję. Domyślnie Chrome i Firefox to robią, ale niektóre rozszerzenia do zarządzania motywami mogą ją nadpisywać
• Sprawdź w DevTools przez Rendering > Emulate CSS media feature prefers-color-scheme, czy preferencja jest ustawiona na dark

Invalid Security Token przy akcji Adminera

Objaw: wykonujesz zapytanie SQL albo edytujesz wiersz, a PrestaShop wyświetla Invalid Security Token.

Prawdopodobna przyczyna: ten komunikat normalnie nigdy nie pojawia się przy module, ponieważ kontroler nadpisuje checkToken(), aby ominąć CSRF PrestaShop na wewnętrznych akcjach Adminera. Jeśli go widzisz, to znaczy, że wchodzisz na adres, który nie przechodzi przez nasz kontroler.

Rozwiązanie: sprawdź, czy adres w pasku przeglądarki zaczyna się od index.php?controller=AdminDfAdminer&token=.... Jeśli zaczyna się od index.php?select=... bez parametru controller, post-processing adresów został ominięty. Wyczyść cache PrestaShop i przeglądarki, a następnie otwórz Adminera ponownie z menu.

Architektura techniczna

Dla deweloperów i ciekawych administratorów, którzy chcą zrozumieć wewnętrzne działanie modułu.

Automatyczne logowanie: wstępne wypełnienie sesji

Loader views/adminer/loader.php uruchamia sesję Adminera, zanim załaduje się adminer.php:

1. Zamyka wszelką bieżącą sesję PHP przez session_write_close() (PS9 mógł uruchomić własną przez Symfony)
2. Uruchamia nową sesję z session_name('adminer_sid')
3. Wstępnie wypełnia $_SESSION[pwds][server][host][user] prawdziwym hasłem bazy, odczytanym z _DB_PASSWD_
4. Wstępnie wypełnia $_SESSION[db][server][host][user][dbname] = true
5. Ustawia $_GET[username], $_GET[db], $_GET[server] na wartości PrestaShop
6. Ładuje adminer.php

Gdy Adminer się inicjalizuje, widzi, że stała SID jest już zdefiniowana, i pomija własne session_start(). Widzi niepustą $_SESSION[pwds] i pomija odtwarzanie z trwałego cookie. Weryfikacja uwierzytelnienia przechodzi wprost, Driver::connect() używa prawdziwego hasła przez metodę credentials() naszej klasy, a login() zwraca true.

Ominięcie CSRF PrestaShop

Wewnętrzne formularze POST Adminera (wykonanie zapytania SQL, edycja wiersza, usunięcie tabeli) nie niosą tokenu CSRF per kontroler PrestaShop. Bez interwencji PS odrzuca te żądania ekranem Invalid Security Token.

Kontroler AdminDfAdminerController nadpisuje metodę checkToken(), aby zwracała true bez weryfikacji. Jest to bezpieczne, ponieważ bramka SuperAdmin (id_profile === 1) powyżej jest ściśle silniejsza niż token CSRF: atakujący, który ma już przejętą sesję SuperAdmina, i tak ma dostęp do całego back office.

Przepisywanie adresów URL Adminera

Adminer buduje wewnętrzne linki w postaci index.php?select=table_name&db=ps. Bez przepisania te adresy nie niosą controller=AdminDfAdminer i PrestaShop kierowałby je do pulpitu.

Kontroler wywołuje ob_start() z callbackiem, który przetwarza wyjście HTML Adminera: wstrzykuje baner powrotu do BO na początku body i przepisuje wszystkie atrybuty href, action i src wskazujące na index.php?..., dodając do nich controller=AdminDfAdminer& zaraz po znaku ?.

Odporność na wywołania exit Adminera

Adminer wykonuje 19 wywołań exit; w różnych miejscach (page_footer, serwowanie zasobów przez file=, zakończenie błędu). Zwykłe ob_get_clean() na końcu kontrolera nigdy nie zostałoby w tych przypadkach osiągnięte.

Rozwiązanie: przekazać callback post-processingu bezpośrednio do ob_start(). Callback jest wywoływany automatycznie przez PHP w momencie końcowego flushu bufora, nawet jeśli wywołano exit;. Całe wyjście Adminera przechodzi więc przez post-processing, bez wyjątku.

Zgodność z PrestaShop 9

Moduł jest testowany na PrestaShop 8.0, 8.1, 8.2 i 9.0. Zgodność z PS 9 osiągnięto, używając wyłącznie wzorców legacy wspieranych przez obie wersje:

• ModuleAdminController zamiast kontrolerów Symfony, wspierany w PS 8 i PS 9
• Smarty dla szablonu konfiguracji, wspierany natywnie
• Instalacja zakładki przez klasę Tab, API stabilne między wersjami
• Brak specyficznych klas Symfony, brak wymaganego bundle
• Autoload PSR-4 bez Composera (ładowany przez require_once w głównym pliku modułu)

Na PS 9 moduł działa bez modyfikacji, bez rekompilacji i bez composer install.

Licencja i kod źródłowy

Moduł DataFirefly jest na licencji komercyjnej (DataFirefly Limited, Irlandia). Kod źródłowy jest dostarczany niezaszyfrowany w pliku ZIP: możesz go audytować, rozszerzać hooki albo dostosować zachowanie (na przykład dodać inne profile uprawnione do otwierania Adminera).

Sam Adminer jest na podwójnej licencji Apache 2.0 i GPL 2.0, autorstwa Jakuba Vrany. Dołączony plik adminer.php to niezmieniona wersja stabilna 5.4.2: możesz podmienić go na dowolną zgodną wersję Adminera z poszanowaniem oryginalnej licencji.

Wsparcie

Wsparcie jest w cenie przez 12 miesięcy po zakupie (24 h robocze, FR i EN). W razie pytań:

• E-mail: support małpa datafirefly.com
• Konto klienta: datafirefly.com/mon-compte

Przy zgłaszaniu błędów lub propozycji rozwoju podaj wersję PrestaShop, wersję PHP, hostingodawcę i zainstalowaną wersję modułu.