Press "Enter" to skip to content

Poprawa wyświetlania polskich znaków w sklepie PrestaShop 1.7

Admin 25

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.

  1. Na poziomie tworzenia bazy danych w panelu hostingowym powinna mieć ona kodowanie: UTF8. Skontaktuj się dla pewności w tej sprawie z administatorem serwera.
  2. W programie PhpMyAdmin wybierz opcję „Databases” i na liście baz danych upewij się czy baza posiada kodowanie UTF8 np. utf8_polish_ci
  3. 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
  4. 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

  1. 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).
  2. 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).
  3. 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

  1. Piotr Piotr

    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.

    • Admin Admin

      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ć.

      • Piotr Piotr

        Przepraszam ale nie jestem na tyle zaawansowany. Co to znaczy na złym kodowaniu w skrypcie ?

  2. jane jane

    U mnie zadziałało. Dzięki 🙂

  3. Grześku Grześku

    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!

  4. Roger Roger

    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);

  5. Konrad Konrad

    Migracja z Linux na Home spowodowała taki błąd. Metoda zadziałała!

  6. Kamil Kamil

    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źć

  7. 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?

  8. 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).

  9. Michal M. Michal M.

    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”)

  10. Michał M. Michał M.

    @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 🙂

  11. Grześku Grześku

    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.

    • Grześku Grześku

      Widzę, że jednak edytor automatycznie zmienia znaki…
      UWAGA: przed zapisaniem pliku zmieńcie: ′ oraz ” – wystarczy wpisać je bezpośrednio z klawiatury

  12. Łukasz Łukasz

    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”));

    • Admin Admin

      Dzięki @Łukasz za podzielenie się tym !

    • Marcin Marcin

      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.

  13. Artur Artur

    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 ?

  14. 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.

  15. 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?

    • Radek Radek

      Aha, to z Ogicom, też wypróbowałem, bo w ich infrastrukturze znajduje się serwer. Zgadnąć nie trudno, że bez oczekiwanego efektu.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

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

Zobacz także !
Jak w PrestaShop 1.7 usunąć wybór płci przez klienta w…