Створили базу в phpMyAdmin, розгорнули WordPress, а за тиждень помітили: в таблицях кракозябри замість тексту. Відкриваєте налаштування, latin1_swedish_ci. Кожен, хто працює з Laragon на Windows, рано чи пізно натрапляє на цей сюрприз.

Проблема в тому, що збірка MySQL, яку Laragon встановлює з коробки, успадковує давній дефолт: latin1 як набір символів і latin1_swedish_ci як порівняння. Для української мови це катастрофа: кирилиця записується знаками питання або абракадаброю, сортування рядків ламається, плагіни падають із помилками.

Нижче, дві зміни в одному файлі, які назавжди закривають це питання. Займе три хвилини. Працює на Laragon 6, 5 і навіть на давній четвірці.

💡 Швидкий огляд:

• Відкриваємо my.ini через меню Laragon і додаємо два рядки в секцію [mysqld]
• Вибираємо utf8mb4_unicode_ci як оптимальний варіант для WordPress у 2026 році (і розбираємо чому саме він)
• Зберігаємо файл, перезапускаємо MySQL і перевіряємо результат у phpMyAdmin
• Бонус: як змінити кодування вже створеної бази без втрати даних

Чому кодування за замовчуванням взагалі важливе

MySQL працює з багаторівневою системою успадкування: сервер → база даних → таблиця → стовпець. Якщо на рівні сервера задано latin1_swedish_ci, кожна нова база, якщо не вказано інше при створенні, успадкує саме його.

Для WordPress це критично, тому що:

• Ядро, теми та більшість плагінів зберігають контент у utf8mb4
• При автоматичному створенні бази через wp-config.php WordPress НЕ перевизначає серверний дефолт
• Незбіг кодувань сервера та таблиць дає «невиразні» помилки: ??? в адмінці, биті символи в JSON REST API, падіння при експорті

За даними W3Techs, WordPress використовують 43,5% усіх сайтів інтернету, а сам рушій з версії 4.2 вимагає utf8mb4 для повної підтримки емодзі. Laragon, один із найпопулярніших локальних серверів під Windows, але його MySQL-збірка постачається з консервативним дефолтом заради зворотної сумісності. Звідси й конфлікт.

Крок 1: Відкриваємо my.ini через меню Laragon

Найпростіший спосіб дістатися до конфігураційного файлу MySQL, вбудоване меню Laragon:

• Натисніть правою кнопкою миші на іконку Laragon у треї
• Виберіть Menu → MySQL → my.ini

Відкриється Блокнот (або ваш редактор за замовчуванням) із повним конфігом MySQL. Файл розбито на секції в квадратних дужках: [client], [mysqld] і [mysqldump]. Нас цікавить [mysqld] (секція налаштувань демона MySQL).

Якщо з якоїсь причини меню не відкриває файл, знайдіть його вручну: C:\laragon\bin\mysql\<версия>\my.ini. У збірках Laragon 6 шлях може бути C:\laragon\bin\mysql\mysql-8.0.30-winx64\my.ini, залежить від встановленої версії.

Крок 2: Додаємо два рядки в секцію [mysqld]

Прокрутіть файл до секції [mysqld] і додайте в кінець (перед наступною секцією, якщо вона є) два рядки:

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Що тут відбувається:

• character_set_server = utf8mb4, сервер за замовчуванням використовує кодування UTF-8 Multilingual Version 4, яке підтримує ВСІ символи Unicode, включно з емодзі, кирилицею, ієрогліфами
• collation_server = utf8mb4_unicode_ci, правило порівняння рядків: _unicode_ означає «за стандартом Unicode», _ci означає case-insensitive (регістронезалежне порівняння)

Додавати потрібно саме в [mysqld], не в [client] і не в [mysqldump]. Помилка з секцією, найчастіша причина «нічого не змінилося».

Повний фрагмент секції після правки виглядає приблизно так:

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

Крок 3: Зберігаємо файл і перезапускаємо MySQL

Збережіть my.ini (Ctrl+S) і перезапустіть MySQL. У Laragon це робиться через те саме меню:

• Правий клік по іконці Laragon у треї
• Menu → MySQL → Stop
• Зачекайте 3-5 секунд
• Menu → MySQL → Start

Альтернативно натисніть Menu → Перезапустити, Laragon сам зупинить і запустить усі служби разом.

Після перезапуску нові бази даних створюватимуться з utf8mb4_unicode_ci за замовчуванням. Старі бази НЕ змінюються автоматично, про те, як конвертувати наявну, читайте в блоці «Часті питання» нижче.

Крок 4: Перевіряємо результат у phpMyAdmin

Відкрийте phpMyAdmin через меню Laragon (Menu → MySQL → phpMyAdmin) і створіть тестову базу:

• Натисніть «Створити БД»
• Введіть будь-яке ім’я
• Подивіться на випадний список «Кодування», тепер там за замовчуванням стоїть utf8mb4_unicode_ci

Якщо випадний список усе ще показує latin1_swedish_ci, перевірте, що рядки character_set_server і collation_server додано саме в секцію [mysqld], а не в [client], і що між назвою параметра та знаком = немає зайвих пробілів.

Швидка перевірка через SQL-запит (виконайте в phpMyAdmin на вкладці SQL):

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

Обидві змінні мають повернути utf8mb4 і utf8mb4_unicode_ci відповідно.

Яке кодування обрати: порівняння варіантів

Тема кодувань MySQL обросла міфами, тому розкладемо по поличках три актуальні варіанти й один застарілий:

Чому ми радимо utf8mb4_unicode_ci для локальної розробки в Laragon:

• Laragon постачає різні версії MySQL (від 5.7 до 8.0+), utf8mb4_0900_ai_ci з’явився тільки в MySQL 8.0 і відсутній у MariaDB, яка часто йде в альтернативних збірках
• utf8mb4_unicode_ci працює скрізь, починаючи з MySQL 5.5.3 (2010 рік)
• Різниця в якості сортування між unicode_ci і 0900_ai_ci для типового WordPress-сайту непомітна
• Хостинги на shared-тарифах часто використовують MySQL 5.7, якщо локально розробляти на 0900_ai_ci, а на проді його немає, отримаєте помилку при перенесенні

Якщо ви точно знаєте, що продакшен-сервер працює на MySQL 8.0+, а локальний Laragon використовує MySQL 8.0, ставте utf8mb4_0900_ai_ci. Це сучасний стандарт, рекомендований Oracle, з кращою підтримкою багатомовного сортування.

Що щодо utf8_general_ci? Він був актуальний років десять тому, коли utf8mb4 ще не підтримувався масово. Сьогодні в нього дві фатальні вади: не зберігає емодзі (WordPress в адмінці використовує їх активно) і спрощено сортує розширені символи. Ставити його в 2026 році немає причин.

Відео: як змінити кодування бази даних MySQL через phpMyAdmin

Текстові інструкції — це добре, але іноді простіше один раз побачити. У цьому 4-хвилинному відео показано повний процес зміни кодування наявної бази даних через інтерфейс phpMyAdmin, від вибору таблиць до фінальної перевірки:

⁉️🤔 Часті питання

У мене вже є база даних із latin1_swedish_ci. Як змінити її кодування?

Найбезпечніший шлях, через phpMyAdmin. Виберіть базу зліва, перейдіть на вкладку «Операції», в блоці «Кодування» виберіть utf8mb4_unicode_ci і натисніть «Вперед». phpMyAdmin згенерує ALTER-запити для кожної таблиці. Перед операцією обов’язково зробіть бекап: вкладка «Експорт» → формат SQL → «Вперед».

Змінив my.ini, перезапустив MySQL, а в phpMyAdmin однаково latin1_swedish_ci. В чому річ?

Три найчастіші причини: (1) рядки додано в [client] замість [mysqld], перевірте, під якою квадратною дужкою вони знаходяться; (2) MySQL не перезапустився, відкрийте диспетчер задач Windows і переконайтеся, що процес mysqld.exe зник і з’явився заново; (3) в my.ini кілька секцій [mysqld], так буває після кількох оновлень Laragon, залиште одну.

Що краще для WordPress: utf8mb4_unicode_ci чи utf8mb4_general_ci?

Для WordPress різниця мінімальна. utf8mb4_unicode_ci точніше сортує багатомовний контент (наприклад, німецьке «ß» = «ss»), utf8mb4_general_ci трохи швидший на великих обсягах, але різниця в мілісекундах. Беріть unicode_ci і не думайте.

Чи можна просто прописати кодування в wp-config.php?

define('DB_CHARSET', 'utf8mb4') і define('DB_COLLATE', 'utf8mb4_unicode_ci') в wp-config.php впливають ТІЛЬКИ на таблиці, які створює сам WordPress при встановленні. Серверний дефолт при цьому не змінюється, і будь-яка база, створена вручну через phpMyAdmin, отримає latin1_swedish_ci. Тому правити my.ini однаково потрібно.

Після зміни кодування частина тексту на сайті перетворилася на знаки питання. Це оборотно?

Так, але діяти потрібно обережно. Знаки питання з’являються, коли дані були записані в latin1, а читаються як utf8. Рішення: експортуйте базу з прапором --default-character-set=latin1, потім імпортуйте з --default-character-set=utf8mb4. Точна команда залежить від версії MySQL, тому звіртеся з офіційною документацією.

Підсумки: що прописати в my.ini прямо зараз

Якщо ви використовуєте Laragon для локальної розробки WordPress-сайтів, два рядки нижче вирішать проблему з кодуванням раз і назавжди:

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Цей варіант працює на будь-якій версії MySQL від 5.5 до 8.4 і на всіх актуальних збірках MariaDB. Він коректно зберігає кирилицю, емодзі та не створює сюрпризів при перенесенні бази з локалки на прод, незалежно від того, на якому хостингу працює продакшен.

Залишилися питання щодо конкретної версії Laragon або нестандартної конфігурації? Зазирніть у тему на форумі Laragon, там розробники обговорюють нюанси налаштування кодувань, включно з Docker-збірками та кастомними портами. А якщо стаття зекономила вам вечір, розкажіть про неї колегам, які теж мучаться з latin1_swedish_ci.