Prestashop 1.7 błąd przy zmianie serwera BO = ContextErrorException + dev.log = doctrine.debug select from ps_lang

[qnev]

Witam wszystkich, od kilku dni walczę z uruchomieniem mojego sklepu na hostingu Cyberfolks'owym.

Ogólnie rozchodzi się o to, że na lokalnej wersji na serwerze WAMP sklep działa, natomiast po przerzuceniu go na serwer współdzielony pojawiają się poniższe błędy i od kilku dni próbuję wszystkiego co mi do głowy przychodzi niestety z mizernym skutkiem.

Lista rzeczy, które próbowałem:

- różne wersje PHP

- zwiększenie parametrów serwera typu memory_limit, generalnie phppsinfo.php zwraca wszystkie parametry na zielono, od strony konfiguracji niby wszystko jest zapewnione

- wcześniej błąd wskazywał na brak kolumny locale tabeli ps_lang, tą tabele zaimportowałem osobno

- założyłem nawet kopie sklepu lokalnie (WAMP) i działa 

- miałem też problem z wgraniem plików na sewer, błąd przy rozpakowywaniu archiwum zip, finalnie rozpakowywałem katalog przez SSH

- plik, na który wskazuje błąd czyli Regexp.php istnieje w podanej ścieżce

- wyłączałem moduły wszystkie, wyłączałem też szablon, admin dalej leżał

Błędy związane z tabelą ps_lang wskazują, że może coś jest nie tak z wersją językową, tłumaczeniami?

Zamieściłem poniżej komunikaty błędów, które mogą pomóc w określeniu, w którą stronę drążyć dalej temat.

Debugger w BO (https://nazwadomeny/admin1) zwraca:

(1/1) ContextErrorException
Warning: include(tutaj-sciezka-do-katalogu/public_html/vendor/composer/../beberlei/doctrineextensions/src/Query/Mysql/Regexp.php): failed to open stream: No such file or directory

in DebugClassLoader.php line 155
at include()
in DebugClassLoader.php line 155
at DebugClassLoader->loadClass('DoctrineExtensions\\Query\\Mysql\\Regexp')
at spl_autoload_call('DoctrineExtensions\\Query\\Mysql\\Regexp')
in Parser.php line 3541
at Parser->CustomFunctionsReturningStrings()
in Parser.php line 3414
at Parser->CustomFunctionDeclaration()
in Parser.php line 3378
at Parser->FunctionDeclaration()
in Parser.php line 2851
at Parser->ArithmeticPrimary()
in Parser.php line 2812
at Parser->ArithmeticFactor()
in Parser.php line 2780
at Parser->ArithmeticTerm()
in Parser.php line 2754
at Parser->SimpleArithmeticExpression()
in Parser.php line 2741
at Parser->ArithmeticExpression()
in Parser.php line 3072
at Parser->ComparisonExpression()
in Parser.php line 2605
at Parser->SimpleConditionalExpression()
in Parser.php line 2486
at Parser->ConditionalPrimary()
in Parser.php line 2462
at Parser->ConditionalFactor()
in Parser.php line 2435
at Parser->ConditionalTerm()
in Parser.php line 2405
at Parser->ConditionalExpression()
in Parser.php line 1373
at Parser->WhereClause()
in Parser.php line 893
at Parser->SelectStatement()
in Parser.php line 860
at Parser->QueryLanguage()
in Parser.php line 273
at Parser->getAST()
in Parser.php line 372
at Parser->parse()
in Query.php line 287
at Query->_parse()
in Query.php line 299
at Query->_doExecute()
in AbstractQuery.php line 1000
at AbstractQuery->executeIgnoreQueryCache(null, 1)
in AbstractQuery.php line 954
at AbstractQuery->execute(null, 1)
in AbstractQuery.php line 757
at AbstractQuery->getResult()
in DatabaseTranslationLoader.php line 92
at DatabaseTranslationLoader->load('AdminActions.pl-PL.db', 'pl-PL', 'AdminActions')
in Translator.php line 385
at Translator->doLoadCatalogue('pl-PL')
in Translator.php line 277
at Translator->initializeCatalogue('pl-PL')
in Translator.php line 128
at Translator->initializeCatalogue('pl-PL')
in Translator.php line 314
at Translator->dumpCatalogue('pl-PL', object(ResourceCheckerConfigCache))
in Translator.php line 299
at Translator->Symfony\Component\Translation\{closure}(object(ResourceCheckerConfigCache))
in ResourceCheckerConfigCacheFactory.php line 43
at ResourceCheckerConfigCacheFactory->cache('tutaj-sciezka-do-katalogu/public_html/var/cache/dev/translations/catalogue.pl-PL.L8dqxxF.php', object(Closure))
in Translator.php line 300
at Translator->initializeCacheCatalogue('pl-PL')
in Translator.php line 265
at Translator->loadCatalogue('pl-PL')
in Translator.php line 241
at Translator->getCatalogue('pl-PL')
in Translator.php line 198
at Translator->trans('Successful deletion.', array(), 'AdminNotificationsSuccess', null)
in PrestaShopTranslatorTrait.php line 61
at Translator->trans('Successful deletion.', array(), 'AdminNotificationsSuccess', null)
in LoggingTranslator.php line 47
at LoggingTranslator->trans('Successful deletion.', array(), 'AdminNotificationsSuccess', null)
in DataCollectorTranslator.php line 50
at DataCollectorTranslator->trans('Successful deletion.', array(), 'AdminNotificationsSuccess', null)
in PrestaShopTranslatorTrait.php line 61
at DataCollectorTranslator->trans('Successful deletion.', array(), 'Admin.Notifications.Success', null)
in Controller.php line 338
at ControllerCore->trans('Successful deletion.', array('legacy' => 'htmlspecialchars'), 'Admin.Notifications.Success')
in AdminController.php line 481
at AdminControllerCore->__construct()
in LegacyContext.php line 86
at LegacyContext->getContext()
in UserLocaleListener.php line 39
at UserLocaleListener->__construct(object(LegacyContext))
in appDevDebugProjectContainer.php line 3848
at appDevDebugProjectContainer->getPrestashop_UserLocale_ListenerService()
in appDevDebugProjectContainer.php line 4377
at appDevDebugProjectContainer->Container7ohiaop\{closure}()
in EventDispatcher.php line 231
at EventDispatcher->sortListeners('kernel.request')
in EventDispatcher.php line 61
at EventDispatcher->getListeners('kernel.request')
in ContainerAwareEventDispatcher.php line 129
at ContainerAwareEventDispatcher->getListeners('kernel.request')
in TraceableEventDispatcher.php line 259
at TraceableEventDispatcher->preProcess('kernel.request')
in TraceableEventDispatcher.php line 137
at TraceableEventDispatcher->dispatch('kernel.request', object(GetResponseEvent))
in HttpKernel.php line 127
at HttpKernel->handleRaw(object(Request), 1)
in HttpKernel.php line 68
at HttpKernel->handle(object(Request), 1, false)
in Kernel.php line 200
at Kernel->handle(object(Request), 1, false)
in index.php line 82

dev.log zwraca:

[2024-04-04 10:38:38] doctrine.DEBUG: SELECT t0.id_lang AS id_lang_1, t0.name AS name_2, t0.active AS active_3, t0.iso_code AS iso_code_4, t0.language_code AS language_code_5, t0.locale AS locale_6, t0.date_format_lite AS date_format_lite_7, t0.date_format_full AS date_format_full_8, t0.is_rtl AS is_rtl_9 FROM ps_lang t0 WHERE t0.locale = ? LIMIT 1 ["pl-PL"] []
[2024-04-05 07:29:11] doctrine.DEBUG: SELECT t0.id_lang AS id_lang_1, t0.name AS name_2, t0.active AS active_3, t0.iso_code AS iso_code_4, t0.language_code AS language_code_5, t0.locale AS locale_6, t0.date_format_lite AS date_format_lite_7, t0.date_format_full AS date_format_full_8, t0.is_rtl AS is_rtl_9 FROM ps_lang t0 WHERE t0.locale = ? LIMIT 1 ["pl-PL"] []
[2024-04-07 22:19:07] doctrine.DEBUG: SELECT t0.id_lang AS id_lang_1, t0.name AS name_2, t0.active AS active_3, t0.iso_code AS iso_code_4, t0.language_code AS language_code_5, t0.locale AS locale_6, t0.date_format_lite AS date_format_lite_7, t0.date_format_full AS date_format_full_8, t0.is_rtl AS is_rtl_9 FROM ps_lang t0 WHERE t0.locale = ? LIMIT 1 ["pl-PL"] []

 

Z góry dziękuje za rady.

Edited April 11 by qnev (see edit history)

[adiem]

Front Office działa poprawnie? Łączysz się z serwerem www po IP czy podające domenę? Sprawdziłeś wartości w tabeli (np. dla PS_SHOP_DOMAIN, PS_SHOP_DOMAIN_SSL)?

Sprawdź też uprawnienia dla folderu, gdzie rozpakowałeś sklep.

Przykładowa komenda dla usera www-data:

chown -R www-data: /var/www/moj-sklep/public_html/

 

Edited April 11 by adiem (see edit history)

[qnev]

1 hour ago, adiem said:

Front Office działa poprawnie? Łączysz się z serwerem www po IP czy podające domenę? Sprawdziłeś wartości w tabeli (np. dla PS_SHOP_DOMAIN, PS_SHOP_DOMAIN_SSL)?

Sprawdź też uprawnienia dla folderu, gdzie rozpakowałeś sklep.

Przykładowa komenda dla usera www-data:

chown -R www-data: /var/www/moj-sklep/public_html/

 

dzięki za podpowiedzi

PS_SHOP_DOMAIN i PS_SHOP_DOMAIN_SSL ustawione na właściwą domenę

Front działa normalnie jak defines na false dam, bo tak to NOTICE warning, z stroną łącze się podając domenę

folder gdzie rozpakowałem czyli public_html ma 0711, wewnątrz pliki 0644, a foldery 0755

 

najlepsze jest to, że w google nie znalazłem podobnego problemu, mającego taki sam lub podobny błąd, są braki kolumn ale to po użyciu 1-click upgrade

 

oczywiście  zostaje podrążenie tematu różnicy serwerów, bo na localhoscie działa, na nowej domenie na localu również

 

Edited April 11 by qnev (see edit history)

[endriu107]

Po przeniesieniu wyczyściłeś folder var/cache ?

[qnev]

57 minutes ago, endriu107 said:

Po przeniesieniu wyczyściłeś folder var/cache ?

przed przeniesieniem, po przeniesieniu, wyczyściłem również kaczki przeglądarkowe, chociaż to na taki błąd nie pomaga, ale profilaktycznie...

[qnev]

jeszcze napiszę do hostingodawcy może on coś poradzi, później jak nic nowego do sprawdzenia nie wymyślę, to będę powtarzał wszystko co robiłem do tej pory być może gdzieś mimo wszystko nie dopilnowałem czegoś, w konfiguracji, przy przenoszeniu plików, BD

 

ale jeszcze mnie taka myśl naszła, nie wiem o co chodzi z tym komunikatem który zwracany jest w dev.log:

[2024-04-07 22:19:07] doctrine.DEBUG: SELECT t0.id_lang AS id_lang_1, t0.name AS name_2, t0.active AS active_3, t0.iso_code AS iso_code_4, t0.language_code AS language_code_5, t0.locale AS locale_6, t0.date_format_lite AS date_format_lite_7, t0.date_format_full AS date_format_full_8, t0.is_rtl AS is_rtl_9 FROM ps_lang t0 WHERE t0.locale = ? LIMIT 1 ["pl-PL"] []

dlaczego tu jest po prostu SELECT wypisany, bez wskazania na błąd czy coś, wcześniej jak był problem z brakiem kolumny w tabeli ps_lang, to wyglądało to tak:

(3/3) InvalidFieldNameException
An exception occurred while executing 'SELECT t0.id_lang AS id_lang_1, t0.name AS name_2, t0.active AS active_3, t0.iso_code AS iso_code_4, t0.language_code AS language_code_5, t0.locale AS locale_6, t0.date_format_lite AS date_format_lite_7, t0.date_format_full AS date_format_full_8, t0.is_rtl AS is_rtl_9 FROM ps_lang t0 WHERE t0.locale = ? LIMIT 1' with params ["en"]:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.locale' in 'field list'

po imporcie samej tabeli ps_lang w której była kolumna komunikat zmienił się na ten pierwszy

[adiem]

Sprawdzałeś konfigurację Composera? stawiam, że trzeba zaktualizować ścieżki do prawidłowych lokalizacji plików

[qnev]

2 hours ago, adiem said:

Sprawdzałeś konfigurację Composera? stawiam, że trzeba zaktualizować ścieżki do prawidłowych lokalizacji plików

nie, ale sprawdzę, jedyne ścieżki w plikach jakie aktualizowałem to domenę w .htaccess, ale przed przerzuceniem plików przeszukałem wszystkie pliki żeby sprawdzić czy gdzieś jeszcze domena jest w plikach bo np. tak się robiło w MODX, ale tutaj starą domenę pokazuje tylko w .htaccess

 

jeszcze jedną rzecz sprawdzam, bo najśmieszniejsze jest to, że starszą wersję tego sklepu, nad którym pracuje, mam normalnie działającą na serwerze hostingodawcy, później sobie zgrałem żeby front robić lokalnie, po czym chcę tak naprawdę uaktualnić to co już tam jest, tyle, że na innej domenie

więc te pliki i BD co są i działają, mogę sprawdzić jeszcze stare pliki z nową bazą oraz starą BD z nowymi plikami, może coś mi to podpowie...

 

[qnev]

ehh, no cóż, ile razy miałem już problemy z "wielkością liter", w sensie, że na windows'ie nie patrzy na wielkość liter, a na linux'ie tak

rozwiązanie jak zazwyczaj okazuje się proste i na wyciągnięcie ręki, wiele wiele godzin poświęcone na szukanie nie tam gdzie trzeba

 

po części pomogła mi podpowiedz z composer'em, bo szukając informacji na ten temat, natrafiłem na 

Quote

I'm aware it's rather old, but maybe someone is still looking for a solution to this problem.

In my case it was a bug in PS 1.7.6.9, but I reckon some other versions might have been affected as well. Translations require Regexp.php file, which is located in vendor\beberlei\DoctrineExtensions\src\Query\Mysql, however the correct path is vendor\beberlei\doctrineextensions\src\Query\Mysql. Once I renamed the folder to doctrineextensions all translations magically reappeared 

For us everything was fine on a test server, which was running on Windows, but the live site was on Linux, which is case sensitive.

wtedy mnie olśniło, że co z tego, że sprawdziłem, że plik Regexp.php istnieje, jak przeoczyłem samą ścieżkę

kilka innych informacji namieszało skutecznie, bo w pewnym momencie wykluczyłem też, że to różnica w plikach, porównując foldery z działającego sklepu i niedziałającego, a tutaj taki psikus:

działająca:

niedziałająca:

teraz, w którym momencie nastąpiła ta zmiana nazwy folderu, a w zasadzie kiedy folder się skopiował? nie wiem

sprawdziłem, w 10-02-2024 aktualizowałem prestashop do 1.7.8.11, wtedy powstał folder doctrineextensions

wygląda na to, że później przy zgrywaniu plików i pracy nad nimi na windows'ie, który nie rozróżnia wielkości liter i po prostu dwa foldery się scaliły?