Як виправити конфлікти charset і collation у WordPress

Що означають charset і collation

Charset, або кодування, визначає, які символи може зберігати база даних. Для сучасного WordPress зазвичай потрібен `utf8mb4`, оскільки він підтримує повний набір Unicode, зокрема емодзі та символи різних мов. Старе кодування `utf8` у MySQL і MariaDB не є повним UTF-8 та може не підтримувати чотирибайтні символи.

Collation визначає правила порівняння і сортування тексту: чи враховується регістр, як порівнюються літери з діакритикою та в якому порядку повертаються результати. Наприклад, `utf8mb4_unicode_ci` і `utf8mb4_general_ci` можуть давати різні результати сортування.

Конфлікт виникає, коли MySQL порівнює або об’єднує текстові значення з різними collation без можливості автоматично узгодити їх. Це може проявлятися не лише на рівні всієї таблиці, а й у конкретній колонці, тимчасовій таблиці або запиті плагіна.

• charset — набір символів, який може зберігатися;
• collation — правила порівняння та сортування тексту;
• `utf8mb4` — рекомендований базовий charset для сучасного WordPress;
• однакова collation бажана для колонок, які порівнюються між собою.

Зробіть резервну копію перед змінами

Конвертація таблиць змінює структуру та іноді перебудовує індекси. Перед роботою створіть повну резервну копію бази й переконайтеся, що її можна відновити. Для великих сайтів бажано також мати копію файлів і виконувати операції в maintenance-вікно.

Якщо доступний WP-CLI, резервну копію можна створити командою нижче. Вона використовує налаштування підключення з WordPress і зберігає дамп у файл.

• Не виконуйте `ALTER TABLE` на робочій базі без перевіреного дампа.
• Перед змінами зафіксуйте поточні версії MySQL або MariaDB і WordPress.
• Перевірте, чи має користувач бази даних права на зміну таблиць.
• Для критичного сайту спочатку протестуйте процедуру на копії або staging-середовищі.

wp db export backup-before-collation.sql

Визначте таблиці WordPress із різним кодуванням

Не припускайте, що префікс таблиць завжди дорівнює `wp_`. Його можна перевірити у файлі конфігурації або отримати через WP-CLI. У запиті нижче використовується префікс `wp_` лише як приклад.

Спочатку перегляньте charset і collation усіх таблиць поточної бази. Запит через `DATABASE()` автоматично використовує базу, до якої підключене поточне з’єднання.

• Таблиці з однаковим charset, але різними collation також можуть спричиняти конфлікти.
• Плагіни часто створюють власні таблиці, які не починаються з `wp_` або мають інший префікс.
• Окремо перевіряйте таблиці, де зберігаються записи, метадані, коментарі, таксономії та дані плагінів.

wp db query "
SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
ORDER BY TABLE_NAME;"

Перевірте charset і collation окремих колонок

Налаштування таблиці не завжди відображають фактичну структуру кожної колонки. Текстова колонка може мати власні `CHARACTER_SET_NAME` і `COLLATION_NAME`, успадковані з іншої схеми або змінені під час імпорту.

Для швидкої перевірки конкретної таблиці використовуйте `SHOW FULL COLUMNS`. Це особливо важливо для `wp_posts`, `wp_postmeta`, `wp_comments`, `wp_terms`, `wp_term_taxonomy` та таблиць плагінів.

wp db query "SHOW FULL COLUMNS FROM wp_posts;"

wp db query "
SELECT TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME, COLUMN_TYPE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND CHARACTER_SET_NAME IS NOT NULL
ORDER BY TABLE_NAME, ORDINAL_POSITION;"

Як знайти підозрілі колонки

У результатах зверніть увагу на текстові колонки, де charset відрізняється від `utf8mb4`, або на колонки з іншою collation порівняно з рештою таблиці. Якщо помилка виникає лише під час пошуку чи імпорту, корисно перевірити також таблиці, які створює відповідний плагін.

Не змінюйте тип колонки, довжину поля або індекси без потреби. Завданням цієї процедури є узгодження кодування і правил порівняння, а не перебудова всієї схеми.

• Порівнюйте не лише таблиці, а й конкретні текстові колонки.
• Враховуйте таблиці сторонніх плагінів і кастомні таблиці теми.
• Збережіть результати діагностики до внесення змін.

Оберіть сумісну collation

Вибір collation залежить від версії сервера. `utf8mb4_unicode_ci` є поширеним і сумісним варіантом для багатьох інсталяцій WordPress. На MySQL 8 можуть бути доступні collations із суфіксом `0900`, але вони не обов’язково існують у старих версіях MySQL або в MariaDB. Тому не переносіть таке значення між серверами без перевірки.

Перелік доступних варіантів можна отримати безпосередньо на сервері. Для сайту, який має працювати на різних середовищах, зазвичай безпечніше обрати collation, присутню на всіх цільових серверах.

wp db query "SELECT VERSION();"
wp db query "SHOW COLLATION LIKE 'utf8mb4%';"

Що врахувати під час вибору

Узгоджуйте charset і collation: collation для `utf8mb4` повинна належати до `utf8mb4`, а не до старого `utf8`. Якщо сайт активно працює з українською та іншими мовами, тестуйте сортування реальними даними після конвертації.

Не потрібно механічно змінювати всі таблиці на найновішу доступну collation. Сумісність із версією сервера, плагінами, резервними копіями та майбутнім середовищем важливіша за сам факт використання новішої назви.

• Перевірте підтримку обраної collation у MySQL або MariaDB.
• Використовуйте один узгоджений варіант для пов’язаних таблиць.
• Не змішуйте collations лише через те, що вони доступні на поточному сервері.

Конвертуйте таблиці поетапно

Для зміни charset і collation таблиці використовується `ALTER TABLE ... CONVERT TO CHARACTER SET`. Команда перетворює текстові колонки таблиці, тому її потрібно виконувати обережно і спочатку на одній тестовій таблиці.

У прикладі нижче використовується `utf8mb4_unicode_ci`. Замініть її на варіант, який підтримує ваш сервер і який ви обрали після перевірки.

ALTER TABLE wp_posts
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

ALTER TABLE wp_postmeta
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

Порядок і технічні обмеження

Після конвертації першої таблиці перевірте сайт, а вже потім переходьте до наступної. Для великих таблиць операція може тимчасово блокувати записи, споживати дисковий простір і створювати додаткове навантаження.

На старих версіях MySQL або при довгих індексах конвертація може завершитися помилкою через обмеження довжини індексу. Не скорочуйте індекси навмання: спочатку з’ясуйте, яка саме колонка або індекс спричинила проблему, і зробіть окремий план змін.

Якщо таблиця належить плагіну, перевірте його документацію або схему оновлення. Примусова зміна структури може бути перезаписана під час наступного оновлення плагіна.

• Починайте з невеликої таблиці або staging-копії.
• Для великих таблиць заплануйте maintenance-вікно.
• Не переривайте операцію без розуміння її поточного стану.
• Після кожної групи змін перевіряйте статус таблиць і журнали помилок.

Перевірте результат після виправлення

Після конвертації повторно виконайте запити до `information_schema` і переконайтеся, що потрібні таблиці та текстові колонки мають очікувані значення. Перевірка лише однієї таблиці не гарантує, що конфлікт зник у всій базі.

Потім протестуйте функції, які раніше викликали помилку: пошук, сортування, фільтри, імпорт, створення записів і коментарів. Окремо перевірте збереження українських символів, емодзі та тексту з діакритикою.

Якщо помилка залишилася, знайдіть повний SQL-запит у журналі PHP, WordPress або плагіна. Проблема може бути не в таблицях, а в запиті, який явно задає іншу collation через `COLLATE`, створює тимчасову таблицю або порівнює значення з різних джерел.

• Перевірте головну сторінку, адмінпанель і сторінки з пошуком.
• Створіть тестовий запис із кирилицею та емодзі.
• Перевірте сортування за заголовком, ім’ям і метаданими.
• Повторіть імпорт або синхронізацію, під час якої виникала помилка.
• Перегляньте журнали після тесту, а не лише повідомлення в браузері.

Типові помилки під час виправлення

Найнебезпечніший підхід — виконати масову заміну collation без інвентаризації бази. Це може приховати першопричину, створити проблеми з індексами або вплинути на дані плагінів.

Також не варто плутати виправлення кодування з виправленням уже пошкодженого тексту. Якщо дані були імпортовані в неправильному charset і вже перетворилися на символи на кшталт `????` або некоректну послідовність, зміна collation не відновить оригінал. Для цього потрібне відновлення з коректної резервної копії або окрема міграція даних.

Не редагуйте дамп текстовим редактором без розуміння його кодування. Під час експорту та імпорту перевіряйте charset самого файлу, налаштування клієнта MySQL і параметри інструмента міграції.

• Не використовуйте collation, якої немає на цільовому сервері.
• Не змінюйте лише одну колонку, якщо пов’язані таблиці залишаються несумісними.
• Не видаляйте індекси для обходу помилки без плану їх відновлення.
• Не вважайте успішне виконання `ALTER TABLE` доказом коректності даних.
• Не пропускайте тестування на копії сайту, якщо база велика або критична.