Podczas przenoszenia sklepu PrestaShop w wersji 1.7.5.2 na inny serwer możesz natrafić na beznadziejny błąd:
prestashop Notice: tempnam(): file created in the system's temporary directory (...) PrestaShopAutoload.php on line 258
Dodatkowo mimo zmiany ustawień bazy danych w pliku:
./app/config/parameters.php
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/ ):
Link to database cannot be established: SQLSTATE$
Dodatkowo – skasowanie folderów cache:
Tak, dokładnie. Ta wersja PrestaShop ma folder cache w… 2 miejscach – WTF???
./app/cache/ ./var/cache/
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?
Zawartość artykułu
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):
UPDATE `ps_configuration` SET `value` = '2' WHERE `name` = 'PS_SMARTY_FORCE_COMPILE'; UPDATE `ps_configuration` SET `value` = NULL WHERE `name` = 'PS_SMARTY_CACHE';
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:
./app/cache/ ./var/cache/
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:
./var/cache/prod/ContainerCfc1oep/appProdProjectContainer.php ./app/cache/prod/appParameters.php ./app/config/parameters.php
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.
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ę ?
to moze być pomocne @Jacek . Otworz plik:
vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php
Następnie zakomentuj linię 1403 tzn kod:
throw new RuntimeException(sprintf(’Cannot dump definition because of invalid class name (%s)’, $class ?: 'n/a’));
Po tej czynności wejdz w dział Preferencje -> Wydajność i wyczyść cache. po tej czynności jest szansa, że Twoja instalacja PrestaShop zadziała.
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ł.