Press "Enter" to skip to content

PrestaShop 1.7.5.2 – przenosiny na nowy serwer i problemy z bazą danych

Admin 2

Podczas przenoszenia sklepu PrestaShop w wersji 1.7.5.2 na inny serwer możesz natrafić na beznadziejny błąd:

Dodatkowo mimo zmiany ustawień bazy danych w pliku:

Nadal są zaczytywane stare dostępy i zgłaszany jest problem (błąd 500) z połączeniem z bazą danych (można go znaleźć w logach w var/logs/ ):

Dodatkowo – skasowanie folderów cache:

Tak, dokładnie. Ta wersja PrestaShop ma folder cache w… 2 miejscach – WTF???

Nic nie daje – nowe ustawienia bazy nie są odbudowywane i jesteśmy atakowani całą serią błędów z nieudaną próbą przenoszenia plików z folderów /tmp…

Jak naprawić taki bajzel?

Po pierwsze: kompilacja szablonu.

Wyłącz od strony bazy cacheowanie szablonu (wymuś kompilację szablonu i wyłącz cache). Chodzi o opcje w dziale “Wydajność“. Co prawda może być to już wyłączone – ale lepiej mieć pewność.

Uruchom następujące zapytania w SQL (np. w PHPMYADMIN):

Po drugie: dostępy do bazy danych w.. plikach cache.

Ostatecznym rozwiązaniem problemu będzie ręczne poprawienie dostępów do bazy danych w plikach cache ze starego serwera i w pliku konfiguracyjnym (tak dla pewności). Jest to dość absurdalne – foldery cache powinny się wygenerować na nowo po przebudowaniu strony. Tak jak to miało miejsce w poprzednich wersjach PS albo w innych systemach CMS.

Wracając do meritum – musisz na nowy serwer przegrać zawartość folderów:

Po czym otwórz każdy z poniższych plików i upewnij się że są w nich podane aktualne połączenia z bazą danych:

Uwaga! W 1 pliku z tej listy – dane do łączenia z bazą danych są podane 2-krotnie. Zmień to w obu miejscach.

Przy odrobinie szczęścia – powinno Ci się udać okiełznać ten problem. Napisz w komentarzu czy to pomogło!

Postscriptum

Niestety ta wersja PrestaShop wygląda na niedopracowaną pod tym względem. Pokutuje tutaj niestety (moim zdaniem) wdrożenie w jądro PS źródeł Symfony Framework. Co prawda poprawiło to w wielu miejscach wydajność, jednak budowanie cache w dwóch odrębnych ścieżkach jest dość kuriozalne… Do tego nieodbudowywanie folderów cache – jest fatalną niedoskonałością.

Było to testowane przez nasz zespół na 2 różnych (wiodących w PL) serwerowniach w Polsce i w obu miejscach pojawiał się ten błąd.

Migracja w starszych wersjach nie była narażona na takie trudności. Przypadek ??

Na tak dziwne zachowanie skryptu może mieć też wpływ wykonanie (na tym akurat sklepie) aktualizacji z wersji 1.7.3 =====> 1.7.5.2. Jednak nie zmienia to faktu, że problem jest co najmniej dziwny.

  1. Jacek Jacek

    Witam,
    Dziękuję za ciekawy wpis. Prawie się udało tzn. Po przeniesieniu sklepu ale w wersji 1.7.3.3 na inny serwer sklep od frontu działa poprawnie, natomiast na zapleczu kiedy wchodzę w moduły pojawia się błąd 500 – reszta zaplecza działa poprawnie. Gdy włączam tryb debugowania to mam błąd:

    Whoops, looks like something went wrong.
    1/1
    RuntimeException in PhpDumper.php line 1403:
    Cannot dump definition because of invalid class name (NULL)
    in PhpDumper.php line 1403
    at PhpDumper->dumpLiteralClass(‘NULL’) in PhpDumper.php line 790
    at PhpDumper->addNewInstance(‘_defaults’, object(Definition), ‘return ‘, ‘$this->services[‘_defaults’] = ‘) in PhpDumper.php line 394
    at PhpDumper->addServiceInstance(‘_defaults’, object(Definition)) in PhpDumper.php line 639
    at PhpDumper->addService(‘_defaults’, object(Definition)) in PhpDumper.php line 666
    at PhpDumper->addServices() in PhpDumper.php line 145
    at PhpDumper->dump(array(‘class’ => ‘appDevDebugProjectContainer’, ‘base_class’ => ‘Container’, ‘namespace’ => ”, ‘debug’ => true, ‘file’ => ‘/home/xxx/domains/xxx/public_html/app/cache/dev/appDevDebugProjectContainer.php’)) in bootstrap.php.cache line 2846
    at Kernel->dumpContainer(object(ConfigCache), object(ContainerBuilder), ‘appDevDebugProjectContainer’, ‘Container’) in bootstrap.php.cache line 2759
    at Kernel->initializeContainer() in bootstrap.php.cache line 2533
    at Kernel->boot() in bootstrap.php.cache line 2564
    at Kernel->handle(object(Request), ‘1’, false) in index.php line 86

    I taka ciekawostka nie mam ./var/cache/ ale pod starą domeną także nie ma i jest OK, nie ma problemu z modułami na zapleczu.
    Prawdopodobnie to nadal problem cache ale nie mam już pomysłu…
    Może masz jakąś wskazówkę ?

  2. Jakub Jakub

    Mega rozkmina przenosiłem 1.7.5 na home.pl (tak wiem co mi tu napiszecie – klient nie da się przekonać), u mnie wersja php na 7.1 po przenosinach sklep wstał ale bez panelu, po usunięciu cache z 2 lokalizacji – rzeczywiście śmiechowo 🙂 panel wstał z dziurami ale wstał.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

Zobacz także !
Skąd wziąć oficjalny moduł do aktualizacji od PrestaShop ? Jeśli…