Излезте от режим на поддръжка на WordPress за 2 минути

by | WordPress

Ако сайтът ви внезапно покаже „За кратко време не е наличен поради планирана поддръжка“ и откаже да се върне онлайн, почти винаги сте в затруднено положение. .maintenance заседнал след актуализация.

Проблемът

Типичното съобщение (front-end и понякога wp-admin) изглежда така:

Briefly unavailable for scheduled maintenance. Check back in a minute.

Обикновено го виждате:

  • След актуализация (WordPress 6.9.4, плъгин, тема), особено ако връзката е прекъсната по средата.
  • След „пакетна“ актуализация (10+ плъгина едновременно) или чрез инструмент за кеширане/оптимизация, който пречи.
  • На предната част (посетителите са блокирани), а понякога и в / WP-администратор / в зависимост от конфигурацията.
  • На споделен хостинг където разрешенията за файлове са ограничени или с ограничение на CPU/IO, което води до „изтичане на времето за изчакване“ на актуализацията.

В крайна сметка ще знаете:

  • Излезте от режим на поддръжка, като 2 минути (изтриване на файл) .maintenance).
  • Проверяващият pourquoi Заседна (разрешения, кеш, PHP, дефектен плъгин).
  • Рестартирайте актуализацията правилно, без да попадате отново в капана.

Бързо обобщение

  • „Заключеният режим на поддръжка“ е почти винаги fichier .maintenance забравен в основата на WordPress.
  • Бързо решение: чрез FTP/файлов мениджър, изтриване /.maintenance.
  • Следващия : Опитайте актуализацията отново (за предпочитане с едно действие) и проверете права et дневниците.
  • Ако се появи отново: подозирайте плъгин (кеш/сигурност), a Лимит на PHP, или a домакин което нарушава процесите.
  • За професионални сайтове: WP-CLI позволява по-чиста проверка/рестартиране.

Симптомите

Симптомите не се ограничават само до съобщението за поддръжка. Често съм виждал сайтове, които са актуализирани само „наполовина“ и оттам започват проблемите.

  • Съобщение за поддръжка в целия сайт, включително началната страница.
  • wp-admin е недостъпен или пренасочване към поддръжка.
  • 500 грешка след отстраняване на .maintenance (непълна актуализация, PHP неуспешно).
  • Бял екран (фатална грешка) след актуализиране на основен плъгин (конструктор, сигурност, електронна търговия).
  • Бутони „Актуализиране“, които се въртят в цикъл в /wp-admin/ (AJAX блокиран, администраторски кеш, конфликт на плъгини).
  • Сайтът е недостъпен само за някои посетители (CDN кеш или кеш) serveur което служи за стар отговор).

Бърза диагностична диаграма

симптом Вероятна причина проверка Решение
Съобщение „За кратко не е налично…“ Досие .maintenance остана присъстващ Наличие на /.maintenance в основата на WP Изтрий .maintenance (Решение 1)
Съобщението ще се появи отново след 1-2 минути. Актуализацията е рестартирана в цикъл / Cron / инструмент за автоматично актуализиране Проверете „Автоматични актуализации“ + лог файлове + кеш деактивирате временно автоматично актуализиране + corriger основна причина (Решение 3)
След изтриване: грешка 500 Непълна актуализация, конфликт на плъгини, фатален PHP PHP лог файлове / WP_DEBUG Деактивирайте плъгините, преинсталирайте плъгина/темата, проверете PHP (Решение 3)
Само за front-end, администраторът е ОК Кешът/CDN обслужва страницата за поддръжка Тествайте в режим на частно сърфиране + изчистване на кеша Почистване на кеша на плъгина/сървъра/CDN (Решение 3)
wp-admin блокиран, но предният интерфейс е ОК Административен кеш, плъгин за сигурност, бисквитки/сесия Конзола на браузъра + деактивиране на плъгин за сигурност Изчистване на кеша + деактивиране на плъгина (Решение 3)

Защо се случва това?

Просто обяснение (за начинаещи)

Когато WordPress актуализира ядрото си, плъгин или тема, той активира временен „режим на поддръжка“, за да предотврати зареждането на файлове, които се заменят, от посетителите. Този режим е представен от файл с име .maintenance в главната папка на WordPress.

Обикновено WordPress изтрива този файл в края на актуализацията. Ако актуализацията бъде прекъсната (прекъсване на мрежата, изчакване на сървъра, недостатъчни разрешения), файлът остава. В резултат на това вашият сайт остава в режим на поддръжка.

Техническо обяснение (средно ниво/професионално)

Режимът на поддръжка се задейства по време на операции по надграждане (надграждане на ядрото и плъгините). WordPress записва файл .maintenance в корена (на същото ниво като wp-config.php). При всяко зареждане WordPress тества присъствието и времевия си печат, след което предоставя страницата за поддръжка, ако се счита, че надстройката е в процес на изпълнение.

Какво причинява проблеми, според моя опит:

  • PHP таймаут по време на разархивиране/копиране (големи плъгини, конструктори, езикови пакети).
  • Разрешения за файлове WordPress не може да изтрие .maintenance или пишете wp-content/.
  • Агресивен кеш (кеш на плъгини, кеш на сървъра, CDN), който продължава да обслужва страницата „поддръжка“ дори след корекция.
  • Автоматични актуализации които незабавно стартират актуализация и пресъздават .maintenance.
  • конфликт на плъгини (сигурност, оптимизация), която блокира изходящите заявки или записа на диск.

Предварителни изисквания преди започване

Запазете, преди да правите каквито и да било промени. Дори ако решението е „просто изтриване на файл“, истинският риск е непълната актуализация, която следва.

  • Резервно копие файлове + база данни (чрез доставчика на хостинг услуги или надежден плъгин за архивиране).
  • Достъп до файлове FTP/SFTP или файлов мениджър (cPanel, Plesk, OVH Manager и др.).
  • Целева версия WordPress 6.9.4 (април 2026 г.) и PHP 8.1 + Препоръчително. Проверете съвместимостта с PHP на php.net.
  • Полезни инструменти :

За отстраняване на грешки, официалната справка остава Отстраняване на грешки в WordPress на developer.wordpress.org.

Решение 1: Изтрийте файла .maintenance (истинското решение след 2 минути)

Това е най-бързият метод и този, който използвам първо в 90% от случаите.

Къде точно да действате

  • В папката корен WordPress: къде обикновено се намират wp-config.php, wp-admin/, wp-includes/.
  • Файлът е с име: .maintenance (с точка в началото). Някои файлови мениджъри скриват „dotfiles“. Активирайте „Показване на скрити файлове“.

Стъпки (FTP/SFTP или файлов мениджър)

  1. Свържете се със сайта си чрез SFTP/FTP или чрез файловия мениджър.
  2. Отворете главната папка на WordPress.
  3. Намерете .maintenance.
  4. Изтрий .maintenance.
  5. Презаредете сайта си (в идеалния случай в режим на частно сърфиране).

Код ПРЕДИ/СЛЕД (за да разберете какво изтривате)

Файлът .maintenance Често съдържа малка PHP структура. Реалистичен пример:

ПРЕДИ (счупено: файлът остава)

<?php
/* Fichier généré automatiquement par WordPress pendant une mise à jour */
$upgrading = 1712700000;

СЛЕД (коригирано: файлът вече не съществува)

<?php
/* Rien ici : le fichier .maintenance a été supprimé */

Да, частта „СЛЕД“ звучи глупаво, но точно това е идеята: Не трябва да „коригирате“ този файлТрябва да го изтриете.

Защо това решава проблема?

WordPress проверява за наличието на този файл при зареждане. Докато съществува, WordPress приема, че е в ход актуализация (или е била актуализирана наскоро) и превключва към страницата за поддръжка. Изтриването му принуждава WordPress да възобнови нормалната си работа.

Ако файлът се върне веднага

Това се случва, когато автоматична актуализация (cron) се задейства циклично или когато инструмент за управление рестартира надстройката. В този случай изтрийте .maintenance след това отидете директно към Solution 3.

Решение 2: Излезте от режим на поддръжка чрез WP-CLI (бързо и чисто)

WP-CLI е официалният команден ред на WordPress. При по-реномирани доставчици на хостинг (или VPS), той често е по-надежден от уеб интерфейса, когато администраторският панел е нестабилен.

Официална справка: WP-CLI команди.

Предварителни

  • Да има SSH достъп.
  • Имате инсталиран WP-CLI (често вече наличен).
  • Да бъде в папката на WordPress (където е wp-config.php).

Полезни команди

1) Проверете дали сте на правилното място

wp core version

2) Изтрийте файла .maintenance (еквивалентно на Решение 1)

rm -f .maintenance

3) Проверете състоянието на актуализацията

wp core check-update
wp plugin list --update=available
wp theme list --update=available

4) Правилно рестартирайте актуализацията (правете това с повишено внимание)

wp core update
wp plugin update --all
wp theme update --all

сигурност: не стартирай update --all В продуктивна среда, ако нямате резервно копие и план за връщане към предишни версии, ще бъдете изложени на риск. Виждал съм сайтове да се счупват след актуализация на конструктора (Divi/Elementor/Avada), направена „на сляпо“.

Код ПРЕДИ/СЛЕД (често срещана грешка)

Често срещана грешка: стартиране на WP-CLI от грешна папка (не сте в инсталацията на WordPress).

ПРЕДНА (счупена)

cd ~
wp plugin update --all
# Error: This does not seem to be a WordPress installation.

СЛЕД (коригирано)

cd /var/www/votre-site/public_html
wp plugin update --all

Решение 3: Коригирайте основната причина (циклична актуализация, разрешения, кеш, PHP)

Излизането от режим на поддръжка е лесната част. Ако не отстраните причината, рискувате рецидив със следващата актуализация или, още по-лошо: частично актуализиран сайт.

3.1 Проверка и коригиране на правата (разрешенията) за файлове

Типичен симптом: актуализацията започва, след което се проваля, след което WordPress остава в режим на поддръжка или не завършва инсталацията.

  • Файлове: често 755
  • Файлове: често 644

На Linux през SSH (адаптирайте към вашата хостинг среда):

# À exécuter dans la racine WordPress
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;

Ако вашият доставчик на хостинг услуги използва конкретен собственик/група (www-data, nginx и др.), a chown Може да е необходимо, но няма да го имате на споделен хостинг. В такъв случай: заявете се за поддръжка при вашия доставчик на хостинг услуги.

Справка: Разрешения за файлове (developer.wordpress.org).

3.2 Изчистете кеша (плъгин, сървър, CDN), за да спрете показването на страницата за поддръжка

Често съм виждал файла .maintenance изтрито… но посетителят все още вижда страницата за поддръжка, защото кешът я обслужва.

  • Кеш на браузъра тествайте в режим на частно сърфиране.
  • Кеш на плъгините : изчистване от интерфейса му (ако е достъпно) или временно изтриване на кеш папката му (в зависимост от плъгина).
  • Кеш на сървъра (LiteSpeed, Nginx FastCGI кеш, Varnish): почистване чрез хостинг панел.
  • CDN (Cloudflare и др.): изчистете „Всичко“, ако е необходимо.

Ако използвате конструктор:

  • Диви 5 : изчистване на кеша на Divi (и статичния кеш, ако е активиран), след което регенериране, ако е необходимо.
  • Elementor „Инструменти“ > „Регенериране на CSS файлове и данни“.
  • Avada „Производителност“ > почистване на кеш паметта/компилацията.

Тези действия не „поправят“ WordPress, но предотвратяват фалшива диагноза („не работи“), когато става въпрос само за кеширана страница.

3.3 Проверка на PHP (версия, ограничения, време за изчакване) и фатални грешки

WordPress 6.9.4 работи много добре на PHP 8.1+. Ако все още използвате PHP 7.4/8.0 на стар сървър, увеличавате риска от неуспешни актуализации и несъвместимости на плъгините.

PHP справка: Директиви на php.ini.

Временно активирайте дебъгването в WordPress (на тестов сайт, ако е възможно). В wp-config.php, добавете/коригирайте:

<?php
/* Sauvegardez avant modification. À placer dans wp-config.php, avant "/* That's all, stop editing! */" */

/* Active le debug WordPress */
define( 'WP_DEBUG', true );

/* Écrit les erreurs dans wp-content/debug.log */
define( 'WP_DEBUG_LOG', true );

/* Évite d'afficher les erreurs aux visiteurs (sécurité) */
define( 'WP_DEBUG_DISPLAY', false );

След това се консултирайте wp-content/debug.logЧесто срещана грешка след непълна актуализация изглежда така:

PHP Fatal error:  Uncaught Error: Class "..." not found in /wp-content/plugins/...

В този случай, актуализацията на плъгина вероятно е била прекъсната. „Чистата“ корекция:

  • Преименувайте папката с плъгина, за да го деактивирате (напр. nom-plugin → nom-plugin.off).
  • Преинсталирайте плъгина от надежден източник (официален ZIP архив), ако е необходимо.

Справка за отстраняване на грешки: Отстраняване на грешки в WordPress.

3.4 Поправяне на прекъсната актуализация (плъгини/теми)

Много често срещан случай: актуализацията изтри старата папка, но не завърши копирането на новата.

Процедура (без код):

  1. Изтрий .maintenance.
  2. категория wp-content/plugins/, намерете плъгина, който е бил актуализиран точно преди блокирането.
  3. Преименувайте папката му, за да го деактивирате.
  4. Ако е възможно, свържете се отново с wp-admin.
  5. Преинсталирайте плъгина (или качете чиста версия).

Същата логика важи и за темите. wp-content/themes/Внимание: ако изтриете/преименувате активната тема, WordPress ще превключи към тема по подразбиране, ако има такава.

3.5 „КОД ПРЕДИ/СЛЕД“: фрагментът, който задейства неуспешна актуализация

Виждам го редовно: добавен е откъс в functions.php (или чрез плъгин за фрагмент) нарушава администраторския интерфейс по време на актуализация. Резултат: актуализацията започва, след това следващата заявка се срива и вие сте заседнали.

ПРЕДИ (неработещо: синтактична грешка, актуализацията е прекъсната)

<?php
/* Mauvais exemple : une parenthèse manque, PHP plante */
add_action( 'admin_init', function() {
	if ( current_user_can( 'manage_options' ) {
		update_option( 'mon_option', '1' );
	}
} );

СЛЕД (коригирано)

<?php
/* Bon exemple : syntaxe valide, et conditions claires */
add_action( 'admin_init', function() {
	if ( current_user_can( 'manage_options' ) ) {
		update_option( 'mon_option', '1' );
	}
} );

Ако наскоро сте добавили код, временно го деактивирайте, докато сайтът се стабилизира. И избягвайте да поставяте фрагменти, „намерени във форум“, които датират от 2017 г.: много от тях са несъвместими с PHP 8.1+.

Проверки след корекция

Не се задоволявайте само с това, че началният екран се завръща. Проверете дали актуализацията не е оставила непоследователно състояние.

  1. Front-End зареждане на 2-3 страници (начална страница, статия, страница за контакти).
  2. Admin : свържете се с /wp-admin/ и отидете на „Актуализации“.
  3. Разширения Проверете дали няма разширения, които са били „неволно деактивирани“.
  4. Здраве на сайта Инструменти > Състояние на сайта. Основно е, но често показва грешка в cron цикъл или имейл.
  5. Дневник поглед wp-content/debug.log (ако е активирано) и след това деактивирайте WP_DEBUG.
  6. Кеш : изчистване на кеша на плъгина/сървъра/CDN за последен път.

Когато всичко е наред, върнете се към нормален режим:

<?php
/* Une fois le diagnostic terminé, évitez de laisser WP_DEBUG à true en production */
define( 'WP_DEBUG', false );

Ако това все още не работи

Когато премахването на .maintenance Ако това не е достатъчно, сайтът често е в „полуобновено“ състояние. Ето процедура, която прилагам към клиентските сайтове, в този ред.

Стъпка 1: Потвърдете, че .maintenance вече не съществува

  • Проверете главната директория на WordPress.
  • Пазете се от кешовете: тествайте в режим на частно сърфиране + друга мрежа, ако е възможно.

Стъпка 2: Деактивирайте всички плъгини без wp-admin

Преименуване на папката wp-content/plugins en plugins.offWordPress ще деактивира всичко.

След това тествайте сайта. Ако проблемът се появи отново, причината е плъгин. Инсталирайте го отново. pluginsслед това преименувайте плъгин по плъгин.

Стъпка 3: Временно превключване към тема по подразбиране

Преименувайте активната тема (папка в wp-content/themes/), за да принудите WordPress да превключи към тема по подразбиране, която е налична в момента.

В сайтовете на Divi/Elementor/Avada това е полезно за изолиране на:

  • проблем с конструктора след актуализация
  • или детска тема с functions.php счупен.

Стъпка 4: Проверете за грешки от страна на браузъра

Отворете конзолата (F12) и вижте:

  • Грешки 403/404 на admin-ajax.php (често място за сигурност или скривалище).
  • Грешки в CORS (често конфигурация на CDN / сървър).
  • Неработещ JS, който пречи на администратора да завърши действие.

Стъпка 5: Проверете REST API, ако администраторският интерфейс „работи“

Съвременните актуализации и администриране разчитат на API заявки. Ако REST API е блокиран, може да се сблъскате с необичайно поведение.

Справка: Наръчник за REST API.

Стъпка 6: Използвайте проверката на състоянието в режим на отстраняване на неизправности

Плъгинът за проверка на състоянието ви позволява да деактивирате плъгините само за теб (Посетителите запазват „нормалната“ версия). Това е много практично, когато сайтът е в процес на разработка.

Стъпка 7: Преинсталирайте ядрото на WordPress (без да докосвате съдържанието)

Ако подозирате частично срутено ядро:

  • Изтеглете официалната версия от wordpress.org/изтегляне.
  • Качване отново wp-admin et wp-includes (и коренните PHP файлове), без да докосвате wp-content ni wp-config.php.

Това решава много „прекъснати актуализации на ядрото“, без да засяга съдържанието ви.

Често срещани капани и грешки

симптом Вероятна причина Препоръчително решение
Не мислиш ли така? .maintenance Скритите файлове не се показват Активирайте „Показване на скрити файлове“ във файловия мениджър или използвайте SFTP/SSH
Вие изтривате .maintenance но посланието остава Кеш на CDN/сървър/плъгини Изчистване на кешовете + тестване на частното сърфиране
След изтриване: грешка 500 Плъгинът е частично актуализиран / PHP фатален Проверете лог файловете, преименувайте дефектния плъгин и го инсталирайте отново чисто.
Поставихте откъс „за конфигуриране на поддръжката“ Код на грешното място / неподходяща кука Изтриване на фрагмента, връщане към изтриване на файла .maintenance
Променяте основните файлове Непостоянна корекция, риск за сигурността Никога не модифицирайте сърцевината; инсталирайте я отново чисто, ако е необходимо.
Актуализация, която винаги е неуспешна за един и същ плъгин Несъвместимост с PHP / недостатъчна памет / повреден плъгин Актуализирайте PHP, увеличете паметта, преинсталирайте плъгина, свържете се с разработчика
Неработещи постоянни връзки след връщане Правилата за пренаписване не са генерирани отново Настройки > Постоянни връзки > Запазване (без промени)

„Човешки“ грешки, които всъщност виждам:

  • Копиране на код в грешен файл (напр. в wp-config.php вместо functions.php), след което бял екран.
  • Забравяне на точка и запетая в откъс, който прекъсва администратора в най-неподходящия възможен момент.
  • Тестване в производство без резервно копие „Защото е просто актуализация.“ Това рядко е „просто“.
  • Следвайте стар урок (преди PHP 8), който съветва за рискови или остарели манипулации.

Вариант / алтернатива

Метод без код: използвайте хостинг услугата

Ако нямате FTP/SFTP:

  • Отворете файловия мениджър (cPanel/Plesk/home tool).
  • Показване на скрити файлове.
  • Изтрий .maintenance.

Това често е най-лесният метод за начинаещи.

По-напреднал метод: временен „сигурностен“ mu-плъгин за принудително излизане

Не бих препоръчал това като решение от първа линия, но е подходящо като временно решение на място, където .maintenance се появява отново и където е необходимо възвърне контрола За да диагностицирате, можете да добавите mu-плъгин („задължителен“ плъгин), който премахва .maintenance зареждане.

Предупреждение: Това е заобиколно решение. Ако действително се извършва актуализация, можете да създадете непоследователно състояние. Използвайте това временно, докато идентифицирате причината (cron/auto-update).

Къде да поставите кода : създаване на файла wp-content/mu-plugins/force-remove-maintenance.phpАко файлът mu-plugins Ако не съществува, създайте го.

Код ПРЕДИ (счупен: нищо не пречи на поддръжката да остане)

<?php
/* Aucun mu-plugin : WordPress reste bloqué si .maintenance persiste */

Код СЛЕД (коригирано: автоматично изтриване)

<?php
/**
 * Plugin Name: Force remove .maintenance (temporaire)
 * Description: Supprime le fichier .maintenance s'il est présent. À retirer après dépannage.
 * Author: Votre Nom
 */

/* Sécurité : empêcher l'accès direct */
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

add_action( 'plugins_loaded', function() {
	/* Chemin du fichier .maintenance à la racine WordPress */
	$maintenance_file = ABSPATH . '.maintenance';

	/* Si le fichier existe, on tente de le supprimer */
	if ( file_exists( $maintenance_file ) ) {
		/* @ est volontaire : on évite de casser le site si permissions insuffisantes */
		@unlink( $maintenance_file );
	}
}, 1 );

След като сайтът е достъпен, премахнете този mu-плъгин и коригирайте основната причина (цикличност на автоматичното актуализиране, разрешения, кеш и др.).

Избягвайте този проблем в бъдеще

Няма да можете да предотвратите всички инциденти, но можете драстично да намалите рисковете.

Конкретни добри практики

  • Избягвайте групови актуализации На крехък сайт. Направете ядрото, след това критичните плъгини (конструктор/сигурност) и накрая останалото.
  • Правете актуализации извън пиковите часове (по-малко трафик, по-малък риск от конкуриращи се процеси).
  • Поддържайте PHP актуален (препоръчва се 8.1+) и следете ограниченията (време за изпълнение, памет).
  • Използвайте среда за подготовка Ако имате Divi 5, Elementor или Avada: актуализация на конструктора може да прекъсне рендерирането.
  • Избягвайте неконтролирани плъгини за „снипти“ В производство. Повреден фрагмент в неподходящ момент може да доведе до неуспешна актуализация.

Малка предпазна мярка: проверете записа на диска

Ако често имате неуспешни актуализации, тествайте дали WordPress може да пише в wp-contentМожете да създадете мини тестов плъгин (който след това да бъде изтрит).

Къде да поставите кода създавам wp-content/plugins/test-ecriture/test-ecriture.phpАктивирайте го, след което го изтрийте след тестване.

<?php
/**
 * Plugin Name: Test d'écriture wp-content (temporaire)
 * Description: Ajoute une page d'admin qui teste l'écriture dans wp-content/uploads.
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

add_action( 'admin_menu', function() {
	add_management_page(
		'Test écriture',
		'Test écriture',
		'manage_options',
		'test-ecriture',
		function() {
			echo '<div class="wrap"><h2>Test écriture</h2>';

			$upload_dir = wp_upload_dir();
			$path       = trailingslashit( $upload_dir['basedir'] ) . 'test-ecriture.txt';
			$content    = "Test à " . gmdate( 'c' ) . "n";

			$result = @file_put_contents( $path, $content, FILE_APPEND );

			if ( false === $result ) {
				echo '<p><strong>Échec</strong> : impossible d’écrire dans uploads. Vérifiez permissions/propriétaire.</p>';
			} else {
				echo '<p><strong>OK</strong> : écriture réussie dans ' . esc_html( $path ) . '.</p>';
			}

			echo '</div>';
		}
	);
} );

Ако този тест се провали, вашите актуализации също ще се провалят рано или късно. Коригирайте разрешенията/собствеността с вашия доставчик на хостинг услуги.

ресурси

Често задавани въпроси

Опасен ли е файлът .maintenance?

Не, това не е зловреден софтуер. Това е нормален механизъм на WordPress. Проблемът е, когато той остане наличен дори след като актуализацията е приключила (или е неуспешна).

Не виждам .maintenance във FTP, това нормално ли е?

Да. Много инструменти скриват файлове, които започват с точка. Активирайте „Показване на скрити файлове“ (dotfiles).

Мога ли просто да чакам?

Понякога, да: WordPress често излиза от режим на поддръжка сам за по-малко от минута. Ако това продължи повече от 2-3 минути, обикновено е заседнал: изтриване .maintenance.

След изтриване получавам грешка 500. Какво означава това?

Често това се дължи на частична актуализация на плъгин/тема или на фатална PHP грешка. Проверете лог файловете (или активирайте WP_DEBUG_LOG), след което деактивирайте проблемния плъгин, като преименувате папката му.

Може ли Divi 5 / Elementor / Avada да причини това?

Те не задействат директно режим на поддръжка, но понякога актуализациите им могат да бъдат големи. При ограничен хостинг това увеличава риска от изтичане на времето за изчакване. След отстраняване на проблема може да се наложи изчистване на кеша и регенериране на ресурсите на конструктора.

Съобщението остава показано само на определени посетители.

Мирише на проблем с кеша (CDN, кеш на сървъра, кеш на браузъра). Изчистете кеша и тествайте от друго устройство/мрежа.

Трябва ли да променя wp-settings.php или основен файл?

Не. Никога не модифицирайте ядрото за това. Изтриване .maintenanceСлед това коригирайте причината (разрешения, плъгин, време за изчакване). Ако ядрото е повредено, качете отново. wp-admin et wp-includes от официалната версия.

Как мога да предотвратя самовъзникването на .maintenance?

Когато се появи отново, това означава, че е била рестартирана актуализация (автоматична актуализация, cron, инструмент за хостинг) или че постоянно се проваля. Коригирайте разрешенията, версията на PHP, използването на памет и актуализирайте всеки плъгин поотделно.

Мога ли да направя това от базата данни?

Не. Режимът на поддръжка, блокиран тук, е файл на диск. Базата данни може да отразява непълна актуализация, но изтриването ѝ .maintenance Това се прави на ниво файл.

Кой е най-надеждният тест, за да се потвърди, че е фиксирано?

Провери това .maintenance вече не съществува, заредете интерфейса в режим на частно сърфиране, след което отидете на /wp-admin/ > Актуализации и проверете дали няма актуализация, която да е „в процес на изпълнение“ или да не е успешна.

Статии

Коментирай

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани *

Този сайт използва Akismet за намаляване на спама. Научете как се обработват вашите коментарни данни.