Użytkownicy sklepów PrestaShop 1.7 mogą natrafić na dość nieznośny problem z kodowaniem polskich znaków. Objawia się on „krzaczkami” (czy raczej pytajnikami..) w tekstach na sklepie – opisach produktów, ich nazwach, nazwach kategorii itd.
Tak samo w zapleczu sklepu pojawiają się nieprawidłowości. Wręcz brak jest opcji w menu administracyjnym sklepu. Opisane tutaj błędy mogą sygnalizować błędy w bazie danych, lecz niekoniecznie.
Poniżej poradnik jak można spróbować naprawić te błędy.
Kopia bezpieczeństwa
W myśl hasła „Użytkownicy dzielą się na dwie grupy: ci co robią kopie bezpieczeństwa i ci co jeszcze nie robią kopii bezpieczeństwa…”:
Przed podjęciem zmian wykonaj koniecznie:
1) kopie zapasowe plików (FTP) oraz
2) bazy danych:
Zaawansowane -> Baza danych -> Kopia bazy DB -> Wykonaj kopię
Kodowanie szablonu.
Włącz dowolną podstonę sklepu albo stronę główną i wciśnij: CTRL + U. W źródle strony upewnij się, że w sekcji <HEAD> na początku kodu HTML jest zawarty znacznik określający kodowanie typu:
<meta charset="utf-8">
Ważna jest tutaj wartość atrybutu – musi być ona zdeklarowana jako utf-8
Checklista – sprawdź kodowanie bazy danych.
- Na poziomie tworzenia bazy danych w panelu hostingowym powinna mieć ona kodowanie: UTF8. Skontaktuj się dla pewności w tej sprawie z administatorem serwera.
- W programie PhpMyAdmin wybierz opcję „Databases” i na liście baz danych upewij się czy baza posiada kodowanie UTF8 np. utf8_polish_ci
- Wybierz bazę danych i na liście tabel w kolumnie „Collation” (kodowanie) upewnij się, że tabele też mają kodowanie UFT8 np. utf8_general_ci albo utf8_polish_ci
- Otwórz dowolną tabelę językową np. ps_cms_lang lub pr_product_lang i upewnij się, że teksty w niej zawarte mają polskie znaki diakrytyczne (kliknij „edytuj” na dowolnym wierszu – nic nie zmieniając i nic nie zapisując)
OK – jeśli wszystko się zgadza – baza danych ma prawidłowe kodowanie i nie jest to przyczyną błędów.
Opcjonalnie. Sprawdź jak zapisywany jest tekst z polskimi znakami.
Utwórz nową stronę CMS z tekstem z pl. literami
- Wejdź w dział strony CMS (jeśli nie widzisz go w menu admina sklepu wejdź pod adres: http://{adres-sklepu}.pl/{admin}/index.php?controller=AdminCmsContent&token={token} (Oczywiście w klamrach podaj dane Twojego sklepu).
- Dodaj nową stronę CMS, w jej treści wpisz: „zażółć gęślą jaźń ZAŻÓŁĆ GĘŚLĄ JAŹŃ” (przykładowy tekst sprawdzający wszystkie poliskie litery).
- Jeśli na poziomie bazy danych w programie PhpMyAdmin w tabeli ps_cms_lang zamiast poliskich liter pojawia się niezrozumiały tekst typu „zaşóĹÄ gÄĹlÄ jaźŠZAĹťĂĹÄ GÄĹLÄ” oznacza to błędne kodowanie na poziomie skrytpu i nasz sposób naprawy powinien zadziałać.
Naprawa kodowania na poziomie skryptu (w PHP)
Otwórz plik:
classes/db/DbPDO.php
Znajdź funkcję:
public function connect()
Następnie w okolicach linii 121 przed kodem:
$this->link->exec('SET SESSION sql_mode = \'\'');
Wstaw:
// UTF-8 support
if ($this->link->exec('SET NAMES \'utf8\'') === false) {
throw new PrestaShopException('PrestaShop Fatal error: no utf-8 support. Please check your server configuration.'.$e->getMessage());
}
Daj znać w komentarzu czy u Ciebie to zadziałało 🙂
grafika: Michelle Bodamer, peakpx.com, MichelleBodamer.com
Zadziałało ale np. tytuły stron w zakładce seo&url czy nazwy atrybutów produktu w panalu admin nadal są źle kodowane.
może zostały wprowadzone na złym kodowaniu w skrypcie? wtedy wpisy są błędne i w PHPmyadmin też będą źle wyświetlone. Inna przyczyna to że ich pola w bazie danych mają ustawione złe kodowanie znaków. ciężko powiedzieć.
Przepraszam ale nie jestem na tyle zaawansowany. Co to znaczy na złym kodowaniu w skrypcie ?
U mnie zadziałało. Dzięki 🙂
Super, cały internet nie jest tak dobry jak Autor
Po pierwsze miałem złe kodowanie, dwa mimo zmiany kodowania dalej krzaki.
Na szczęście zmiana w DbPDO.php załatwiła sprawę – dzięki za poradnik!
Świetnie!:-) do usług:)
działa, ale zastanawia mnie gdzie leży faktyczna przyczyna problemu;
mam działający sklep postawiony na hostingu A, chciałem wytestować jak będzie działał na dedykowanym hostingu pod PrestaShop w home (do testów triale 14 dni);
co ciekawe miesiąc temu przerzucałem całą Prestę i wszytko chodziło od strzała;
a dziś po po raz pierwszy zdarzyło mi się, żeby po przeprowadzce wystąpił taki problem z kodowaniem (czyli krzaki zamiast polskich znaków w opisach i nazwach produktów, wybrakowane menu w backoffice);
Migracja z Linux na Home spowodowała taki błąd. Metoda zadziałała!
U mnie ruszyło ale teraz cały panel zarządzania presta nie posiada polskich znaków. Pola np. Płatności, Moduły, Wygląd, Wysyłka są bez polskich znaków. Ponadto przy cenach nie wyświetla się nie wyświetla w „zł” polskich znaków. Za to kategorie i opisy produktów są już wyświetlane poprawnie.
Nie wiem jak to ugryźć
Dla większości rzeczy faktycznie to zadziałało, ale…
W kategoriach (Katalog -> Kategorie) na liście mam krzaczki (w opisie i nazwie), ale jak wezmę edycję to już się wyświetla poprawnie. I jak wprowadzę tam poprawnie to znowu na liście są krzaczki (w sklepie jest OK).
Czyżby to nie korzystało z PDO?
Rozwiązanie które tutaj jest przedstawione w tym artykule nie jest do końca dobre (chociażby z powodów o których napisałem w powyższym komentarzu)
Szczęśliwie znalazłem powód tego problemu (jak i też rozwiązanie nie wymagające zmiany kodu presty).
Dla potomnych: presta przesyła literki na stronę dokładnie tak jak dostaje z bazy i wymusza w przeglądarce kodowanie utf8. Jeśli w bazie (na skutek ustawień bazy, ustawień starej presty czy z jakiegokolwiek innego powodu) są znaki zakodowane w iso-8859-2 (lub innym kodowaniu w przypadku innych języków) to wyświetlają się źle. Dotyczy to zarówno produktów jak i kategorii i ustawień w menu itd (praktycznie wszystko jest zaciągane z bazy).
Rozwiązaniem jest przekonwertowanie bazy do utf8. Trzeba ją niestety pobrać do pliku tekstowego, zmienić kodowanie i wgrać na nowo – np do nowej bazy i przełączyć tylko wskazanie bazy w konfiguracji presty (można oczywiście nazwę starej bazy zmienić i utworzyć nową o tej samej nazwie i do niej wgrać dumpa, wtedy nie trzeba nic zmienić w konfiguracji presty oczywiście).
żadna z powyższych metod
Niestety u mnie nie pomogło, cała baza, jak i tabele są w utf_unicode. Połączenie ustawione utf8. W Adminie, jak whcodzę w tłumaczenia mam ładnie polskie znaki, jak coś zapisuję z polskimi znakami to w adminie też ładnie się wyświetla. Niestety w bazie i na froncie wyświetlają się krzaczki. Jak spróbuję zmienić bezpośrednio w bazie tak aby były ładnie polskie znaki to na froncie jest ładnie OK, ale wtedy nie chce się otworzyć strona z tłumaczeniem (komunikat: „Malformed UTF-8 characters, possibly incorrectly encoded”)
@Admin, znalazłem dodatkowe rozwiązanie problemu które u mnie występowało nadal po wprowadzeniu powyższych uwag.
Moduł tłumaczeń w adminie używa doctrine który zaczytuje całkiem z innego miejsca ustawienia połączenia z bazą przez co tłumaczenia zapisywały się do bazy oraz wyświetlały się na froncie z krzakami (mimo poprawnego wyświetlania w adminie), dlatego w pliku app/config/condig.yml mniej więcej w linii 86 należy:
1002: „SET sql_mode=(SELECT REPLACE(@@sql_mode,’ONLY_FULL_GROUP_BY’,”))”
zmienić na:
1002: „SET sql_mode=(SELECT REPLACE(@@sql_mode,’ONLY_FULL_GROUP_BY’,”)), NAMES 'UTF8′”
Zmiana ta spowodowała, że u mnie działa jak marzenie 🙂
[…] Poprawa wyświetlania polskich znaków w sklepie PrestaShop 1.7 […]
Mały update do wpisu Michała M.
W presta 1.7.7.3 zmianę należy wprowadzić w pliku:
/app/config/doctrine.yml
w powyższym wpisie są też nieprawidłowe apostrofy i cudzysłowy, przez co skrypt potrafi wysypać stronę.
Wklejam ponownie, zakładam że edytor tekstowy komentarzy niczego nie zmieni 😉
1002: „SET sql_mode=(SELECT REPLACE(@@sql_mode,’ONLY_FULL_GROUP_BY’,”)), NAMES 'UTF8′”
btw- działa, mi pomogło.
Dzięki Michał M.
Widzę, że jednak edytor automatycznie zmienia znaki…
UWAGA: przed zapisaniem pliku zmieńcie: ′ oraz ” – wystarczy wpisać je bezpośrednio z klawiatury
w 1.7.7.8 nie zadziałało, byłoby zbyt pięknie:-) Rozwiązanie z rosyjskiego forum (nie chce mi się tłumaczyć:-))
vendor\doctrine\dbal\lib\Doctrine\DBAL\DriverManager.php
after line 154 add:
$params[’driverOptions’] = array(1002=>’SET NAMES utf8′);
vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\DrizzlePDOMySql\Driver.php
replace line 35 with:
public function connect(array $params, $username = null, $password = null, array $driverOptions = array(PDO::MYSQL_ATTR_INIT_COMMAND => „SET NAMES utf8”))
vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\PDOMySql\Driver.php
replace line 37 with:
public function connect(array $params, $username = null, $password = null, array $driverOptions = array(PDO::MYSQL_ATTR_INIT_COMMAND => „SET NAMES utf8”))
classes/db/DbPDO.php
in return new PDO($dsn, $user, $password, array(PDO::ATTR_TIMEOUT => $timeout, PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true, PDO::MYSQL_ATTR_INIT_COMMAND => „SET NAMES utf8”));
Dzięki @Łukasz za podzielenie się tym !
Ta opcja u mnie zadziałała w Preście 1.7.8.7.
W sumie wystarczyło dodać w pliku vendor\doctrine\dbal\lib\Doctrine\DBAL\DriverManager.php
$params[’driverOptions’] = array(1002=>’SET NAMES utf8′);
Dzięki wielkie.
Udało się komuś finalnie rozwiązać ten problem ? U mnie on dalej występuję.
Po zmianach wg. Grześku strona przestała w ogóle działać.
Natomiast zmiany z rosyjskiego forum nie udało mi się wprowadzić bo w liniach 35 i 37 mam komentarze. Tak jakby te pliki już się zmieniły i nie wiem jak to zrobić
Ktoś ma jeszcze jakieś pomysły ?
Trafiła mi się kolejna Presta z krzakami, pojawiły się po tym jak usługodawca zmienił wersję MySQL.
Zacząłem po kolei od pierwszej dostępnej tu solucji aż do ostatniej i nic… 🙂
btw – apostrofy w podanym kodzie są niepoprawne trzeba je przeklikiwać ręcznie
Rozwiązanie nie do końca okazało się złe, do podanych wskazówek musiałem dołożyć działania na DB:
– pobrałem całość na dysk,
– za pomocą Notepad++ podmieniłem 'krzaki’ na ogonki
– import do DB
et voila – działa 🙂
Sprawdźcie u siebie czy do tych wszystkich zmian na plikach (bo czasem w zupełności wystarczą) nie musicie dołączyć działań na tekście bezpośrednio w DB.
Przesiedziałem wiele godzin na tym problemem. Po aktualizacji do 1.7.8 w zapleczu pokazywały się krzaki , a przede wszystkim zniknął widok Szablonów przez co nie można nanieść poprawek w widoku sklepu.
Rozwiązania nie znalazłem bo jestem cienki w php-ach itp. Ale zrobiłem nową instalację sklepu na nowej bazie. Dodałem nowy produkt i kategorię. I co? Na zapleczu produkt dobrze się wyswietla, a kategoria ma robaki. Zajrzałem do bazy i tam jest ok. Zrobiłem wszystkie wymienione wyżej rozwiązanie i dalej nic, to samo. Kategoria, a nawet logi w Administracji nie mają znaków.
Podmieniłem więc na produkcyjnym sklepie parametry do nowej bazy i adres sklepu. I tutaj przeżyłem szok. Lista produktów zawiera jeden produkt czyli ten, który wcześniej dodałem, ale kategorie są stare , nie są więc pobierane z bazy. Uruchomiłem tryb incognito, wyczyściłem pamięć podręczną. Wciąż to samo kategorie widać zupełnie inne niż te dodane w bazie danych, to samo z logami.
Znaczyłoby to, że baza bazą, ale PS korzysta jeszcze z plików, które ch… wie gdzie się znajdują i żeby rozwiązać problem polskich znaków nie wystarczy skupić się na samej bazie.
Ja już wymiękam i raczej będę namawiał klientów na przesiadkę na bardziej ludzkie rozwiązania 😉
PS. Nowa , czysta instalka w zapleczy w dużym stopniu nie poradziła sobie z tłumaczeniem zaplecz na na polski. Całe menu mam po angielsku, ale opisy po polsku, Dziwne?
Aha, to z Ogicom, też wypróbowałem, bo w ich infrastrukturze znajduje się serwer. Zgadnąć nie trudno, że bez oczekiwanego efektu.