Як виправити помилку "Cookies заблоковані або не підтримуються" у WordPress (включно з Multisite)

Привіт усім! Якщо ви керуєте сайтом на WordPress, рано чи пізно можете зіткнутися з різними технічними проблемами. Нещодавно я сам потрапив у неприємну ситуацію: під час спроби увійти до адмін-панелі мого сайту (і, що особливо важливо, сайту на Multisite) я побачив страшне повідомлення: “Помилка: Cookies або заблоковані або не підтримуються вашим браузером. Щоб використовувати WordPress, потрібно дозволити cookies.”. Це було дуже дивно, адже я точно знав, що cookies у моєму браузері увімкнені, і ще вчора все працювало ідеально.

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

Швидке вирішення проблеми

Модифікація /wp-config.php (Додавання констант для Cookies)

/wp-config.php часто допомагає вирішити проблеми з невідповідністю домену або шляху cookie, особливо після міграції або в складних конфігураціях Multisite.

Код потрібно додавати у файл $wp-config.php перед рядком:

/* That’s all, stop editing! Happy publishing. */

define(‘COOKIE_DOMAIN’, false);

Зміст

Вступ: Розуміння помилки “Cookies заблоковані або не підтримуються” у WordPress

Що означає ця помилка?

По суті, це повідомлення з’являється, коли WordPress не може встановити або прочитати спеціальний файл cookie, який потрібен для автентифікації вашого сеансу входу. Уявіть собі cookies як тимчасовий пропуск або ключ до вашого сайту. Коли ви вводите логін та пароль, WordPress створює у вашому браузері невеликий файл cookie, який каже: “Так, ця людина авторизована і може перебувати в адмін-панелі”. Якщо цей “пропуск” не може бути створений або прочитаний, WordPress не може підтвердити вашу особу і блокує доступ, показуючи цю помилку.

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

Чому вона виникає і викликає роздратування?

Найбільше дратує те, що помилка часто з’являється раптово, без видимих причин. Ви могли нічого не змінювати у налаштуваннях сайту чи браузера, cookies у вас увімкнені, а вхід все одно не працює.¹ Часто це трапляється після міграції сайту на новий хостинг або зміни сервера, навіть якщо домен залишився тим самим.

Ще одна причина фрустрації криється у самій природі повідомлення. Воно каже “Cookies заблоковані браузером“, що змушує користувачів насамперед перевіряти налаштування браузера. Однак, як показує практика, проблема часто полягає не в глобальному блокуванні cookies браузером, а в тому, що сам WordPress через внутрішні конфлікти або неправильну конфігурацію не може коректно встановити або прочитати свій власний автентифікаційний cookie.¹ Браузер може бути готовий прийняти cookie, але WordPress не може надати йому правильний. Це збиває з пантелику і призводить до витрати часу на перевірку налаштувань, які можуть бути абсолютно нормальними.

Загальні причини блокування Cookies браузером

Перш ніж заглиблюватися у специфіку WordPress, варто розглянути загальні причини, через які браузер може не приймати cookies:

Налаштування конфіденційності браузера: Деякі користувачі свідомо встановлюють високий рівень конфіденційності, вимикаючи cookies або блокуючи сторонні (third-party) cookies для зменшення відстеження.³ Хоча логін WordPress зазвичай використовує основні (first-party) cookies ⁷, у певних сценаріях (як ми побачимо пізніше, особливо в Multisite з мапуванням доменів ⁸) вони можуть інтерпретуватися як сторонні, що призводить до блокування. Сучасні браузери все більше обмежують сторонні cookies через занепокоєння щодо приватності.¹⁰
Розширення (Add-ons) браузера: Різноманітні розширення, особливо блокувальники реклами, трекерів або антивірусні/фаєрвол-додатки, можуть помилково ідентифікувати cookie WordPress як щось шкідливе і блокувати його.
Режими приватного перегляду (Incognito/Private): Ці режими зазвичай мають більш суворі налаштування щодо cookies за замовчуванням, особливо сторонніх.⁷ Хоча вони й не зберігають cookies після закриття, під час сесії можуть виникати проблеми.
Застарілий кеш або файли cookie браузера: Накопичені, пошкоджені або конфліктуючі дані у кеші браузера та старі cookies – одна з найчастіших причин.¹³ Особливо це актуально після міграції сайту, коли старі cookies, що вказують на попередній сервер чи конфігурацію, конфліктують з новими.³

Специфічні причини помилки Cookies у WordPress

Якщо проблема не в загальних налаштуваннях браузера, найімовірніше, вона криється всередині вашої інсталяції WordPress. Ось найпоширеніші винуватці:

Конфлікти плагінів: Це, мабуть, найчастіша причина.

Плагіни безпеки та кешування: Такі плагіни, як Wordfence, Sucuri, WP Super Cache, W3 Total Cache тощо, можуть агресивно втручатися в процес обробки cookies або сесій входу.¹ Надто суворі налаштування безпеки можуть помилково блокувати легітимні cookies.¹
“Неочікуваний вивід” (Unexpected Output): Деякі плагіни можуть генерувати зайвий код або навіть пробіли перед тим, як WordPress намагається встановити cookie. Це порушує процес, і cookie не встановлюється.¹⁵ Ця проблема часто проявляється як помилка “Cookies are blocked due to unexpected output”.
Несумісність: Плагін може бути несумісним з вашою версією WordPress, темою або іншими плагінами.¹⁷

Конфлікти тем оформлення: Подібно до плагінів, ваша активна тема може містити помилки в коді, конфліктувати з плагінами або ядром WordPress, або генерувати “неочікуваний вивід”, що заважає роботі cookies.²
Неправильні налаштування URL-адреси WordPress та URL-адреси сайту: У розділі “Налаштування” -> “Загальні” є два поля: “Адреса WordPress (URL)” та “Адреса сайту (URL)”. Якщо ці адреси не збігаються, вказані неправильно (наприклад, HTTP замість HTTPS) або не відповідають реальній адресі сайту, це може призвести до проблем з cookies.² Дуже важливо перевіряти значення siteurl та home в таблиці $wp_options бази даних, особливо після міграції.²
Проблеми після міграції сайту: Як уже згадувалося, переїзд сайту – частий тригер помилки. Це може бути пов’язано з невідповідністю шляхів до файлів, налаштувань сервера, старими cookies у браузері, що вказують на старий сервер, або неправильно оновленими URL-адресами в базі даних.¹
Пошкоджений файл .htaccess: Цей файл керує багатьма аспектами роботи сервера Apache. Неправильні директиви або пошкодження файлу можуть блокувати доступ або заважати процесу автентифікації.²
Проблеми з PHP файлами (зайві пробіли, кодування): Помилка “Cookies are blocked due to unexpected output” найчастіше викликана саме цим. Зайвий пробіл або порожній рядок перед початковим тегом <?php або після кінцевого тегу ?> (який краще взагалі прибирати в кінці файлів) у файлах $wp-config.php, $functions.php теми або файлах плагінів може все зламати.¹⁵ Також проблемою може бути неправильне кодування файлу, наприклад, збереження у форматі UTF-8 з BOM замість чистого UTF-8.²⁴
Проблеми з SSL/HTTPS: Якщо ваш сайт використовує HTTPS, але SSL-сертифікат налаштований неправильно, або є проблеми з перенаправленням з HTTP на HTTPS, це може блокувати cookies, які мають атрибут “Secure”.² Особливо це актуально при використанні інструментів попереднього перегляду сайту (site preview) на хостингу, які можуть намагатися відкрити HTTPS-сайт через HTTP.²⁵
Конфігурація сервера: Іноді проблема може бути глибше:

Обмеження фаєрволом/безпекою: Серверний фаєрвол або інструменти безпеки можуть блокувати IP-адреси сервісів, необхідних для роботи деяких функцій (наприклад, Cloudflare або Jetpack).²⁶
PHP Сесії: Неправильна конфігурація PHP-сесій на сервері.¹⁴
Проксі-сервери: Некоректна робота зворотного проксі (наприклад, Nginx перед Apache) може заважати передачі cookies.²⁵
Ресурси сервера: Недостатньо ресурсів (пам’яті, процесорного часу) для обробки запитів, особливо на великих Multisite мережах.¹⁴

Важливо розуміти, що ці причини часто взаємопов’язані. Наприклад, конфлікт плагіна ¹ може проявитися через “неочікуваний вивід” ¹⁵, що призведе до помилки cookie. Міграція сайту ⁴ може спричинити неправильні URL в базі даних ² або проблеми з .htaccess ³, що також викличе проблеми з cookie. Тому діагностика вимагає системного підходу, перевіряючи різні можливі точки збою, а не припускаючи одну ізольовану причину.

Кроки з усунення несправностей: Від простих до складних

Тепер перейдемо до практичних кроків, які допомогли мені (і, сподіваюся, допоможуть вам) вирішити цю проблему. Рухатися будемо від найпростіших і найменш інвазивних методів до більш складних.

Крок 1: Базові перевірки браузера

Це перше, що варто зробити, оскільки це найпростіше і часто допомагає.

Оновлення сторінки (Hard Refresh): Не просто натисніть F5. Використовуйте “жорстке” оновлення, щоб змусити браузер завантажити всі ресурси заново, ігноруючи кеш. Комбінації клавіш: Windows/Linux: Ctrl+F5 або Ctrl+Shift+R, Mac: Cmd+Shift+R.¹
Очищення кешу та Cookies браузера: Це критично важливий крок, особливо якщо помилка з’явилася після міграції або змін на сайті.¹ Потрібно повністю очистити кеш та видалити всі cookies, пов’язані з вашим сайтом. Процедура трохи відрізняється для різних браузерів (див. таблицю нижче).
Спробуйте інший браузер: Зайдіть на сторінку входу вашого сайту через інший браузер (Chrome, Firefox, Edge, Safari), яким ви зазвичай не користуєтеся. Якщо вхід вдається, проблема, швидше за все, у налаштуваннях, розширеннях або кеші вашого основного браузера.¹
Спробуйте режим Incognito/Private: Відкрийте вікно в режимі інкогніто (приватного перегляду) і спробуйте увійти. Цей режим зазвичай запускається без розширень і не використовує існуючий кеш та cookies. Якщо вхід вдається, винуватцем є або кеш/cookies, або якесь розширення у вашому звичайному режимі.⁷

Крок 2: Як переконатися, що Cookies увімкнені у вашому браузері

Хоча помилка часто не пов’язана з глобальним блокуванням cookies, перевірити налаштування браузера все ж варто. Особливу увагу зверніть на налаштування сторонніх cookies (third-party cookies), оскільки вони можуть впливати на роботу в певних сценаріях WordPress, таких як Multisite з мапуванням доменів або використання зовнішніх сервісів автентифікації.⁸

Ось коротка інструкція для найпопулярніших браузерів:

Браузер	Кроки для доступу до налаштувань Cookies	Рекомендовані налаштування
Google Chrome	1. Натисніть три крапки у верхньому правому куті → Налаштування. <br> 2. Перейдіть до Конфіденційність і безпека → Файли cookie та інші дані із сайтів. <br> (Або введіть chrome://settings/cookies в адресний рядок).⁶	Переконайтеся, що вибрано Дозволити всі файли cookie. Або, якщо ви блокуєте сторонні файли cookie, перевірте список винятків і додайте до нього ваш домен WordPress (особливо актуально для Multisite/WordPress.com з власним доменом ⁹). Можна спробувати тимчасово вибрати “Дозволити всі файли cookie”.
Mozilla Firefox	1. Натисніть три риски у верхньому правому куті → Налаштування. <br> 2. Перейдіть до Приватність і Безпека. <br> 3. Прокрутіть до розділу Куки і дані сайтів. <br> (Або введіть about:preferences#privacy в адресний рядок).¹⁴	У розділі Посилений захист від стеження виберіть Стандартний (зазвичай дозволяє необхідні cookies) або Власний і переконайтеся, що опція “Куки” не встановлена на “Усі куки (призведе до несправності сайтів)”. Перевірте налаштування блокування сторонніх cookies. Можна спробувати тимчасово вимкнути блокування.
Apple Safari	1. У меню Safari виберіть Параметри…. <br> 2. Перейдіть на вкладку Конфіденційність.⁹	Зніміть прапорець Запобігати міжсайтовому відстеженню (це може впливати на third-party cookies). Переконайтеся, що опція Блокувати всі файли cookie не увімкнена.⁹ Можливо, доведеться тимчасово зняти прапорець “Запобігати міжсайтовому відстеженню”.
Microsoft Edge	1. Натисніть три крапки у верхньому правому куті → Налаштування. <br> 2. Перейдіть до Файли cookie та дозволи для сайтів → Керування файлами cookie та даними сайтів і їх видалення. <br> (Або введіть edge://settings/content/cookies в адресний рядок).²⁸	Переконайтеся, що увімкнено Дозволити сайтам зберігати та читати дані файлів cookie (рекомендовано). Перевірте налаштування Блокувати сторонні файли cookie. Якщо воно увімкнено, спробуйте тимчасово вимкнути його або додати ваш сайт до списку дозволених.

Після зміни налаштувань обов’язково перезавантажте браузер і спробуйте увійти знову.

Крок 3: Деактивація плагінів для виявлення конфліктів

Якщо базові перевірки браузера не допомогли, наступний логічний крок – перевірити плагіни.¹

Якщо ви не можете увійти в адмін-панель (найімовірніший сценарій при цій помилці):

Підключіться до вашого сайту за допомогою FTP-клієнта (наприклад, FileZilla) або через Файловий менеджер у панелі керування вашого хостингу.
Перейдіть до папки $wp-content.
Знайдіть папку $plugins і перейменуйте її на щось інше, наприклад, $plugins-deactivated або $plugins_old.¹ Це миттєво деактивує всі плагіни на вашому сайті.
Спробуйте увійти до адмін-панелі WordPress (/wp-admin/).
Якщо вхід вдався, значить, проблема була в одному з плагінів.
Поверніться до FTP/Файлового менеджера і перейменуйте папку $plugins-deactivated назад на $plugins.
Тепер заходьте в папку $plugins і перейменовуйте папки кожного плагіна по черзі (наприклад, додаючи _ в кінець назви), щоразу перевіряючи, чи можете ви увійти. Коли після перейменування чергової папки плагіна вхід стане можливим, ви знайшли винуватця.¹
Особливу увагу приділіть плагінам безпеки та кешування, спробуйте деактивувати їх першими.¹

Якщо ви можете увійти (наприклад, помилка виникає періодично або після певних дій):

Перейдіть до розділу “Плагіни” -> “Встановлені плагіни”.
Виділіть усі плагіни (поставте галочку зверху).
У випадаючому меню “Масові дії” виберіть “Деактивувати” і натисніть “Застосувати”.¹⁵
Перевірте, чи зникла проблема.
Якщо так, активуйте плагіни по одному, щоразу перевіряючи наявність помилки, доки не знайдете конфліктний плагін.

Коли знайдете проблемний плагін, ви можете спробувати оновити його, перевірити його налаштування (можливо, вони надто суворі ¹), звернутися до розробника або знайти альтернативу.

Крок 4: Перемикання на стандартну тему WordPress

Якщо деактивація плагінів не допомогла, наступний підозрюваний – ваша активна тема.²

Підключіться до сайту через FTP або Файловий менеджер.
Перейдіть до папки $wp-content/themes/.
Знайдіть папку вашої активної теми і перейменуйте її (наприклад, додайте _old в кінець назви).²
WordPress не знайде активну тему і автоматично перемкнеться на одну зі стандартних тем (наприклад, Twenty Twenty-Three, Twenty Twenty-Four).
Спробуйте увійти до адмін-панелі.
Якщо вхід вдається, проблема у вашій темі. Вам потрібно буде або оновити тему, або звернутися до розробника, або вибрати іншу тему. Якщо проблема не зникла, поверніть оригінальну назву папки вашої теми і переходьте до наступного кроку.

Крок 5: Перевірка URL-адрес WordPress та сайту

Неправильні або неузгоджені URL-адреси – ще одна можлива причина.

Якщо ви змогли увійти (після деактивації плагінів/теми): Перейдіть у “Налаштування” -> “Загальні”. Переконайтеся, що поля “Адреса WordPress (URL)” та “Адреса сайту (URL)” містять однакову, правильну адресу вашого сайту, включаючи правильний протокол (HTTP або HTTPS).
Якщо ви не можете увійти:

Вам знадобиться доступ до бази даних вашого сайту, зазвичай через інструмент phpMyAdmin у панелі керування хостингом.
Знайдіть вашу базу даних WordPress і відкрийте таблицю $wp_options (префікс wp_ може бути іншим).
Знайдіть у цій таблиці рядки з option_name рівними siteurl та home.
Перевірте значення в колонці option_value для цих двох рядків. Вони мають містити правильну та однакову URL-адресу вашого сайту з правильним протоколом (наприклад, https://yourdomain.com).² Якщо вони неправильні, відредагуйте їх.

Крок 6: Перевірка файлу .htaccess

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

Підключіться до сайту через FTP або Файловий менеджер.
Знайдіть файл .htaccess у кореневій папці вашого сайту (це прихований файл, можливо, вам доведеться увімкнути відображення прихованих файлів у вашому FTP-клієнті/менеджері).
Завантажте копію цього файлу на свій комп’ютер як резервну копію.²
Видаліть файл .htaccess з сервера.
Спробуйте увійти до адмін-панелі WordPress.
Якщо вхід вдається, проблема була у файлі .htaccess. Щоб згенерувати новий, чистий файл, зайдіть в адмін-панель (якщо ви вже там), перейдіть у “Налаштування” -> “Постійні посилання” і просто натисніть кнопку “Зберегти зміни” (нічого не змінюючи). WordPress автоматично створить стандартний .htaccess.²

Крок 7: Перевірка PHP файлів на наявність зайвих пробілів (wp-config.php, functions.php)

Це особливо актуально, якщо ви бачите помилку “Cookies are blocked due to unexpected output”.¹⁵

Через FTP/Файловий менеджер відкрийте для редагування файл $wp-config.php (знаходиться у кореневій папці сайту).
Уважно перевірте початок файлу: перед <?php не повинно бути жодних символів, пробілів або порожніх рядків.¹⁵
Перевірте кінець файлу: після завершального ?> (якщо він є) не повинно бути жодних символів, пробілів або порожніх рядків. Найкраща практика – взагалі видалити кінцевий тег ?> з файлу $wp-config.php та $functions.php, якщо він там є.¹⁵ PHP чудово працює і без нього, а це усуває ризик випадкового додавання зайвих символів після нього.
Збережіть зміни у $wp-config.php.
Повторіть ту саму перевірку для файлу $functions.php вашої активної теми (знаходиться у $wp-content/themes/your-theme-name/). Якщо ви використовуєте дочірню тему, перевірте $functions.php саме дочірньої теми.
Також переконайтеся, що ці файли збережені у кодуванні UTF-8 без BOM (Byte Order Mark). Деякі текстові редактори (наприклад, старі версії Notepad++) можуть додавати невидимий символ BOM на початку файлу, що також вважається “неочікуваним виводом”.²⁴ Використовуйте редактор коду (наприклад, VS Code, Sublime Text, Notepad++), який дозволяє явно вказати кодування “UTF-8” або “UTF-8 without BOM”.

Логіка послідовності цих кроків полягає в тому, щоб почати з найпростіших і найменш ризикованих дій (перевірки на стороні клієнта – браузера), потім перейти до поширених проблем у WordPress, які можна вирішити без редагування коду (деактивація плагінів/тем, перевірка налаштувань URL, .htaccess), і лише в останню чергу вдаватися до редагування критично важливих файлів конфігурації та коду, що несе більший ризик.

Розширені рішення: Редагування файлів ядра (Використовуйте обережно!)

Якщо попередні кроки не допомогли, можливо, доведеться вдатися до редагування основних конфігураційних файлів WordPress: $wp-config.php та $functions.php.

!!! ВАЖЛИВО!!! Перш ніж редагувати будь-який з цих файлів:

Зробіть повну резервну копію вашого сайту (файлів та бази даних)!.¹ Неправильна кома або лапки у цих файлах можуть повністю “зламати” ваш сайт (викликати “білий екран смерті”).
При редагуванні $functions.php завжди використовуйте дочірню тему, якщо це можливо. Це запобігає втраті ваших змін при оновленні батьківської теми.¹
Будьте готові швидко відновити оригінальні файли через FTP/Файловий менеджер, якщо щось піде не так.

Модифікація $wp-config.php (Додавання констант для Cookies)

Редагування $wp-config.php часто допомагає вирішити проблеми з невідповідністю домену або шляху cookie, особливо після міграції або в складних конфігураціях Multisite.¹

Код потрібно додавати у файл $wp-config.php перед рядком:

/* That’s all, stop editing! Happy publishing. */

(або /* Це все, далі не редагуйте! Щасливих публікацій. */)

Ось кілька варіантів констант, які можна спробувати (зазвичай потрібна лише одна з опцій для COOKIE_DOMAIN, але іноді її доповнюють іншими константами):

Варіант 1 (Динамічний COOKIE_DOMAIN):
PHP
define(‘COOKIE_DOMAIN’, $_SERVER );
Пояснення: Встановлює домен cookie на основі того домену, який запитує браузер. Часто рекомендується для простих сайтів ¹, але може викликати проблеми в Multisite з мапуванням доменів або за проксі-серверами.⁵
Варіант 2 (Статичний COOKIE_DOMAIN з крапкою):
PHP
define( ‘COOKIE_DOMAIN’, ‘.yourdomain.com’ ); // ЗАМІНІТЬ yourdomain.com НА ВАШ ДОМЕН!
Пояснення: Явно вказує основний домен. Крапка на початку .yourdomain.com робить cookie доступним для всіх субдоменів (наприклад, www.yourdomain.com, blog.yourdomain.com), що може бути корисним для Multisite на субдоменах, якщо потрібен єдиний вхід.²
Варіант 3 (COOKIE_DOMAIN порожній рядок – часто для Multisite):
PHP
define(‘COOKIE_DOMAIN’, ”);
Пояснення: Це значення за замовчуванням. Воно змушує WordPress встановлювати cookies тільки для конкретного домену/субдомену, з якого прийшов запит. Це часто є найкращим рішенням для Multisite з різними доменами або субдоменами, оскільки запобігає конфліктам між сайтами мережі.
Варіант 4 (COOKIE_DOMAIN як false – для Multisite з мапуванням):
PHP
define(‘COOKIE_DOMAIN’, false);
Пояснення: Іноді цей варіант рекомендують саме для Multisite з мапуванням доменів.⁸ Однак результати можуть бути непередбачуваними, і деякі користувачі повідомляли про проблеми з цим налаштуванням.³¹ Використовуйте з обережністю.
Додаткові константи шляхів (іноді потрібні разом з COOKIE_DOMAIN, особливо в Multisite):
PHP
define(‘ADMIN_COOKIE_PATH’, ‘/’);
define(‘COOKIEPATH’, ”);
define(‘SITECOOKIEPATH’, ”);
Пояснення: Ці константи визначають шлях на сервері, для якого дійсні різні типи cookies (адміністративні, сайту, мережі). Встановлення їх у ‘/’ (корінь сайту) або ” (за замовчуванням) може допомогти забезпечити їхню доступність по всьому сайту або мережі, особливо якщо WordPress встановлено не в кореневому каталозі або в складних конфігураціях Multisite.¹⁴ Часто комбінація define(‘COOKIE_DOMAIN’, ”); разом із цими трьома константами вирішує проблеми в Multisite.³²

Важливо: Після додавання або зміни цих констант збережіть файл $wp-config.php, завантажте його на сервер і обов’язково повністю очистіть кеш та cookies вашого браузера, перш ніж пробувати увійти знову. Спробуйте різні варіанти COOKIE_DOMAIN (по одному!), якщо перший не спрацював.

Якщо редагування $wp-config.php не дало результату, можна спробувати додати спеціальний код у файл $functions.php вашої (бажано дочірньої) теми. Цей метод намагається примусово встановити тестовий cookie WordPress, що іноді допомагає обійти проблеми з конфігурацією шляхів.¹

Додайте наступний код в кінець файлу $functions.php:

PHP

if ( SITECOOKIEPATH!= COOKIEPATH ) {
setcookie(TEST_COOKIE, ‘WP Cookie check’, 0, SITECOOKIEPATH, COOKIE_DOMAIN);
}

Або спробуйте цей варіант, який зустрічається в кількох джерелах ²:

PHP

setcookie(TEST_COOKIE, ‘WP Cookie check’, 0, COOKIEPATH, COOKIE_DOMAIN);
if ( SITECOOKIEPATH!= COOKIEPATH ) {
setcookie(TEST_COOKIE, ‘WP Cookie check’, 0, SITECOOKIEPATH, COOKIE_DOMAIN);
}

Або ще один варіант:

PHP

setcookie( ‘wordpress_test_cookie’, ‘WP Cookie check’, time() + ( 3600 ), COOKIEPATH, COOKIE_DOMAIN, is_ssl() );

Після додавання коду збережіть файл, завантажте його на сервер і обов’язково повністю очистіть кеш та cookies браузера.¹

Пам’ятайте про ризики: Редагування файлів ядра – це потужний інструмент, але він несе ризик. Дослідження показують, що немає єдиного “чарівного” рішення, особливо для COOKIE_DOMAIN у Multisite.⁸ Різні конфігурації серверів та сайтів можуть вимагати різних підходів. Тому наголошую ще раз: робіть бекапи і будьте готові відкотити зміни. Вдавайтеся до цих методів лише після того, як вичерпали безпечніші варіанти.

Фокус на WordPress Multisite: Вирішення проблем з Cookies у мережевих інсталяціях

WordPress Multisite дозволяє створити мережу сайтів на одній інсталяції WordPress.³⁴ Це зручно, але саме ця архітектура створює додаткові складнощі для управління cookies, що робить помилку “Cookies заблоковані” особливо поширеною в таких середовищах.

Унікальні виклики Multisite

Структура: Мережа може використовувати субдомени (site1.yourdomain.com) або підкаталоги (yourdomain.com/site1).³⁴
Мапування доменів: Це функція, яка дозволяє призначати окремі, унікальні домени (наприклад, myclient.com) сайтам всередині мережі Multisite.¹⁴ Хоча це зручно для клієнтів або різних проектів, саме мапування доменів є основною причиною проблем з cookies у Multisite.¹⁴
Спільні та окремі Cookies: Система повинна коректно обробляти cookies як для головного сайту мережі, так і для кожного підсайту (або зіставленого домену). Іноді потрібен єдиний вхід (Single Sign-On) для всієї мережі, що вимагає спільного доступу до cookies, а іноді cookies мають бути ізольовані для кожного сайту.⁸
Проблема “Third-Party” Cookies: Коли ви намагаєтеся увійти на сайт із зіставленим доменом (mappeddomain.com), але cookie автентифікації встановлено для основного домену мережі (maindomain.com), браузер може сприйняти це як спробу використання стороннього (third-party) cookie і заблокувати його відповідно до налаштувань конфіденційності.⁸

Через ці фактори управління cookies у Multisite значно складніше, ніж на окремому сайті. Взаємодія між ядром WordPress, налаштуваннями мережі, конфігурацією мапування доменів та середовищем сервера створює безліч потенційних точок збою, яких немає у звичайних інсталяціях WordPress.

Перевірка конфігурації доменів/субдоменів Multisite

DNS: Переконайтеся, що DNS-записи для всіх субдоменів та зіставлених доменів правильно налаштовані та вказують на ваш сервер. Для субдоменів зазвичай потрібен wildcard DNS запис (*) або окремі записи для кожного субдомену. Для зіставлених доменів потрібні відповідні A-записи або CNAME.
Налаштування мережі: В адмін-панелі мережі (Network Admin -> Settings -> Network Settings) перевірте основні налаштування мережі.¹⁴
Мапування доменів: Якщо ви використовуєте мапування, перевірте його налаштування. У сучасних версіях WordPress мапування вбудоване, але раніше використовувалися плагіни. Переконайтеся, що домени правильно додані та прив’язані до відповідних сайтів мережі.⁵ Наприклад, користувач повідомив, що проблема зникла після того, як він додав запис мапування для сайту.⁵

Критично важливі константи $wp-config.php для Multisite

Правильне налаштування констант у файлі $wp-config.php є ключовим для стабільної роботи cookies у Multisite.

COOKIE_DOMAIN: Як вже зазначалося, це найважливіша константа.⁵ Вибір правильного значення залежить від структури вашої мережі. Через суперечливі поради в різних джерелах, ось спроба систематизувати рекомендації:

Тип конфігурації Multisite	Рекомендоване значення COOKIE_DOMAIN	Пояснення/Примітки	Приклади Snippet IDs
Субдомени (без мапування)	” (порожній рядок) АБО .yourmaindomain.com (з крапкою)	” дозволяє кожному субдомену мати свої cookies (безпечніше). .yourmaindomain.com дозволяє єдиний вхід (SSO) для всіх субдоменів.	⁸
Підкаталоги (без мапування)	” (порожній рядок)	Зазвичай це стандартна і робоча конфігурація. Cookies встановлюються для основного домену.	¹⁴
Субдомени з мапуванням доменів	” (порожній рядок) АБО false (з обережністю!)	” є найбезпечнішим варіантом, що дозволяє кожному сайту (включаючи зіставлені) використовувати свої cookies. false іноді допомагає ³¹, але може бути нестабільним.³¹ Уникайте $_SERVER! ⁵	¹⁴
Підкаталоги з мапуванням доменів	” (порожній рядок)	Зазвичай ” працює найкраще, дозволяючи зіставленим доменам мати власні cookies.	¹⁴

COOKIEPATH, SITECOOKIEPATH, ADMIN_COOKIE_PATH: Ці константи визначають шлях, для якого дійсні cookies. У більшості випадків їх можна залишити невизначеними (WordPress використає значення за замовчуванням) або встановити як ” або ‘/’. Це особливо важливо, якщо ваша інсталяція WordPress знаходиться в підкаталозі.³² Часто для вирішення проблем у Multisite використовують таку комбінацію ¹⁴:
PHP
define(‘ADMIN_COOKIE_PATH’, ‘/’);
define(‘COOKIE_DOMAIN’, ”); // Або інше значення з таблиці вище
define(‘COOKIEPATH’, ”);
define(‘SITECOOKIEPATH’, ”);
Інші константи:

Переконайтеся, що константи MULTISITE, SUBDOMAIN_INSTALL (має бути true для субдоменів, false для підкаталогів), DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE, SITE_ID_CURRENT_SITE, BLOG_ID_CURRENT_SITE визначені правильно відповідно до вашої інсталяції.²¹ Неправильне значення SUBDOMAIN_INSTALL може спричинити дивні проблеми.⁸ Один користувач повідомив, що зміна DOMAIN_CURRENT_SITE на $_SERVER допомогла, хоча це не стандартна практика.³¹
Якщо ви бачите define(‘SUNRISE’, ‘on’);, це може бути залишком старого методу мапування доменів і потенційно конфліктувати з сучасними механізмами WordPress.³⁵

Перевірка таблиць бази даних Multisite

Неправильні записи в базі даних також можуть бути причиною проблем. Використовуйте phpMyAdmin для перевірки наступних таблиць ²²:

$wp_blogs: Перевірте стовпці domain та path для кожного сайту в мережі. Вони мають відповідати реальним адресам.
$wp_site: Перевірте domain та path для основного сайту мережі.
$wp_sitemeta: Перевірте мета-дані сайту, особливо siteurl.
$wp_X_options (де X – ID сайту): Для кожного сайту (особливо для тих, що використовують мапування доменів) перевірте значення siteurl та home. Вони мають містити правильну URL-адресу саме цього сайту (наприклад, https://mappeddomain.com), а не основного домену мережі.²¹

Використання WP_DEBUG для поглибленої діагностики

Якщо ви все ще не можете знайти причину, інструмент налагодження WordPress WP_DEBUG може стати вашим найкращим другом. Він допомагає виявити приховані PHP помилки, попередження або повідомлення, які можуть бути причиною “неочікуваного виводу” або інших проблем, що заважають роботі cookies.¹⁴

Як увімкнути:

Відкрийте файл $wp-config.php для редагування.
Знайдіть рядок: define( ‘WP_DEBUG’, false );
Змініть false на true: define( ‘WP_DEBUG’, true );
Додайте наступні рядки відразу під ним (або змініть існуючі, якщо вони є):
PHP
define( ‘WP_DEBUG_LOG’, true ); // Вмикає запис помилок у файл /wp-content/debug.log
define( ‘WP_DEBUG_DISPLAY’, false ); // Вимикає показ помилок на екрані сайту
@ini_set( ‘display_errors’, 0 ); // Додатково намагається приховати помилки з екрану
¹⁴
Збережіть файл $wp-config.php.

Аналіз:

Тепер спробуйте знову виконати дію, яка викликає помилку cookie (наприклад, спробуйте увійти). Після цього перевірте вміст файлу debug.log, який має з’явитися у вашій папці /wp-content/. Шукайте повідомлення про помилки (Error), попередження (Warning) або повідомлення (Notice), які можуть вказувати на конкретний файл плагіна чи теми та номер рядка, де виникає проблема.15 Це може дати вам ключ до розгадки.

Важливо: Після завершення діагностики обов’язково поверніть WP_DEBUG у значення false:

define( ‘WP_DEBUG’, false );

Залишати режим налагодження увімкненим на робочому сайті небезпечно і може призвести до розростання лог-файлу.14

Запобігання майбутнім помилкам Cookies

Щоб мінімізувати ризик повторення цієї неприємної помилки у майбутньому, дотримуйтесь кількох простих правил:

Регулярні оновлення: Своєчасно оновлюйте ядро WordPress, усі теми та плагіни. Застаріле програмне забезпечення – часта причина конфліктів.¹⁵ Оновлюйте плагіни по одному, а не всі одразу, щоб легше було виявити проблему, якщо вона виникне.¹⁸
Надійні теми та плагіни: Встановлюйте теми та плагіни тільки з перевірених джерел (наприклад, офіційного каталогу WordPress.org) або від розробників з хорошою репутацією.¹⁶ Перед встановленням перевіряйте сумісність з вашою версією WordPress та відгуки інших користувачів.¹⁷
Чистий код: Якщо ви додаєте власний PHP-код (наприклад, у $functions.php або через плагіни), робіть це акуратно. Уникайте зайвих пробілів до <?php та після ?>. Використовуйте спеціалізовані плагіни, такі як Code Snippets ² або WPCode ¹⁵, для безпечного додавання та керування фрагментами коду.
Регулярні бекапи: Це золоте правило. Завжди створюйте повну резервну копію сайту перед будь-якими значними змінами, оновленнями або редагуванням файлів.³
Використання Staging-середовища: Якщо ваш хостинг надає таку можливість, завжди тестуйте оновлення плагінів, тем, ядра WordPress та будь-які зміни коду на проміжному (staging) сайті, перш ніж застосовувати їх на живому сайті.¹⁸ Це найкращий спосіб уникнути несподіваних проблем.
Правильна конфігурація Multisite: Якщо у вас Multisite, приділіть особливу увагу правильному налаштуванню констант у $wp-config.php (COOKIE_DOMAIN тощо) відповідно до структури вашої мережі та використання мапування доменів.
Моніторинг: Час від часу перевіряйте лог помилок вашого сервера (error log) та, за потреби, активуйте WP_DEBUG для перевірки логу WordPress.²⁴

Висновок: Повернення доступу до панелі керування WordPress

Помилка “Cookies заблоковані або не підтримуються” може бути справді неприємною, особливо коли вона виникає несподівано і блокує доступ до власного сайту. Як ми побачили, причини можуть бути різноманітними: від простих налаштувань браузера до складних конфігурацій на сервері, конфліктів плагінів/тем або специфічних проблем WordPress Multisite.

Ключ до вирішення – це систематичний підхід до діагностики. Починайте з найпростіших кроків (перевірка браузера, очищення кешу), поступово переходьте до деактивації плагінів та тем, перевірки налаштувань URL та файлу .htaccess, і лише в крайньому випадку вдавайтеся до редагування файлів $wp-config.php та $functions.php, пам’ятаючи про необхідність резервного копіювання та обережність. Для користувачів Multisite особливо важливо ретельно перевірити конфігурацію мережі та налаштування COOKIE_DOMAIN.

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

Успіхів!

Як виправити помилку “Cookies заблоковані або не підтримуються” у WordPress (включно з Multisite)