Utworzyli Państwo bazę w phpMyAdmin, wdrożyli WordPress, a po tygodniu zauważyli: w tabelach zamiast tekstu są krzaczki. Otwierają Państwo ustawienia, latin1_swedish_ci. Każdy, kto pracuje z Laragon na Windows, prędzej czy później natrafia na tę niespodziankę.

Problem polega na tym, że kompilacja MySQL, którą Laragon instaluje domyślnie, dziedziczy stare ustawienie: latin1 jako zestaw znaków i latin1_swedish_ci jako porównanie. Dla języka polskiego to katastrofa: cyrylica zapisuje się jako znaki zapytania lub abrakadabra, sortowanie wierszy się psuje, wtyczki padają z błędami.

Poniżej dwie zmiany w jednym pliku, które raz na zawsze zamykają tę kwestię. Zajmie to trzy minuty. Działa na Laragon 6, 5, a nawet na starej czwórce.

💡 Szybki przegląd:

• Otwieramy my.ini przez menu Laragon i dodajemy dwa wiersze w sekcji [mysqld]
• Wybieramy utf8mb4_unicode_ci jako optymalny wariant dla WordPress w 2026 roku (i analizujemy, dlaczego właśnie ten)
• Zapisujemy plik, restartujemy MySQL i sprawdzamy wynik w phpMyAdmin
• Bonus: jak zmienić kodowanie już istniejącej bazy bez utraty danych

Dlaczego domyślne kodowanie w ogóle ma znaczenie

MySQL działa w wielopoziomowym systemie dziedziczenia: serwer → baza danych → tabela → kolumna. Jeśli na poziomie serwera ustawiono latin1_swedish_ci, każda nowa baza, o ile nie wskazano inaczej przy tworzeniu, odziedziczy właśnie to ustawienie.

Dla WordPress jest to krytyczne, ponieważ:

• Rdzeń, motywy i większość wtyczek przechowują treść w utf8mb4
• Przy automatycznym tworzeniu bazy przez wp-config.php WordPress NIE nadpisuje domyślnych ustawień serwera
• Niezgodność kodowań serwera i tabel daje „niejednoznaczne" błędy: ??? w panelu administracyjnym, uszkodzone znaki w JSON REST API, błędy przy eksporcie

Według danych W3Techs, WordPress jest używany przez 43,5% wszystkich stron internetowych, a sam silnik od wersji 4.2 wymaga utf8mb4 do pełnej obsługi emoji. Laragon to jeden z najpopularniejszych serwerów lokalnych pod Windows, ale jego kompilacja MySQL jest dostarczana z konserwatywnym ustawieniem domyślnym ze względu na kompatybilność wsteczną. Stąd konflikt.

Krok 1: Otwieramy my.ini przez menu Laragon

Najprostszy sposób, aby dostać się do pliku konfiguracyjnego MySQL, to wbudowane menu Laragon:

• Kliknąć prawym przyciskiem myszy ikonę Laragon w zasobniku systemowym
• Wybrać Menu → MySQL → my.ini

Otworzy się Notatnik (lub domyślny edytor) z pełną konfiguracją MySQL. Plik jest podzielony na sekcje w nawiasach kwadratowych: [client], [mysqld] i [mysqldump]. Interesuje nas [mysqld] (sekcja ustawień demona MySQL).

Jeśli z jakiegoś powodu menu nie otwiera pliku, proszę znaleźć go ręcznie: C:\laragon\bin\mysql\<версия>\my.ini. W kompilacjach Laragon 6 ścieżka może wyglądać tak: C:\laragon\bin\mysql\mysql-8.0.30-winx64\my.ini, zależy to od zainstalowanej wersji.

Krok 2: Dodajemy dwa wiersze w sekcji [mysqld]

Proszę przewinąć plik do sekcji [mysqld] i dodać na końcu (przed następną sekcją, jeśli istnieje) dwa wiersze:

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Co tu się dzieje:

• character_set_server = utf8mb4, serwer domyślnie używa kodowania UTF-8 Multilingual Version 4, które obsługuje WSZYSTKIE znaki Unicode, w tym emoji, cyrylicę i hieroglify
• collation_server = utf8mb4_unicode_ci, reguła porównywania ciągów: _unicode_ oznacza „zgodnie ze standardem Unicode", _ci oznacza case-insensitive (porównywanie bez rozróżniania wielkości liter)

Należy dodać to dokładnie w [mysqld], nie w [client] ani nie w [mysqldump]. Błąd z sekcją to najczęstsza przyczyna sytuacji „nic się nie zmieniło".

Pełny fragment sekcji po edycji wygląda mniej więcej tak:

1
[mysqld]
2
port=3306
3
socket=/tmp/mysql.sock
4
key_buffer_size=256M
5
max_allowed_packet=512M
6
character_set_server = utf8mb4
7
collation_server = utf8mb4_unicode_ci

Krok 3: Zapisujemy plik i restartujemy MySQL

Proszę zapisać my.ini (Ctrl+S) i zrestartować MySQL. W Laragon robi się to przez to samo menu:

• Prawy klik na ikonę Laragon w zasobniku systemowym
• Menu → MySQL → Stop
• Proszę odczekać 3-5 sekund
• Menu → MySQL → Start

Alternatywnie proszę nacisnąć Menu → Uruchom ponownie, Laragon sam zatrzyma i uruchomi wszystkie usługi razem.

Po restarcie nowe bazy danych będą tworzone domyślnie z utf8mb4_unicode_ci. Stare bazy NIE zmieniają się automatycznie, o tym, jak przekonwertować istniejącą, przeczytają Państwo w bloku „Często zadawane pytania" poniżej.

Krok 4: Sprawdzamy wynik w phpMyAdmin

Proszę otworzyć phpMyAdmin przez menu Laragon (Menu → MySQL → phpMyAdmin) i utworzyć testową bazę:

• Kliknąć „Utwórz BD"
• Wpisać dowolną nazwę
• Spojrzeć na rozwijaną listę „Kodowanie", teraz domyślnie widnieje tam utf8mb4_unicode_ci

Jeśli rozwijana lista nadal pokazuje latin1_swedish_ci, proszę sprawdzić, czy wiersze character_set_server i collation_server zostały dodane dokładnie w sekcji [mysqld], a nie w [client], oraz czy między nazwą parametru a znakiem = nie ma zbędnych spacji.

Szybkie sprawdzenie przez zapytanie SQL (proszę wykonać w phpMyAdmin na karcie SQL):

1
SHOW VARIABLES LIKE 'character_set_server';
2
SHOW VARIABLES LIKE 'collation_server';

Obie zmienne powinny zwrócić odpowiednio utf8mb4 i utf8mb4_unicode_ci.

Jakie kodowanie wybrać: porównanie wariantów

Temat kodowań MySQL obrósł mitami, dlatego rozłożymy na czynniki pierwsze trzy aktualne warianty i jeden przestarzały:

Dlaczego radzimy utf8mb4_unicode_ci do pracy lokalnej w Laragon:

• Laragon dostarcza różne wersje MySQL (od 5.7 do 8.0+), utf8mb4_0900_ai_ci pojawił się tylko w MySQL 8.0 i nie ma go w MariaDB, która często występuje w alternatywnych kompilacjach
• utf8mb4_unicode_ci działa wszędzie, począwszy od MySQL 5.5.3 (rok 2010)
• Różnica w jakości sortowania między unicode_ci a 0900_ai_ci dla typowej strony na WordPress jest niezauważalna
• Hostingi na taryfach współdzielonych często używają MySQL 5.7, jeśli lokalnie rozwija się Państwo projekt na 0900_ai_ci, a na produkcji go nie ma, otrzymają Państwo błąd przy przenoszeniu

Jeśli mają Państwo pewność, że serwer produkcyjny działa na MySQL 8.0+, a lokalny Laragon używa MySQL 8.0, proszę ustawić utf8mb4_0900_ai_ci. To nowoczesny standard, rekomendowany przez Oracle, z lepszą obsługą wielojęzycznego sortowania.

Co z utf8_general_ci? Był aktualny jakieś dziesięć lat temu, gdy utf8mb4 nie był jeszcze masowo wspierany. Dziś ma dwie fatalne wady: nie przechowuje emoji (WordPress aktywnie używa ich w panelu administracyjnym) i upraszcza sortowanie rozszerzonych znaków. Nie ma powodu, by go ustawiać w 2026 roku.

Wideo: jak zmienić kodowanie bazy danych MySQL przez phpMyAdmin

Instrukcje tekstowe to dobra rzecz, ale czasem łatwiej raz zobaczyć. W tym 4-minutowym filmie pokazano pełny proces zmiany kodowania istniejącej bazy danych przez interfejs phpMyAdmin, od wyboru tabel do końcowego sprawdzenia:

⁉️🤔 Często zadawane pytania

Mam już bazę danych z latin1_swedish_ci. Jak zmienić jej kodowanie?

Najbezpieczniejsza droga wiedzie przez phpMyAdmin. Proszę wybrać bazę po lewej, przejść na kartę „Operacje", w bloku „Kodowanie" wybrać utf8mb4_unicode_ci i kliknąć „Wykonaj". phpMyAdmin wygeneruje zapytania ALTER dla każdej tabeli. Przed operacją koniecznie proszę zrobić kopię zapasową: karta „Eksport" → format SQL → „Wykonaj".

Zmieniłem my.ini, zrestartowałem MySQL, a w phpMyAdmin nadal jest latin1_swedish_ci. O co chodzi?

Trzy najczęstsze przyczyny: (1) wiersze dodano w [client] zamiast [mysqld], proszę sprawdzić, pod którym nawiasem kwadratowym się znajdują; (2) MySQL nie zrestartował się, proszę otworzyć menedżera zadań Windows i upewnić się, że proces mysqld.exe zniknął i pojawił się na nowo; (3) w my.ini jest kilka sekcji [mysqld], zdarza się to po kilku aktualizacjach Laragon, proszę zostawić jedną.

Co jest lepsze dla WordPress: utf8mb4_unicode_ci czy utf8mb4_general_ci?

Dla WordPress różnica jest minimalna. utf8mb4_unicode_ci dokładniej sortuje treść wielojęzyczną (np. niemieckie „ß" = „ss"), utf8mb4_general_ci jest nieco szybszy na dużych wolumenach, ale różnica to milisekundy. Proszę wziąć unicode_ci i nie zaprzątać sobie tym głowy.

Czy można po prostu wpisać kodowanie w wp-config.php?

define('DB_CHARSET', 'utf8mb4') i define('DB_COLLATE', 'utf8mb4_unicode_ci') w wp-config.php wpływają TYLKO na tabele, które tworzy sam WordPress podczas instalacji. Domyślne ustawienie serwera nie zmienia się przy tym, a każda baza utworzona ręcznie przez phpMyAdmin otrzyma latin1_swedish_ci. Dlatego i tak trzeba edytować my.ini.

Po zmianie kodowania część tekstu na stronie zamieniła się w znaki zapytania. Czy to odwracalne?

Tak, ale należy działać ostrożnie. Znaki zapytania pojawiają się, gdy dane zostały zapisane w latin1, a są odczytywane jako utf8. Rozwiązanie: proszę wyeksportować bazę z flagą --default-character-set=latin1, a następnie zaimportować z --default-character-set=utf8mb4. Dokładne polecenie zależy od wersji MySQL, dlatego proszę sprawdzić w oficjalnej dokumentacji.

Podsumowanie: co wpisać w my.ini od razu

Jeśli używają Państwo Laragon do lokalnego tworzenia stron WordPress, dwa poniższe wiersze rozwiążą problem z kodowaniem raz na zawsze:

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Ten wariant działa na każdej wersji MySQL od 5.5 do 8.4 i na wszystkich aktualnych kompilacjach MariaDB. Poprawnie przechowuje cyrylicę, emoji i nie stwarza niespodzianek przy przenoszeniu bazy z lokalnego środowiska na produkcję, niezależnie od tego, na jakim hostingu działa produkcja.

Zostały Państwu pytania dotyczące konkretnej wersji Laragon lub niestandardowej konfiguracji? Proszę zajrzeć do wątku na forum Laragon, tam deweloperzy omawiają niuanse konfiguracji kodowań, włącznie z kompilacjami Docker i niestandardowymi portami. A jeśli artykuł zaoszczędził Państwu wieczór, proszę opowiedzieć o nim kolegom, którzy również męczą się z latin1_swedish_ci.