По-малко е повече: разчистване и разрешаване на конфликти

Модул 5: Теми и разширения · Време за четене: 9 минути

Учебна цел: След този урок ще можете да разчиствате разширения и сами да откривате и решавате конфликт или бяла страница.

Ключови понятия: изключване срещу изтриване, неактивен код, критична грешка, режим на възстановяване (recovery mode), Състояние на сайта, режим за отстраняване на проблеми, преименуване на папка с разширение, WP_DEBUG, WP_DEBUG_LOG, debug.log, лог на грешките

Изключването не е изхвърляне

В Разширения можете да изключите или да изтриете разширение. Разликата:

• Изключване: WordPress вече не зарежда разширението. Но файловете остават в wp-content/plugins/ и често все още могат да бъдат заявени директно през уеб сървъра. Ако в отделен PHP файл на това разширение има уязвимост, тя продължава да съществува. Нападателите сканират за известни уязвими файлове, не за активни разширения.
• Изтриване: файловете изчезват. Някои разширения при изтриване разчистват и своите настройки и таблици в базата данни; други ги оставят.

Ако вече не използвате дадено разширение, изтрийте го. Изключването е само временно (докато търсите даден проблем). Същото важи и за темите (урок 2.4).

Разчистване: редовна проверка

Преглеждайте разширенията си веднъж на тримесечие (урок 9.4). За всяко разширение проверете:

1. За какво служи? Ако не помните, разберете. Често се оказва, че разширение е било инсталирано веднъж за едно нещо и никога не е премахнато.
2. Все още ли се използва? Разширение за слайдер, докато никъде няма слайдер; разширение за формуляр, докато страницата Ви за контакт използва друг формуляр.
3. Може ли без него? Може ли WordPress, темата или друго разширение да го замести (урок 5.3)?
4. Все още ли се поддържа? Кога е последната актуализация, все още ли е в хранилището с разширения?

Направете разчистването първо в тестова среда (staging) (урок 8.3) или поне направете резервно копие, и изтривайте по едно разширение наведнъж, за да знаете какво се е объркало, ако нещо се обърка. Внимавайте с кратките кодове (shortcodes): ако изтриете разширение, което е предоставяло [formulier id="2"], този текст след това ще остане буквално на страницата Ви.

Когато нещо се обърка: критичната грешка

След актуализация, ново разширение или ъпгрейд на PHP изведнъж виждате:

Има фатална грешка на този уебсайт.

или напълно бяла страница. Това означава, че PHP е спрял с фатална грешка преди да е била генерирана страница (урок 1.2). Обикновено причината е разширение или тема, които не работят добре с нещо друго: друго разширение, новата версия на WordPress или версията на PHP.

От WordPress 5.2 насам WordPress прави две неща:

• изпраща имейл до адреса на администратора с информация кое разширение или тема е предизвикало грешката, и специална връзка;
• чрез тази връзка влизате в режим на възстановяване (recovery mode): администрацията тогава работи, като разширението, причинило грешката, е временно изключено, за да можете да го актуализирате, замените или изтриете.

Затова адресът на администратор, който наистина четете, е толкова важен (урок 2.2).

Самостоятелно търсене: стъпките

Не получавате имейл или режимът на възстановяване не работи? Ето как да го откриете сами.

1. Проверете лога на грешките

Грешката почти винаги се намира в лога на грешките на уеб сървъра или на PHP. В DirectAdmin го намирате в логовете на Вашия домейн. Търсите ред с PHP Fatal error и часа на опита си:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /home/gebruiker/domains/example.com/public_html/wp-content/plugins/oude-slider/slider.php:42

Пътят показва кой е виновникът: тук разширението в папката oude-slider. Останалата част от реда показва защо (тук: функция, която е премахната в PHP 8, урок 8.4).

2. Включете debug лога (не съобщението на екрана)

Ако в лога на грешките няма нищо полезно, задайте в wp-config.php (над „stop met bewerken“):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WordPress тогава записва всички грешки в wp-content/debug.log, без да ги показва на посетителите. Никога не оставяйте това включено по-дълго от необходимото: debug.log се намира в папка, която уеб сървърът предоставя, и който знае адреса, може да го прочете. В него се съдържат пътища, понякога потребителски имена и друга информация, която помага на нападател. Изключете го отново след търсенето и изтрийте debug.log. Или оставете WordPress да записва лог файла извън уеб папката, като зададете път при WP_DEBUG_LOG (например '/home/gebruiker/logs/wp-debug.log', ако Вашият хостинг доставчик позволява това). В урок 7.4 проверявате дали debug.log не е публично достъпен.

3. Изключване на разширение без администрация

Ако не можете да влезете в администрацията, изключете подозираното разширение, като преименувате папката му през File Manager или SFTP:

wp-content/plugins/oude-slider   wordt   wp-content/plugins/oude-slider-uit

WordPress тогава вече не намира разширението и го изключва. Ако не знаете кое точно е, преименувайте цялата папка plugins на plugins-uit: всички разширения се изключват. Ако сайтът тогава работи, създайте нова празна папка plugins, връщайте разширенията едно по едно и проверявайте след всяко дали грешката се връща. За тема важи същото: преименувайте папката на активната тема и WordPress автоматично преминава към стандартна тема, ако такава все още е налична (урок 2.4).

4. Конфликти без фатална грешка

Не всеки проблем е критична грешка. Понякога не работи само една функция: бутон не прави нищо, формулярът не се изпраща, редакторът се зарежда наполовина. Тогава често причината е конфликт между две разширения или между разширение и темата. За това е полезно официалното разширение Health Check & Troubleshooting: в режима за отстраняване на проблеми то изключва всички разширения само за Вашата сесия и превключва към стандартна тема, докато посетителите продължават да виждат обичайния сайт. След това ги включвате едно по едно, докато проблемът се върне.

Погледнете също в конзолата на браузъра си (F12): грешките в JavaScript често посочват файла, а с него и разширението.

Състояние на сайта

В Инструменти > Състояние на сайта WordPress сам проверява Вашия сайт: остаряла версия на PHP, разширения и теми, които не са активни, липсващи PHP разширения, REST API, който не работи, планирани задачи, които изостават. В раздела Информация са изброени всички данни за Вашата инсталация (версии, пътища, PHP настройки). Този раздел можете да копирате и изпратите, когато поискате помощ. Проверявайте тук след всяка голяма промяна.

Обобщение

• Изключването оставя файловете на място; изтривайте разширенията и темите, които не използвате.
• Разчиствайте всяко тримесечие, по едно разширение наведнъж, с резервно копие или в тестова среда.
• При критична грешка WordPress изпраща имейл с връзка към режима на възстановяване.
• Логът на грешките или debug.log сочи пътя на виновника; изключете отново debug след търсенето, защото иначе debug.log е публично достъпен.
• Без администрация изключвате разширение, като преименувате папката му; конфликтите откривате чрез режима за отстраняване на проблеми.

Тест

Задача

Задача A5.4: Вашият debug log публично достъпен ли е? Въведете адреса на Вашия сайт и докажете с кода, предоставен от задачата, че сайтът е Ваш (TXT запис или малък файл). Програмата заявява /wp-content/debug.log: добре е, ако файлът не съществува или достъпът е отказан (404 или 403). Ако програмата получи файл обратно, това е отбелязано в червено. Освен това програмата преброява колко различни папки с разширения се срещат в HTML кода на Вашата начална страница (само за информация).

Задача D5.4: Подреждане на списъка Ви с разширения. Съставете списък на всички Ваши разширения (активни и неактивни): име, за какво служи, все още ли е необходимо (да/не), алтернатива без разширение. Изтрийте (след резервно копие или в тестова среда) разширенията, които вече не са необходими, по едно наведнъж, и проверявайте след всяко изтриване дали сайтът все още работи. Попълнете колко разширения сте имали и колко са останали, и отбележете дали са останали кратки кодове, които сте трябвало да разчистите.

Допълнително четене

Тези статии описват стъпките в панелите на WebOké; в други панели те работят по подобен начин.

• Ръководство за DirectAdmin 18.1: Моят сайт е бял или показва грешка 500
• Грешка 500 или „критична грешка“ на Вашия уебсайт (включително след актуализация на WordPress)
• Ръководство за DirectAdmin 14.6: Fouten след ъпгрейд на PHP и намиране на лога с грешки
• Ръководство за DirectAdmin 17.2: Site summary & logs: лог файлът за грешки и лог файлът за достъп
• Как да отстранявам грешки в PHP, без да променям php.ini?
• Дебъгване в WordPress (developer.wordpress.org, на английски): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/