Połączenie baza danych prestashop: zmień bezpiecznie

Po przeniesieniu na inny hosting lub zmianie danych logowania PrestaShop nadal odczytuje ustawienia MySQL z pliku konfiguracyjnego – nie z Back Office. Gdy host, nazwa bazy, użytkownik lub hasło nie odpowiadają serwerowi, sklep i panel administracyjny przestają się ładować. Ten przewodnik pokazuje, jak bezpiecznie zmienić połączenie baza danych prestashop, wyczyścić cache, który może trzymać stare wartości, i sprawdzić typowe komunikaty błędów.

Od PrestaShop 1.7 (w tym wersji 8 i 9) ustawienia połączenia z bazą danych znajdują się w app/config/parameters.php. Starsze sklepy 1.5 – 1.6 korzystają z config/settings.inc.php. Oficjalne informacje o tym pliku są w dokumentacji deweloperskiej PrestaShop 9 (parameters.php). Błędne wartości wyłączają sklep z sieci, więc przed edycją warto wykonać pełną kopię zapasową PrestaShop.

Kiedy trzeba zmienić połączenie baza danych prestashop

Te ustawienia zwykle edytuje się, gdy:

• Sklep został przeniesiony na nowy hosting lub VPS i dostawca podał nowy host, nazwę bazy, użytkownika lub hasło.
• W panelu zmieniono nazwę bazy lub zaktualizowano hasło MySQL.
• Pliki zostały przywrócone na serwer, który ma inną bazę danych.
• Front lub Back Office po przeniesieniu pokazuje błąd połączenia z bazą lub „access denied”.

Ten plik nie służy do zmiany nazw produktów, adresu e-mail sklepu ani naprawy przyjaznych URL SEO. To osobne ekrany. Gdy sklep działa i potrzebna jest tylko bezpieczniejsza kopia przed migracją, warto zacząć od powyższego przewodnika o kopii zapasowej.

PrestaShop 1.7, 8 i 9 – edycja parameters.php

Aby zmienić połączenie baza danych prestashop w nowoczesnym sklepie, należy użyć SFTP, SSH lub menedżera plików hostingu. Jeśli to możliwe, pracuje się na kopii, a na żywo podmienia plik jednym krokiem.

1. Otwórz katalog główny sklepu i przejdź do app/config/parameters.php.
2. Pobierz kopię na komputer (zabezpieczenie przed cofnięciem zmian).
3. Znajdź klucze tablicy parameters: database_host, database_port, database_name, database_user i database_password.
4. Zastąp tylko te wartości danymi z nowego hostingu (lub nowym hasłem). Klucz database_prefix pozostaw bez zmian, chyba że faktycznie zmieniono prefiks wszystkich tabel.
5. Zapisz plik i prześlij go z powrotem z tymi samymi uprawnieniami co wcześniej.
6. Wyczyść cache Symfony/PrestaShop (następna sekcja), potem otwórz front i Back Office w trybie prywatnym przeglądarki.

Nazwy hosta zależą od dostawcy: localhost, 127.0.0.1, zdalna nazwa hosta lub czasem ścieżka socketu. Warto skopiować ciąg hosta z panelu dokładnie – bez zgadywania. database_port pozostaw pusty, gdy panel nie podaje portu innego niż domyślny; ustaw go (często 3306) tylko wtedy, gdy hosting wymaga tego wyraźnie.

Przykładowa struktura (same placeholdery – nigdy wklejaj przykładowych haseł na produkcji):

<?php
return array (
  'parameters' =>
  array (
    'database_host' => '127.0.0.1',
    'database_port' => '',
    'database_name' => 'your_database_name',
    'database_user' => 'your_database_user',
    'database_password' => 'your_database_password',
    'database_prefix' => 'ps_',
    'database_engine' => 'InnoDB',
    // … pozostałe klucze zostaw jak w sklepie - nie wymyślaj nowych wartości secret/cookie
  ),
);

Zmieniaj tylko klucze bazy podane przez hosting. Modyfikacja secret, cookie_key lub cookie_iv wyloguje wszystkich i może zepsuć sesje – to inna ścieżka odzyskiwania. Poprawne połączenie baza danych prestashop w tym pliku nie zadziała, dopóki nie wyczyści się cache (poniżej).

Wyczyść /var/cache po zapisaniu pliku

PrestaShop trzyma skompilowaną konfigurację w cache. Gdy połączenie baza danych prestashop zostało zaktualizowane w pliku, należy usunąć cache w /var/cache/ – głównie foldery dev i prod (i podobne foldery środowisk, jeśli są). Usuwa się te foldery lub ich zawartość – nie cały sklep i nie niepowiązane katalogi obok var.

Back Office działa, front nie? Po zmianie połączenia z bazą ten podział prawie zawsze oznacza stary cache – najpierw wyczyść var/cache, zanim zaczniesz szukać przyczyn w motywach, modułach lub URL sklepu.

Foldery dev i prod mogą być ogromne (dziesiątki tysięcy małych plików). Lepiej użyć menedżera plików hostingu lub SSH do usunięcia lub opróżnienia. Zwykły FTP często przetwarza pliki pojedynczo i może zająć godziny. Gdy dostępny jest tylko FTP, warto zmienić nazwę prod / dev (np. na prod_old / dev_old), aby PrestaShop od razu utworzył puste foldery, a stare drzewa usunąć później, gdy będzie czas lub lepsze narzędzie.

1. Z katalogu głównego sklepu otwórz var/cache/.
2. Usuń lub zmień nazwę prod i dev (i inne foldery środowisk, jeśli są widoczne).
3. Gdy PHP-FPM działa pod innym użytkownikiem, w razie potrzeby utwórz puste foldery prod / dev, aby serwer WWW mógł ponownie zapisywać pliki.
4. Odśwież sklep. Pierwsze ładowanie może być wolniejsze podczas przebudowy cache.

Gdy Parametry zaawansowane → Wydajność jest dostępne, cache można wyczyścić też z Back Office – ale przy niepoprawnym połączenie baza danych prestashop logowanie często nie działa, więc czyszczenie na poziomie plików jest pewniejszą ścieżką.

Gdy połączenie baza danych prestashop nadal nie działa

Przed ponowną edycją całego pliku warto przejść te kontrole:

• Access denied (Odmowa dostępu). Błędny użytkownik lub hasło, albo użytkownik MySQL nie ma uprawnień z tego hosta. Hasło resetuje się w panelu i wkleja ostrożnie (bez spacji na końcu ani „smart quotes” z komunikatora).
• Unknown database (Nieznana baza danych). database_name nie odpowiada rzeczywistej nazwie schematu po przeniesieniu.
• Cannot connect to server (Brak połączenia z serwerem). Błędny database_host lub port, firewall albo usługa bazy jest wyłączona. Warto potwierdzić dane w phpMyAdmin lub narzędziu MySQL hostingu.
• Niezgodny prefiks. Tabele istnieją, ale mają inny prefiks niż database_prefix – sklep łączy się, potem wygląda na pusty lub zgłasza brak tabel.
• Pusta strona / WSOD. Błąd składni w parameters.php (brakujący cudzysłów lub przecinek) może dać biały ekran. Przywróć pobraną kopię i edytuj ponownie. Nasz przewodnik o białym ekranie śmierci opisuje tryb debug, gdy plik jest poprawny, ale coś innego zawodzi.

Centrum pomocy PrestaShop opisuje ten sam wzorzec błędu połączenia i klucze do weryfikacji w parameters.php – przydatne, gdy panel używa innych sformułowań: Database connection error for your PrestaShop store.

Starsze PrestaShop 1.5 – 1.6 – settings.inc.php

Gdy sklep nadal działa na 1.5 lub 1.6, otwórz config/settings.inc.php i zaktualizuj:

• _DB_SERVER_ (host)
• _DB_NAME_
• _DB_USER_
• _DB_PASSWD_

_DB_PREFIX_ pozostaw bez zmian, chyba że tabele zostały przeniesione pod inny prefiks. Zapisz, prześlij plik, potem wyczyść foldery cache używane w tej wersji (często pod cache/). Ta sama zasada: złe hasło wyłącza sklep – i błędne połączenie baza danych prestashop tutaj zawiedzie tak samo jak w nowszych wersjach.

Krótka lista kontrolna

1. Kopia zapasowa plików i bazy.
2. Zmień połączenie baza danych prestashop w app/config/parameters.php (1.7+) lub config/settings.inc.php (1.5 – 1.6).
3. Ustawienie hosta, portu (jeśli wymagany), nazwy, użytkownika i hasła zgodnie z panelem.
4. Wyczyszczenie var/cache (lepiej menedżer plików lub SSH; przy FTP czasem zmiana nazwy zamiast usuwania).
5. Test frontu i Back Office; gdy panel działa, a front nie – ponowne czyszczenie cache przed innymi przyczynami. Gdy oba nie działają, dopasuj błąd do access denied / unknown DB / host unreachable, zanim zmienisz inne klucze.

Gdy połączenie baza danych prestashop znów działa, na nowym hostingu dokończ listę migracji (domena sklepu, SSL, poczta) – same ustawienia połączenia nie aktualizują tych elementów.