Wp администратор бял екран. Какво да направите, ако получите бял екран в WordPress? Активирайте режима за отстраняване на грешки

Голям онлайн магазин, създаден на базата на WordPress и плъгина WooCommerce. Според клиента: „Работеше, работеше и днес започна да влиза в админ зоната и там нямаше нищо, накратко, не можа да влезе.“ Е, когато не влезе, това е истински проблем, но с админ панела не можах да устоя, забавно е да се троли. Не се замисляйте, не съм казал това на клиента и не ви съветвам да ги тролите, знайте, че по дефиниция те не разбират вашия и моя хумор. Като цяло, това е катастрофа, вместо удобно и красив панеладминистратор CMS WordPressс нас бял екрансмърт (не го измислих аз, така се нарича в интернет).

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

Е, вече познахте какво направих първо. Точно така, влязох в конфигурацията и включих режима за отстраняване на грешки. Това се прави просто, отиваме през FTP до корена или където файлът е скрит там wp-config.phpи го отворете за редактиране. Има специален ред, който задава необходимата константа за WordPress CMS, всъщност е достатъчно да я промените невярнона вярно. И сега режимът за отстраняване на грешки е включен.

Е, ако по някаква причина нямате такъв ред там, не се колебайте да го добавите сами. Можете също да добавите тези редове там:

Определете ("WP_DEBUG_DISPLAY", невярно); define("WP_DEBUG_LOG", true);

След това ще имате създаден файл debug.logв татко wp-съдържаниеи всички открити грешки ще бъдат записани там. Както може би се досещате, първият ред деактивира показването на грешки в браузъра, а вторият позволява запис на гореспоменатия лог файл с грешки.

Между другото, тези, които не знаеха, сега знаят, движещият сеWordPress е интелигентен двигател, той улеснява лекото скриване на вашия конфигурационен файл. По подразбиранеwp-конфиг.php се намира в корена, но може да бъде преместен на по-високо ниво, тоест напълно премахнат от публичната папка. Например коренът на вашия сайт има пътя<доменное имя сайта>/ public_html/. Вземете и прехвърлете файла отpublic_html към папка едно ниво по-високо, т.е<доменное имя сайта>. Следва хитрият ходWordPress ще направи всичко сам. Искам да кажа, че не намери файла в корена, той не беше много изненадан този фактще погледне към по-високо ниво, където няма публичен достъпот мрежата и ето, той ще намери там файла, който безопасно скрихме там.

Голяма информационна бележка под линия, добре, не можех да замълча, трябва да признаете, това е, полезна информация! Добре, нека продължим, тези действия не дадоха нищо, нямаше грешки, които да се видят, така да се каже, белият екран на смъртта на WordPress, не аз го кръстих така, така се наричаше в огромните простори на интернет, той беше непоклатим и все още символизира фразата " Целият живот е разложение".

Е, аз съм весел или... човек, така е, реших да вляза, от друга страна, за да разгледам регистрационните файлове за грешки през хостинга. Да, да, хостингът има такава функция. Всъщност включих записването на всички грешки, опресних белия екран няколко пъти и отидох да видя какво интересно пише в логовете. Представете си изненадата ми, че и там беше празно, тоест наистина, напълно празно, както се казва, нито една муха не седеше.

Но когато направим нещо лошо, не можем да бъдем спрени, най-важното е да не ядем бисквитката накрая, иначе на сутринта ще бъде лошо.

Практика за премахване на белия екран на WordPress

Нормалните методи не помогнаха, преминах към ненормални. Е, просто взех и добавих номер 1 в името на папката с плъгини, намираща се в папката wp-content. Защо е така, добре, не сте забравили, опитваме се да влезем в администраторския панел. Е, можете да деактивирате всички добавки наведнъж по три начина, през админ панела, този, който използвах аз (по-бързо и лесно е) и третия чрез phpMyAdmin.

Няколко думи за третия метод, да, да, отново не мога да устоя и трябва да ви кажа. Но това е за вас! Няма значение, че не го използвате, но ще знаете. Да отидем в базата данни (о, да, това е, брато, същата база данни, с която не искахте да се занимавате и която винаги ви плашеше с три букви SQL) и там, в раздела SQL заявки, въведете следното линия:

АКТУАЛИЗИРАНЕ wp_options SET option_value = "" WHERE option_name = "active_plugins";

Или отидете на масата wp_опциявиж там в колоната име_на_опция, низ активни_плъгини. И сега в този ред изтриваме съдържанието на клетката option_value. Препоръчвам ви да направите това ръчно, без да използвате SQL заявка, там ще ви се разкрият големите тайни на JSON, а именно в него хитрият WordPress съхранява данни в гореспоменатата клетка на своята база данни. Просто от любопитство да погледнете, ако не искате, използвайте SQL заявка.

Като цяло деактивирах плъгините и нищо, пак бял екран, а и сайта спря да работи. Да, да, това се случва, когато внезапно изключите всички добавки наведнъж. Но, както си спомняте, използвах втория метод и чрез някаква проста манипулация стартирах отново всички добавки. И о, чудо, сайта пак заработи, но не и админ панела, тоест стигнахме до там откъдето тръгнахме. Белият екран и неговото сакраментално „Целият живот е тление“. Но, както си спомняте, аз съм весел или... човек. Реших да не ровя повече; мога внимателно да добавя малко код към файла admin.php и пак да намеря инфекцията, която причинява белия екран. И аз бих направил това, но клиентът съобщи, че след прехвърлянето на сайта се появява бял екран нов хостинг, където работеше безопасно и всичко работеше докато антивирусната беше на хостинга (между другото беше beget , но там я имат безплатна антивирусна програма). Е, клиентът естествено се съгласи и кодът беше изтрит. Но проблемът с всички антивируси е, че те не само премахват зловреден код, но те също така свързват код, който е необходим, но е развален от вградения код.

На светло нова информация, спрях да танцувам с тамбура и да пея шамански песни, а след това започнаха да ме гледат накриво и да хвърлят подозрителни погледи към телефона. И реших да използвам, образно казано, тояга, добре, това е оригиналният руски начин за ремонт на фина електроника. А именно, преинсталирайте двигателя на WordPress, но не прост и достъпен, но ръчно, да, въпреки че използваме клуб, клиентът няма да е доволен, ако ние " Да умрем и целият свят ще се превърне в прах„(c) DMB.

Между другото, приятелю, надявам се, че вече си бил на етапа между приемането на поръчка от клиент и започването на ровене във файловете на сайта, като си направиш труда да направиш РЕЗЕРВНО копие на файловете на сайта и неговата база данни, или, добре, принуждавайки клиента да го направи. Ако не, добре, не искам да казвам лоши думи, просто го направете сега! И в бъдеще, независимо какво правите с уебсайта на клиента, винаги първо правете резервно копие. Променяте кода във файла, запазвате оригиналния файл, просто го преименувате, добавяте префикса _старо или нещо друго, това трябва да е на ниво неосъзнат рефлекс.

Но да се върнем на нашите ръчна актуализация WordPress. Това е всичко, просто отидете тук. Уебсайт на WordPress и изтеглете комплекта за разпространение, нашата машина. Разопаковайте получения архив на вашия компютър. След това отворете от FTP файловенашия сайт (използвам WinSCP, преди това използвах FileZilla) и там изтриваме две директории: wp-администраторИ wp-включва. Ние не докосваме останалото, помнете, нашата задача не е да покажем колко сме готини, а да направим това, което клиентът иска, той винаги е прав, така да се каже. И тогава копираме всичко от разопакованата дистрибуция, като се съгласяваме да заменим всичко, което иска да промени там, повярвайте ми, той знае какво и къде да промени, така че нека го промени. Остава само да отидете в админ панела и да проверите дали всичко е там. Да, така или иначе админ панелът ще работи след такова безобразие, което ние с теб направихме. Целта е постигната, късмет и просперитет!

На WordPress бял екран– доста рядка и неприятна ситуация, която може да разстрои почти всеки уеб администратор. Най-често се появява след CMS актуализации, инсталиране на нов или актуализиране на стар плъгин, промяна на шаблон или актуализиране на активна тема.

Бял екран може да се показва само в предната част на сайта (тази, която е видима за потребителите), или може би дори по-лошо - дори при влизане в конзолата.

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

ПРЕДУПРЕЖДЕНИЕ: Преди да действате, направете пълно архивиранефайлове и база данни на сайта.

Основните причини за белия екран на смъртта в WordPress са:

Като правило, основните причини подобни неизправности WordPress съдържа плъгини, чиито разработчици не са тествали напълно тяхната функционалност. Също така е много вероятно, че инсталирани добавкиможе да са в конфликт помежду си, в резултат на което се появява празна страница.

Следователно трябва да разберете кой плъгин е основната причина за проблема.

Имам достъп до конзолата

  1. Отидете в секцията Plugins → Installed.
  2. Проверете всички добавки и изберете „Деактивиране“ в полето „Действия“.
  3. Отидете на сайта и проверете работата му.
  4. Ако това не реши проблема, тогава причината е в нещо друго и трябва да преминете към следващия метод.
  5. Ако сайтът работи, трябва да започнете да активирате плъгините един по един и след всяко активиране да проверявате функционалността на сайта.
  6. В резултат на това ще попаднете на плъгин, след чието активиране ще се появи бял екран. Тук има две възможности: премахнете го и намерете алтернатива, изчакайте актуализацията (но не е факт, че грешката ще бъде коригирана след актуализацията) или се свържете с разработчиците на плъгини.

Може също да е конфликт между два различни приставки. За да проверите тази версия, трябва да деактивирате отново всички плъгини и да активирате първо проблемния плъгин, който намерите. Ако сайтът работи след активирането му, тогава има голяма вероятност от спор между добавките. Същият метод на последователно активиране ще помогне да се определи вторият от тях (при условие, че първият е намерен и вече е активиран).

  1. Трябва да преминете през вашия хостинг панел до файловия мениджър на вашия сайт или да се свържете с него чрез .
  2. Отидете в папката wp-content и преименувайте директорията с добавки с друго име, например plugins2.
  3. След това всички добавки се деактивират, тъй като системата ще търси файлове с добавки в папката „plugins“, а не в „plugins2“.
  4. Проверете сайта.
  5. Ако нищо не се е променило, преименувайте папката обратно и преминете към следващата стъпка.
  6. Ако тези стъпки помогнаха, първо опитайте да върнете името на директорията и проверете отново. Отново нищо не работи - опитайте да преименувате за всяка папка с добавки, тоест папка в директорията "plugins".

PHP няма памет

Често проблемът е недостигът PHP памете резултат от работата на някакъв фрагмент от код на заявка, алгоритъм или процедура. Тоест, това предполага, че php скрипттрябва да използва повече памет, отколкото е позволено.

Този проблем се коригира естествено чрез увеличаване на тази граница.

Нов лимит чрез wp-config.php

  1. Отворете този файл чрез редактор на код (или текстов редактор) и добавете нов ред с кода: define("WP_MEMORY_LIMIT", "64M");

    Трябва да вмъкнете кода след първия ред на съдържанието

  2. Запазете промените си и проверете сайта. Ако всичко работи - поздравления, ако не - търсим проблема по-нататък.

Нов лимит чрез .htaccess

  1. С помощта на файловия мениджър в хостинг панела (или като се свържете със сървъра чрез ), отидете в главната директория на сайта и потърсете там файла .htaccess. Ако липсва, създайте го.
  2. След това го отворете чрез произволен текстов редактор и добавете следния ред php_value memory_limit 64M
  3. Опитваме се да влезем в сайта. Ако все още няма нищо фатално, преминаваме към следващата стъпка.

Нов лимит чрез php.ini

  1. Ако вашият хостинг доставчик е предоставил достъп до файла php.ini, отворете го и добавете реда memory_limit = 64M;

    Ако нямате достъп до файла, можете да го създадете сами и да го поставите в главната директория на вашия WordPress сайт.

  2. Проверяваме работата на сайта. Ако отново нищо не се е променило, тогава вземаме предвид следващата стъпка.

Може да се наложи да се свържете с техническата поддръжка на вашия хостинг доставчик, за да поискате увеличение на лимита.

Грешки в активната тема

Имам достъп до конзолата

  1. Отидете на конзолата на сайта, отидете на раздела Облик → Теми.
  2. Направете всяка стандартна тема активна. Ако сте ги изтрили преди, изтеглете разпространението на WordPress и инсталирайте стандартен шаблон.
  3. Обновете страницата на сайта. Някакви промени? не? Нервите ви вероятно вече са изтощени, но това е добре, опитайте се да разрешите проблема по-нататък.

Нямам достъп до конзолата

Грешки и бъгове в кода

  1. Отидете до файловия мениджър през хостинг панела (или се свържете със сървъра чрез ), отидете в основната директория на сайта и намерете файла wp-config.php там.
  2. Намерете реда define("WP_DEBUG", false);

    и заменете със следното

    Define("WP_DEBUG", true);

  3. Ако не сте намерили такъв ред във файла, можете да го добавите сами. Просто поставете този ред define("WP_DEBUG", true);

    и запазете промените.

  4. След като се опитате да влезете в сайта, ще видите информация, която изглежда ще ви помогне да разрешите проблема с белия екран.

Заключение

Ето колко дълъг и досаден се оказа процесът на решаване на проблема и ще се радвам за вас, ако наистина помогна за решаването на проблема и не ви накара да загубите толкова много време от скука.

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

Всеки, който не е виждал белия екран на смъртта на WordPress, не е работил с WordPress! В тази статия ще опиша решение на една от причините за появата на бял екран, тоест явлението, когато вместо съдържанието на вашия сайт в прозореца на браузъра виждате празен бял екран.

Къде да търсите причините за белия екран на WordPress

В повечето случаи белият екран не се появява сам, а когато сте направили промени в сайта. Например инсталирахме нова тема. Би било логично незабавно да отмените направените промени. Тоест, ако сте инсталирали и активирали нова тема на WordPress, тогава трябва да активирате предишната, която е била активирана по-рано, например вградената по подразбиране от създателите на WordPress Twenty Fifteen, Twenty Fourteen. Но проблемът е, че като правило, когато се появи „бял ​​екран“, вие също губите достъп до контролния панел на WordPress. И следователно, използвайки административния панел, вече няма да можете да отмените направените промени.

Подмяна на активната тема без достъп до WordPress конзолата

Първо, запомнете какви теми имате налични в WordPress. Друга възможност е да се свържете със сървъра чрез SSH или FTP и да проверите дали стандартните теми на WordPress са качени на сървъра. Нека ви напомня, че темите в WordPress се съхраняват в директория wp-съдържание/теми/

Отидете на PhpMyAdminи отидете на масата wp_options. Превъртете през страниците с опции, докато го намерите. шаблонИ таблица със стилове. Трябва да замените техните стойности с името на директорията с теми, която искате да активирате. например, двадесет и петнадесеткато снимката по-долу:

Обновете началната страница на сайта във вашия браузър. Всичко трябва да работи, включително достъп до администраторския панел.

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

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

Бял екран вместо уебсайт - какво да правя?

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

Какво да проверите, когато в WordPress се появи бял екран на смъртта

  1. Първото нещо, на което трябва да обърнете внимание, са вашите скорошни действия. Инсталирали сте или сте актуализирали плъгин или тема. Или са добавили нов запис към файла с грешка.
  2. Лесно е да проверите дали приставката е повредена. Достатъчно е да преименувате папката с плъгини на сървъра и да опитате отново да влезете в админ зоната. Изобщо не е необходимо да ги премахвате. Ако проблемът не е разрешен, значи това не е проблемът. Върнете оригиналното име на папката.
  3. Ако сте добавили файл, например, към дъщерна тема, файла functions.php, тогава проверете правилността на записа и кодирането на файла. Само една отметка може да изведе бяло изображение вместо уебсайт.
  1. Може също да е просто кеш. Чисто
  2. Друга причина: хостерът отделя малко памет за PHP и скриптовете нямат достатъчно за изпълнение. В този случай променете или тарифния план, или преместете на друг хостинг. Можете също така да напишете, ако имате право, във файла .htaccess php_value memory_limit 64M Но е по-добре да се свържете с поддръжката на хостинг компанията с молба за увеличаване на PHP паметта.

Този брой обикновено е достатъчен, за да работят скриптовете.

Разрешаване на регистриране в WordPress

За да улесните проследяването на всеки проблем, по време на разработката активирайте журнала на WordPress, който се съхранява в папката /wp-content/debug.log

IN wp-config.phpдобави:

От моя опит: бял екран след извършване на промени във файла .htaccess

Правенето на нови записи във файла htaccess е обичайно нещо. Но по някакъв начин получих странен проблем. Добавих редове, които вече бяха тествани на други сайтове и получих бял екран за потребителите (администраторът можеше да влезе в админ панела и да работи там). Отмених тези промени, върнах предишния .htaccess, но проблемът не изчезна. И най-интересното е, че никакви разрешения за показване на грешки на екрана не работят. Чист бял и празен лист!

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

Това е толкова неразбираема история. И най-интересното е, че все още трябва да добавя редове към .htaccess. Но някак си е страшно да се повтори ситуацията.)

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

Най-често това се случва, когато се правят промени в кода на сайта и можете да познаете причините за проблема или да се върнете към предишния код, но се случва сайтът да спре да работи без видима причина. Понякога този проблем възниква при влизане в администраторския акаунт. панел на сайта след обновяване на темата, при преместване на сайта на друг хостинг и др. Имаше дори такъв леко хумористичен израз: „WordPress Бял екран на смъртта“.

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

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

Активирайте отстраняването на грешки

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

1. Намерете следния ред във файла wp-config.php (намиращ се в основната директория на вашия сайт):

define("WP_DEBUG", false);

Превключването на константата WP_DEBUG в режим „отстраняване на грешки“ (true) води до показване на грешки и предупреждения, които възникват по време на изпълнение на кода.

2. На практика обаче описаната по-горе техника не винаги води до появата на необходимата информация на екрана - той все още остава напълно бял.

В този случай е полезно да добавите ред като този към файла .htaccess (намиращ се в основната директория на вашия сайт):

php_value display_errors 1

php_value display_errors1

Тази инструкция води до показване на php грешки и в комбинация с първата точка трябва да помогне.

След като откриете грешката и я поправите, трябва да деактивирате режима за отстраняване на грешки, тоест да върнете кода във файловете към оригиналния.

Деактивиране на добавки

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

Ако имате достъп до административния панел на сайта, можете да деактивирате добавките точно там. Ако няма такъв достъп, свържете се към сайта чрез FTP и преименувайте папката с добавки (wp-content/plugins), например на plugins1. След това плъгините ще спрат да работят и трябва да проверите функционалността на сайта без тях.

Смяна на темата

Ако грешката е в работната тема, трябва да я променим. Отново, ако имате достъп до административната област на сайта, просто влезте и променете темата, като използвате стандартни методи.

Ако няма достъп, тогава ще трябва да промените темата директно в базата данни. За да направите това, влезте в phpMyAdmin (в контролния панел на хостинга), намерете таблицата с опции там. В тази таблица трябва да намерите 2 записа (параметъра): шаблон и таблица със стилове. Техните стойности трябва да съответстват на работната тема. Променете стойностите на имената на темите, включени в WP, например двадесет и четиринадесет (тази тема трябва да е на сайта).