Случвало ли ви се е при работа с WordPress да се появи бял екран? Това е сравнително често срещана грешка, позната като “бял екран на смъртта” (от англ. White Screen of Death или WSOD). Трябва да знаете, че в по-голямата част от случаите виновникът не е WordPress. Какво да направите обаче, когато се появи на екрана пред вас WSOD? Обикновено следва обаждане към поддръжката на хостинга и връщане от архив. Ние решихме да ви покажем как и вие можете да направите това, което хостинг поддръжката ще извърши. В няколко стъпки и за 5 минути ще премахнете белия екран от вашия WordPress.

1. Защо WordPress показва бял екран?

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

Един от най- простите примери, който можем да дадем е аритметичната операция A+B*C/D. Как е възможно в тази формулка да възникне грешка? Напълно е възможно ако D е равно на нула. И ако горната формула е част от по-голяма такава, е невъзможно да се изчисли. Това е причината изпълнението да спира и резултатът да бъде неизвестен. На програмистки жаргон горният процес на спиране на изпълнението се нарича “ексепшън” (от англ. exception - изключение). Практически в модулите и темите на WordPress има ужасно много места, където това може да се случи. Всички автори на код прилагат много трикове, за да не се стигне до крайности - проверяват входните параметри, изискват специфични входни данни, блокират нелогични комбинации от действия на потребителя и още много други. Понякога обаче всичко това не сработва поради други причини - програмистки грешки, липсващи файлове, липсващи входни данни или други. И точно тогава WordPress не може да продължи изпълнението и показва знаменития “бял екран на смъртта”.

2. Кой вижда белия екран?

Белият екран има 3 подразновидности. Първата е, когато се среща само в административния панел, но потребителите могат да използват сайта. Втората е ,когато потребителите на сайта го виждат, а администрацията работи. Третата и може би най-често срещана е, когато нито потребителите виждат сайта, нито администрацията работи. От трите типа най-малкото зло е, когато администрацията не работи. Тогава потребителите и роботите обхождащи интернет не спират работа си. Най-лошо обаче е , когато нищо не работи. Тогава сайтът винаги връща грешка и на практика е неизползваем.

3. Как да отстраните белия екран?

Процесът е сравнително лесен и прост. Единственото, което ще ви трябва е FTP достъп до сайта и някакъв текстов редактор. Ако нямате достъп, файловият мениджър на хостинга ще може да ви свърши работа.
3.1. Отваряте уебсайта през FTP или през файловия мениджър. Отивате в папката, където е инсталиран WordPress
3.2. Отваряте файла wp-config.php
3.3. Добавяте 2 реда - най-отдолу:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );
3.4. Записвате промените. На този етап белият екран е деактивиран и можете да видите каква е грешката в сайта, както и какво я е предизвикало.
3.5. Отваряте мястото където сте видели белия екран - било то сайта или администрацията на  сайта. Сега WordPress ще ви стовари малко техническа информация. С особено внимание трябва да прочетете секцията “error”.
3.6. От горната техническа информация ще разберете кой модул или коя тема пречи на
нормалното функциониране на WordPress.
3.7. Проблемен модул

Ако се окаже, че проблемът е в модул - отивате с файловия мениджър в папката wp-content/plugins и преименувате папката на модула, като го направите различно. Можете да прибавите - (тире) отпред или _ (подчертано) отзад. Вариант е да допишете .notworked отзад.

3.8. Проблемна тема

Ако се окаже проблемна тема - отивате в папката wp-content/themes и извършвате преименуване на папката на самата тема.

3.9. Пак извършвате проверка като в точка 3.6. Ако сайта отново не работи и този път има други грешки ги отстранявате като в точки 3.7. и 3.8. Ако сайтът работи , продължавате напред.
3.10. Свързваме се със автора на темата или модула и ги уведомяваме за грешката, с която сме се сблъскали. Това най-често се прави във форумите за поддръжка на темата или модула в wordpress.org. Ако обаче добавките са платени - тогава се свържете с авторите им и ги уведомете за проблема.
3.11. Връщате се да редактирате wp-config.php и премахвате прибавените редове в
точка 3.

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

4. Какво следва след бързата корекция

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

5. Как да се предпазим от проблеми?

За съжаление колкото и да ни се иска няма такава възможност. От личен опит знаем, че това
най-често става по време на инсталиране на нови теми или плъгини, или по време на обновяването им с по-нови версии. Тъй като понякога нещата просто не се случват както искаме, единственния вариант за спасение са архивните копия. Дали архивните копия ще си ги правим ние, което е силно препоръчително, или архивите ще ги прави хостинг доставчикът ни, няма значение. Всъщност е хубаво двете неща просто да се случват паралелно. Понякога е по-бързо и удобно просто да се върне архивно копие на сайта, което е отпреди ден или два – затова е необходимо да се правят архиви. За тази цел се допитайте до поддръжката на хостинга ви кога, как и къде се правят и пазят архивите. В идеалния случай архивите ще са от вчера (максимум 24 часа), правят се всеки ден и се запазват на отдалечена машина. Ако имате и архив на възраст седмица, също е приемливо, ако нямате някакви големи промени междувременно.

6. Любопитно

Белият екран на смъртта има английски акроним WSOD и много наподобява сините екрани на Windows по-известни като BSOD.

Въпреки че изглежда сложно, горната операция отнема по-малко от 5 минути и дори начинаещите ще могат да я изпълнят. Ако не сте сигурни, че ще успеете, можете винаги да се свържете с поддръжката на вашия хостинг. Специалистите там ще ви върнат сайта от архива , където проблемът няма да съществува. Нашите специалисти разработиха специален WordPress хостинг план, който включва всекидневен отдалечен бекъп. По този начин ние се грижим да извършваме архивно копие на уебсайта ви всеки ден, за да бъдете спокойни в подобни неприятни ситуации.