Как в WordPress изменить время жизни сессии (таймаут), чтобы не прерывалось редактирование страниц?

Всем привет! При редактировании записи в стандартном редакторе WordPress админ-панель «вылетает». <br/> Ситуация: <br/> 1. Открываю запись для редактирования. <br/> 2. Переключаюсь на другую вкладку (чтобы что-то прочитать или скопировать). <br/> 3. Через несколько секунд возвращаюсь в вкладку с редактором — появляется всплывающее окно WP с требованием ввести пароль заново; редактирование и сохранение становятся невозможными. <br/> Что пробовала: отключала/включала Wordfence — не помогло; служба хостинга утверждает, что проблема не на их стороне; в списке заблокированных IP моего адреса нет. <br/> Подозреваю, что дело в настройках Wordfence. Куда ещё смотреть и как это можно исправить? Подскажите, пожалуйста, кто сталкивался.
  • 10 июля 2026 г. 11:00
Ответы на вопрос 2
Кратко — что происходит и куда смотреть
- Скорее всего вас «выбрасывает» не из-за обычного WP-куки (они живут по умолчанию днями), а из‑за истечения nonce/сессии REST/или блокировки со стороны безопасности. Редактор (Gutenberg / REST API) активно использует nonce и AJAX-запросы, и если запросы возвращают 401/403 или «nonce expired», редактор покажет окно входа.
- Надо сначала диагностировать, а затем менять либо время жизни nonce/auth-cookie, либо настройки PHP-сессий/защитных плагинов/файрвола.

Что проверить в первую очередь (диагностика)
1. Откройте DevTools (F12) → Network → фильтруйте XHR/fetch. Вернитесь на вкладку редактора и посмотрите, какие запросы выполняются и какие статусы приходят (401/403/302/500).  
   - Если видите ответ вида «Login required», «You are not allowed to edit this post» или 403 — это подсказка.
   - Если видите в ответе «nonce is invalid» / «nonce expired» — явно проблема с nonce.
2. В Console проверьте ошибки JS и сообщения о невалидном nonce или блокировке.
3. Application → Cookies — есть ли cookies wordpress_logged_in_* и wordpress_sec_*; меняются ли они при возврате?
4. Повторите в другом браузере/инкогнито. Повлиял ли отключённый Wordfence? Попробуйте полностью отключить все плагины и тему переключить на Twenty* — если проблема уходит, включайте по одному.
5. Проверьте серверные логи, мод_security, WAF (Cloudflare, серверный firewall). Иногда правило WAF блокирует запросы REST API и возвращает 403.

Варианты исправления

A) Увеличить время жизни nonce (если дело в нонсе)
Добавьте в functions.php (или через плагин Code Snippets):

// увеличить время жизни nonce до 24 часов
add_filter( 'nonce_life', function() {
    return 24 * 60 * 60; // секунда*минут*час = 24 часа
} );

По умолчанию nonce живёт 12–24 часа (в разных источниках фигурирует 24 часа), но при проблемах можно увеличить.

B) Увеличить время жизни куки авторизации (auth cookie)
Если вас разлогинивает, можно изменить время жизни куки:

function my_auth_cookie_expiration( $length, $user_id, $remember ) {
    // если галочка «Запомнить» — 14 дней, иначе 2 дня (можете поставить больше)
    return $remember ? 14 * DAY_IN_SECONDS : 2 * DAY_IN_SECONDS;
}
add_filter( 'auth_cookie_expiration', 'my_auth_cookie_expiration', 10, 3 );

C) Проверьте PHP-сессии (если сайт использует PHP-сессии)
Если сессии обрываются на уровне PHP (session.gc_maxlifetime), увеличьте:

В php.ini или .user.ini:
session.gc_maxlifetime = 14400  ; (например 4 часа в секундах)

И/или в .htaccess (если поддерживается):
php_value session.gc_maxlifetime 14400

После изменения перезапустите PHP-FPM / веб-сервер при необходимости.

D) Heartbeat API
Иногда Heartbeat (wp‑heartbeat) взаимодействует с блокировками. Попробуйте увеличить интервал heartbeats (плагин Heartbeat Control) — не отключайте полностью, иначе пропадут автосохранение и блокировки по редактированию.

E) Проверьте WAF / прокси / кеш
- Cloudflare, nginx reverse proxy, CDN или мод_security могут прерывать REST/админ-запросы. Отключите временно WAF или смотрите логи/правила.
- Кеширующие плагины не должны кэшировать /wp-admin/* или REST-запросы. Убедитесь в этом.

F) Проверка Wordfence / других security-плагинов
- В Wordfence проверьте настройки «Brute Force Protection» и «Lock out after how many failed login attempts»,/«Immediately block IPs that show malicious activity» и опции Live Traffic. Иногда есть опции, которые разлогинивают пользователей при подозрительной активности.
- Полностью деактивируйте Wordfence и протестируйте. (Вы говорили, отключали — но сделайте и очистку кэша/перезапуск).

Рекомендации по безопасной настройке
- Не ставьте слишком большое время жизни куки/nonce без понимания рисков — это снижает безопасность.
- Лучше: найти причину (WAF/плагин/сервер) и исправить её. Увеличение nonce — быстрый обход, но не всегда правильный.

Если хотите — помогу дальше
- Приложите скриншот Network (XHR) с проблемным запросом (статус + тело ответа) — скажу точнее.
- Напишите, используете ли Cloudflare/облачный WAF, какие security‑плагины и хостинг.
это <code>wp-auth-check.js</code> : хартбит дёргает <code>admin-ajax.php?action=heartbeat</code> , и модалка вылезает когда пришёл нормальный ответ, но в нём <code>"wp-auth-check": false</code> — то есть WP реально не признаёт куку. Глянь DevTools → Network в момент когда окно всплывает: если в JSON именно это поле false, копай куку/домен (http vs https), время на сервере, смену пароля или «завершить все сессии» в другой вкладке, плагины лимита сессий. Если там вместо этого <code>nonces_expired</code> — это отдельная история про протухший nonce, а не про саму сессию. А вот 403, таймаут или пустой ответ на сам heartbeat-запрос это уже не WP — что-то режет запрос раньше (хостинг, WAF, Cloudflare, необязательно Wordfence).
Похожие вопросы