Счупен WordPress? Пълно ръководство за справяне с бъгове и системни грешки
# wordpress
# Сайт поддръжка
Сайтът ви дава грешки, „бъгнат“ е или има проблеми с визуализацията? В тази статия ще разгледаме най-често срещаните проблеми при WordPress сайтовете, методите за диагностика и техните решения.
Как да дебъгваме под WordPress?
Преди да започнете с ремонтите, трябва да разберете източника на проблема. Ето основните начини да проверите за скрити грешки:
1. Конзола на браузъра (Console errors)
Това е първата стъпка при проблеми с дизайна или функционалността. Отворете конзолата в Chrome с бутон F12 или с десен бутон върху страницата -> Inspect.
Таб Console: Тук се изписват JavaScript грешки и софтуерни конфликти.
Таб Network: Тук е списъкът с файловете, които се зареждат. Ако виждате файлове в червено със статус (canceled) или 404, значи те не се зареждат правилно.
Съвет: Копирайте съобщението за грешка от Console в ChatGPT – това често ще ви даде правилна посока за решение.
2. Сървърни логове
Ако сайтът показва бял екран или грешка 500, проблемът е в сървъра.
Чрез плъгин: Използвайте Debug Log Viewer. Той чете записите от лог файловете и ги показва директно в таблото ви – идеално, ако не искате да влизате в хостинга си.
Ръчно (през FTP или cPanel): В главната директория на сайта потърсете файла error_log.
WordPress Debug режим: За по-подробна информация активирайте вградения дебъгър в wp-config.php със следния код:
Важно: Включвайте този режим само при нужда. Ако е активен постоянно, лог файлът може да нарасне значително и да запълни дисковото ви пространство. Ако това се случи, можете спокойно да изтриете debug.log – WordPress ще го създаде наново.
3. Вградени инструменти на WordPress
Състояние на сайта (Site Health): Намира се в Инструменти -> Състояние на сайта. Този инструмент прави автоматичен анализ на настройките, сървъра и ресурсите. Там ще откриете известия като „Кешът не е открит“ или „Обновяванията на заден план не работят“.
Плъгин Health Check & Troubleshooting: Този инструмент добавя режим Troubleshooting mode. Той ви позволява да изключвате плъгини и теми само за вашата сесия. Така можете да откриете виновника за проблема, без да прекъсвате работата на сайта за останалите потребители.
4. Статус страници на плъгини и теми
Много от популярните разширения имат собствени отчети за състоянието на системата. Проверете тук:
WooCommerce:Status (Статус)
Rank Math SEO:Status & Tools
Премиум теми (Avada, Elementor и др.): Потърсете таб System Status в настройките на темата.
1. Проблеми при обновяване на плъгин или тема
Ако опитвате да актуализирате компонент, но процесът е неуспешен, причините обикновено са една от следните:
Липса на активен лиценз: При платените (Premium) продукти обновяването става през сървъра на разработчика. Ако плъгинът е свален от неофициален източник ("пиратска" версия), той няма валиден ключ и връща грешка от типа: “Automatic update is unavailable for this plugin.”
Изтекъл лиценз: Повечето Premium лицензи включват поддръжка и обновявания за определен период (обикновено 1 година). След изтичането му трябва да подновите
абонамента си, за да получите достъп до новите версии.
Невъзможен автоматичен ъпдейт: При някои теми (например от ThemeForest) се налага ръчно обновяване. Трябва да изтеглите новия архив от маркетплейса и да качите файловете чрез файловия мениджър или FTP, замествайки старата папка. Винаги проверявайте документацията на темата.
Липса на дисково пространство: Ако хостингът ви е запълнен, WordPress няма къде да изтегли и разархивира новия пакет. Проверете квотата си в контролния панел на хостинга.
Неправилни файлови права: WordPress се нуждае от разрешения, за да променя файловете.
Папките трябва да са с права 755.
Файловете трябва да са с права 644. Проверете специфично папките /wp-content/plugins/ и /wp-content/themes/.
Сървърни ограничения (Timeout): Ако архивът е твърде голям или сървърът е бавен, връзката може да прекъсне преди завършване на процеса.
Общо решение (Ръчен ъпдейт): Ако автоматичното обновяване не работи, изтеглете новата версия на плъгина/темата от официалния източник. Влезте през FTP или File Manager, изтрийте старата папка на съответния компонент и качете новата.
Спокойно: Настройките ви няма да се изгубят, тъй като те се съхраняват в базата данни, а не във файловете на самия плъгин.
2. Бял екран (White Screen of Death - WSOD)
Това е една от най-честите "класики" в WordPress – потребителят вижда само напълно празна страница без никакви съобщения. Обикновено това се дължи на фатална PHP грешка или изчерпан лимит на паметта (memory_limit).
Как да го оправите?
Увеличаване на паметта (RAM): Проверете дали WordPress има достатъчно заделена памет. Често по подразбиране сървърът е настроен на 32MB или 64MB, което е крайно недостатъчно за модерни теми и плъгини.
Решение: Опитайте да увеличите лимита на 128MB или 256MB (за по-тежки сайтове дори повече). Това става чрез редактиране на файла wp-config.php или през контролния панел на хостинга.
Разкриване на скритата фатална грешка: Ако не е пуснат режимът за отстраняване на грешки (debug mode), сървърът просто спира работа и не показва нищо. За да разберете какво точно "чупи" сайта, трябва да активирате визуализацията на грешки.
Решение: В wp-config.php се уверете, че дебъг режимът е правилно конфигуриран:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true ); // Променете на true, за да видите грешката на екрана
Хостинг настройки: Понякога самият хостинг блокира показването на грешки заради сигурност. Потърсете в своя cPanel настройки като "Display Errors" или "Select PHP Version -> Options" и ги включете временно.
Съвет: Ако след включване на WP_DEBUG видите съобщение, което споменава конкретен плъгин (например в пътя към файла присъства /wp-content/plugins/ime-na-plugin/), просто преименувайте папката на този плъгин през FTP, за да го деактивирате и да върнете достъпа до сайта си.
3. Грешка при връзка с базата данни (Error Establishing a Database Connection)
Тази грешка означава, че вашият сайт не може да „говори“ с MySQL сървъра. Най-често се дължи на грешни данни за достъп или проблем със самия хостинг сървър.
Проверка на настройките: Отворете файла wp-config.php и се уверете, че следните редове съвпадат точно с данните, създадени в хостинг панела ви:
'DB_USER', 'потребител_на_базата' );
define( 'DB_PASSWORD', 'парола' );
define( 'DB_HOST', 'localhost' ); // Понякога хостингът изисква IP или друг хост
Претоварен сървър: Ако настройките са правилни, но грешката се появява само от време на време, вероятно базата данни е претоварена или сървърът е достигнал лимитите си. В такъв случай се свържете с поддръжката на вашия хостинг доставчик.
4. Вътрешна сървърна грешка (500 Internal Server Error)
Това е една от най-общите грешки. Тя казва, че сървърът е срещнал проблем, но не може да уточни какъв. Ако грешката е по целия сайт – проблемът е глобален; ако е само на определени страници – конфликтът е частичен.
Повреден .htaccess файл: Това е най-честият виновник.
Решение: Влезте през FTP или File Manager и преименувайте файла на нещо друго (напр. .htaccess_old). Ако сайтът тръгне, отидете в Настройки -> Постоянни връзки и натиснете „Запис“, за да генерирате нов, чист файл.
Конфликтен плъгин: Ако промяната на .htaccess не помогне, опитайте да преименувате папката plugins, за да деактивирате всички добавки наведнъж и да проверите дали сайтът ще се зареди.
5. Сайтът е „заседнал“ в режим на поддръжка
Това се случва, когато прекъснете обновяване на плъгин или тема по средата (например затворите таба или интернетът прекъсне). WordPress не успява да изтрие временния файл, който ограничава достъпа.
Симптом: Виждате надпис "Briefly unavailable for scheduled maintenance. Check back in a minute."
Решение: 1. Влезте в основната директория на сайта (public_html). 2. Намерете файла с име .maintenance. 3. Изтрийте го. Сайтът ви ще се върне към нормално състояние моментално.
6. Грешка "404 Not Found" на вътрешните страници
Често срещан проблем: началната страница се зарежда нормално, но при клик върху всяка друга страница или статия се появява грешка 404. Това обикновено е свързано с конфигурацията на постоянните връзки (Permalinks) или файла .htaccess.
Презаписване на постоянните връзки: Това е най-лесният фикс. Отидете на Настройки (Settings) -> Постоянни връзки (Permalinks) и просто натиснете бутона „Запис на промените“, без да променяте нищо. Това ще „рестартира“ правилата за пренасочване на сървъра.
Проверка на .htaccess файла: Ако презаписването не помогне, файлът .htaccess може да е повреден или с грешни права. Намерете го в главната директория (public_html) и го преименувайте временно на .htaccess_old. Ако сайтът тръгне, генерирайте нов чист файл чрез настройките на WordPress (както е описано по-горе).
7. Изчерпана памет (PHP Memory Limit Error)
Ако видите грешка от типа: "Allowed memory size of X bytes exhausted", това означава, че някоя тежка тема или плъгин (като Elementor или WooCommerce) изисква повече ресурс, отколкото сървърът позволява.
Как да увеличите memory_limit?
Вариант 1: Чрез wp-config.php (Препоръчително) Влезте във вашия File Manager или през FTP и отворете файла wp-config.php. Добавете този ред точно преди текста „/ That's all, stop editing! Happy publishing. /“:
define( 'WP_MEMORY_LIMIT', '256M' );
Вариант 2: През cPanel (MultiPHP INI Editor) Ако хостингът ви го позволява, това е най-лесният начин:
Влезте в cPanel.
Намерете „MultiPHP INI Editor“.
Изберете вашия домейн и променете стойността на memory_limit на 256M или 512M.
Чрез .htaccess файл Ако горните методи не работят, добавете този ред най-отгоре в своя .htaccess файл:
php_value memory_limit 256M
Важно ограничение: На споделен хостинг не можете да вдигнете лимита над това, което физически ви е заделил доставчикът. Винаги проверявайте дали промяната е сработила в Инструменти -> Състояние на сайта -> Информация -> Сървър -> PHP memory limit.
8. Грешки10. Проблеми с имейлите (WordPress Not Sending Emails)
Ако вашите форми за контакт (Contact Form 7, WPForms и др.) не изпращат съобщения, най-честата причина е, че стандартната PHP функция mail() е блокирана или ограничена от вашия хостинг доставчик с цел предотвратяване на спам.
Решение: Използвайте SMTP плъгин (например WP Mail SMTP). Този метод пренасочва имейлите през реална пощенска кутия (като Gmail, Outlook или професионален имейл към домейна), което гарантира, че съобщенията ще стигнат до получателя, а не в папката "Спам". при качване на изображения (HTTP Error)
Когато се опитвате да качите файл в Медийната библиотека и видите червено съобщение „HTTP Error“, причините обикновено са технически:
Проверете правата на папките: Влезте във файловата система и се уверете, че директорията /wp-content/uploads/ (както и нейните подпапки по години и месеци) е с права 755.
Лимит на паметта (Memory Limit): Процесът по преоразмеряване на снимки при качване изисква много RAM. Ако паметта е малко, процесът прекъсва. Вижте предходната точка за това как да увеличите WP_MEMORY_LIMIT.
PHP библиотеки за обработка: WordPress използва библиотеките GD или Imagick, за да обработва снимките.
Решение: Влезте в cPanel -> Select PHP Version -> Extensions и се уверете, че тези разширения са отметнати и активни.
Липса на дисково пространство: Уверете се, че не сте запълнили дисковата квота на хостинг плана си.
9. Грешка при качване на определен тип файлове
Ако видите съобщението: „Sorry, this file type is not permitted for security reasons“, това означава, че се опитвате да качите формат, който WordPress счита за потенциално опасен (например SVG, JSON или специфични шрифтове).
По подразбиране са разрешени само стандартни формати като JPEG, PNG, PDF и др. Ето как да добавите поддръжка за нови типове файлове:
Вариант 1: Чрез специализиран плъгин (Препоръчително) Инсталирайте плъгин като SVG Support или Safe SVG. Това е най-сигурният начин, тъй като тези плъгини „пречистват“ кода на файловете от зловредни скриптове.
Вариант 2: Чрез wp-config.php (За напреднали) Можете да премахнете всички ограничения за качване, но бъдете внимателни – това може да компрометира сигурността на сайта. Добавете този ред в wp-config.php:
define( 'ALLOW_UNFILTERED_UPLOADS', true );
10. Смесено съдържание (Mixed Content Error)
Сложили сте SSL сертификат (HTTPS), но катинарчето в браузъра е „счупено“ или липсва. Това се случва, когато сайтът е защитен, но някои изображения, скриптове или шрифтове все още се зареждат през старата http:// връзка.
Диагностика: Отворете конзолата в браузъра (F12) и потърсете съобщения в жълто или червено: "Mixed Content: The page at... was loaded over HTTPS, but requested an insecure script...".
Защо е опасно?
Сигурност: Позволява атаки тип „Man-in-the-Middle“.
SEO: Google санкционира сайтове, които не са напълно подсигурени.
Решение: Най-лесният начин е чрез плъгина Really Simple SSL. Той автоматично открива и пренасочва всички заявки към сигурната https връзка.
12. Проблеми с автоматичните обновявания (Update Failed)
Честа грешка при опит за ъпдейт е: „Destination folder already exists“. Тя се появява, когато предходен опит за инсталация или обновяване е прекъснал и е оставил папка със същото име в директорията на сайта.
Решение: 1. Влезте във вашия File Manager или през FTP. 2. Отидете в папка /wp-content/plugins/ (или /themes/). 3. Намерете папката на съответния плъгин/тема, която дава грешка, и я изтрийте ръчно. 4. Опитайте отново да инсталирате или обновите през административния панел на WordPress.
13. Заключен административен панел (Wp-admin Locked Out)
Когато собствената ви „крепост“ ви остави отвън, ситуацията изглежда безнадеждна, но в WordPress почти винаги има „заден вход“ през хостинг панела (cPanel) или FTP.
Сценарий А: Забравена парола (и имейлът не работи)
Ако бутонът „Изгубена парола?“ не изпраща имейл, трябва да действате директно в базата данни.
Решение: Влезте в phpMyAdmin -> таблица wp_users -> кликнете Edit на вашия потребител. В полето user_pass изберете функция MD5 от падащото меню и напишете новата си парола в чист текст в полето "Value". Запишете промените.
Сценарий Б: Блокиран IP адрес от плъгин за сигурност
Ако плъгин (Wordfence, iThemes) ви е „баннал“ заради грешни опити за вход:
Бърз фикс: Сменете интернет връзката си (например пуснете хотспот от телефона). Това ще ви даде ново IP.
Технически фикс: Влезте през FTP в /wp-content/plugins/ и преименувайте папката на плъгина (напр. от wordfence на wordfence_old). Това ще го деактивира принудително.
Сценарий В: Сайтът е хакнат
Ако виждате странни пренасочвания или бели екрани при вход:
Проверка: Проверете файла .htaccess в основната директория. Хакерите често добавят код там, който блокира достъпа до администрацията.
Решение: Възстановете чиста версия на .htaccess и сканирайте сайта с инструментите на хостинг доставчика.
14. Твърде много пренасочвания (Too Many Redirects)
Грешката ERR_TOO_MANY_REDIRECTS обикновено означава, че сайтът е влезе в безкраен цикъл („редирект лууп“).
Причина 1: Cloudflare конфликт: Най-често се случва при използване на настройка Flexible SSL в Cloudflare, без на вашия сървър да има инсталиран SSL сертификат. Сървърът се опитва да върне към HTTP, а Cloudflare форсира HTTPS.
Решение: Променете настройката в Cloudflare на Full или Full (Strict).
Причина 2: SEO плъгини: Конфликт в правилата за пренасочване (Redirects) в Rank Math или Yoast.
Диагностика: Използвайте онлайн инструмент като httpstatus.io, за да видите точно кои адреси се пренасочват един към друг.
15. Грешка "Sidebar Below Content"
Това е специфичен визуален дефект, при който страничната лента (sidebar) изпада под основното съдържание, вместо да стои до него. В 99% от случаите това не е сървърен проблем, а чист HTML или CSS бъг.
Незатворен <div> таг: Ако наскоро сте редактирали статия или файл на темата, може да сте забравили да затворите някой таг. Когато един </div> липсва, структурата на страницата се „счупва“ и браузърът избутва елементите надолу.
ширината на основното съдържание или на сайдбара и общият им сбор (плюс разстоянието между тях) надвишава 100% от контейнера, сайдбарът автоматично пада на долния ред.
Решение: Проверете последните промени в CSS или използвайте HTML валидатор, за да откриете липсващи тагове в кода на страницата.
16. Счупени бутони или менюта (JavaScript грешки)
Симптомите са следните: натискате бутона „Добави в количката“, главното меню на мобилен телефон или падащо меню, но нищо не се случва. Това обикновено се дължи на конфликт между различни jQuery библиотеки или JavaScript грешки.
Причина: Стари плъгини, които зареждат собствена (остаряла) версия на jQuery, която влиза в конфликт с версията на WordPress ядрото.
Диагностика: Отворете конзолата (F12 -> Console). Ако видите червени съобщения от типа "Uncaught TypeError" или "jQuery is not defined", значи имате скриптов конфликт.
Решение:
Обновяване: Уверете се, че темата и всички плъгини са актуализирани до последните си версии.
jQuery Manager: Използвайте плъгина jQuery Manager for WordPress. Той ви позволява да тествате сайта с различни версии на библиотеката, докато откриете тази, при която всичко работи.
Деактивиране: Изключвайте плъгините един по един, за да видите кой от тях причинява блокирането на скриптовете.
17. Грешки "Cloudflare 520 / 521 / 522"
Тези грешки са специфични за сайтове, които използват защитата на Cloudflare. Те показват, че Cloudflare не може да осъществи връзка с вашия хостинг сървър (Origin Server).
Грешка 520 (Unknown Error): Сървърът е върнал празен или неочакван отговор. Често се дължи на срив в PHP или претоварен уеб сървър.
Грешка 521 (Web Server Is Down): Вашият сървър е "паднал" или защитната му стена (Firewall) блокира заявките от IP адресите на Cloudflare.
Грешка 522 (Connection Timed Out): Cloudflare не е успял да се свърже със сървъра в рамките на определеното време.
Решение: Проверете статуса на хостинга си. Уверете се, че IP адресите на Cloudflare са в "белия списък" (whitelist) на сървъра и че вашият SSL сертификат е валиден и правилно конфигуриран.
18. Възстановяване на забравена парола
Ако сте изгубили достъп до административния панел, имате два основни начина да се върнете в сайта:
Вариант 1: Стандартният метод (чрез имейл)
Ако имейл сървърът на вашия хостинг работи коректно:
Отидете на страницата за вход (yourdomain.com/wp-login.php).
Кликнете върху линка "Изгубена парола?" (Lost your password?).
Въведете вашия имейл или потребителско име.
Проверете пощата си (включително папка Spam) за линк за нулиране.
Вариант 2: Чрез базата данни (phpMyAdmin) – Най-сигурен
Това е "златният стандарт" за възстановяване, ако имейлът не пристига. Почти всеки хостинг предлага phpMyAdmin в своя контролен панел (cPanel или DirectAdmin).
Влезте в phpMyAdmin и изберете базата данни на вашия сайт.
Намерете таблицата wp_users (префиксът wp_ може да е различен, например wpst_users).
Кликнете върху бутона Edit (Редактиране) до вашия потребител.
Намерете реда user_pass.
В колоната Function задължително изберете MD5 от падащото меню.
В колоната Value изтрийте стария криптиран текст и напишете новата си парола в чист текст.
Забележка: Функцията MD5 автоматично ще криптира паролата ви в момента, в който запишете промените, за да бъде тя защитена в базата данни.
Повечето проблеми в WordPress изглеждат плашещи, но в основата си са логични – конфликт между плъгини, липса на сървърен ресурс или неправилни права за достъп.
Най-добрата превенция е редовният бекъп (резервно копие). Винаги правете копие на сайта си преди обновяване на теми или плъгини, за да можете да го възстановите за минути, ако нещо се обърка.
