Окончательное руководство по решению 500 внутренних ошибок сервера и пустых белых страниц в WordPress

Внутренняя ошибка сервера 500 — самая бесполезная и неописуемая проклятие веб-разработчиков во всем мире. Это универсальное сообщение об ошибке, которое может буквально означать что угодно. Иногда ваш сайт WordPress не дает никаких ошибок и просто показывает пустую страницу. Как, черт возьми, вы должны выяснить, что не так?

Это случается с лучшими из нас, но не нужно паниковать. Вот мой собственный процесс отладки, в порядке вероятности и с решениями.

Плагины

Если вы только что установили новый плагин или если ваш сайт показывает 500 ошибок после обновления ядра WordPress, наиболее вероятной причиной является несовместимый плагин. Есть много причин для того, чтобы плагин был «сломан»:

• WordPress, возможно, удалил некоторые основные функции, которые использует плагин.
• Возможно, плагин был написан для старой версии PHP и не обновлялся.
• Это может быть просто неправильно закодировано, например, путем ссылки на имена баз данных по умолчанию, а не с помощью префиксов.

Идентифицировать плагин легко, если вы только что установили его и появилась ошибка, но как отключить плагин, если он был удален? WP-администратора площадь вашего сайта тоже? Короткий ответ, вам нужен FTP-доступ, хотя веб-менеджер файлов из CPanel или Plesk также будет работать нормально.

Решение:

Все, что вам нужно сделать, это переименовать WP-содержание / плагины / папка. Поместите _ перед папкой плагинов, поэтому она называется _plugins, и теперь вы сможете снова войти в вашу админ-панель WordPress. Переименовывая папку, вы фактически деактивируете каждый плагин — вы должны получить кучу сообщений об ошибках от WordPress, говорящих «Плагин X был деактивирован, потому что файл Y.php не может быть найден». Не волнуйтесь, вы не потеряете никаких настроек — они хранятся в базе данных, и любой приличный плагин должен найти их снова после повторной активации.

Снова переименуйте папку, удаление _. Обновите плагины WordPress, и они все снова будут перечислены, но в деактивированном состоянии. Теперь вы можете повторно активировать их один за другим, пока не найдете виновника; затем сделайте все это снова, очевидно, оставив плохой плагин на этот раз.

К сожалению, когда это происходит, есть вероятность, что есть лучший плагин, который совместим. Найди это.

Несовместимая тема

Отключение плагинов не помогло? Это, вероятно, что-то в вашей теме. Как и плагины, вы можете заставить активную тему прерываться, просто переименовав ее. Вернитесь в область администрирования WordPress (если вы можете, конечно, если вы не можете, это, вероятно, не имеет ничего общего с вашей темой), и WordPress предупредит вас, что она вернулась к теме по умолчанию. Проверьте сайт еще раз. Конечно, это не очень помогает, если вы привержены определенной теме, поэтому, возможно, захотите снова включить ее и перейти к разделу «Включение отладки PHP»; или просто найдите новую совместимую тему.

Bad .htaccess

Если деактивация ваших плагинов ничего не дала и это тоже не ваша тема, возможно, ваш .Htaccess файл каким-то образом поврежден. Обычно, когда это происходит, вы все равно можете получить доступ к административной части сайта. .Htaccess Файл обрабатывает правила перезаписи и настройки кэша, но иногда вы будете редактировать этот файл напрямую, чтобы вручную кодировать такие вещи, как перенаправления 301.

Решение:

Переименовать .Htaccess файл в корне вашей установочной папки WordPress в нечто вроде .htaccess_old. Если вы не видите файл там, вам нужно включить просмотр скрытых файлов — точный способ сделать это будет зависеть от вашего FTP-клиента. «.» В начале имени файла означает «скрыть это» в Linux и других UNIX-подобных системах.

Переименовав текущий .htaccess, вернитесь в область администрирования WordPress и перейдите в настройки -> Permalinks и, не внося никаких изменений, нажмите сохранить. Это автоматически создаст новую рабочую версию файла, хотя любые изменения, сделанные вами вручную, будут потеряны.

Включить отладку PHP

Мы можем включить журнал отладки из конфигурации WordPress, который может дать подсказку о точной проблеме — но на этом этапе вы по своему усмотрению. Вам нужно выяснить, как это исправить, что потребует навыков кодирования.

Чтобы включить журнал отладки, откройте wp-config.php в корне вашей установки WordPress. Найдите строку, которая говорит:

define('WP_DEBUG', false);

Закомментируйте это, используя // в начале, затем вставьте следующее:

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

Это начнет выводить ошибки в файл в папке wp-content с именем error.log. Если вы обновляете свой FTP и через минуту или около того ничего не видите, возможно, у него нет разрешения на создание файла. Вручную создайте новый файл error.log и дайте ему разрешение 666.

Имейте в виду: этот файл будет увеличиваться до тех пор, пока вы не удалите эти строки из вашей конфигурации. Не забудьте также раскомментировать оригинальную строку. Прочитайте файл в любом текстовом редакторе и проверьте наличие критических ошибок PHP. В этом примере я вижу множество PHP-уведомлений об устаревшем коде, но на самом деле они не сломают сайт.

Конфигурация сервера

Недавно у меня был случай, когда примерно половина всех загрузок страниц достигала 500, но без установленного шаблона и абсолютно ничего полезного в журналах ошибок. Активация журналов отладки WordPress не показала ничего очевидного — множество PHP-уведомлений и устареваний, но ничего критичного Наконец, я понял, что на прошлых выходных я установил кеширование APC для использования с W3 Total Cache. Удаление, которое полностью уничтожило 500 ошибок.

Моя точка зрения: ошибка 500 может быть просто комбинацией серверных настроек, которые представляют несовместимость. Это маловероятно, если вы используете управляемые сервисы, но с вашим собственным виртуальным частным сервером (почему вы должны использовать VPS вместо общего хостинга?

) вы несете ответственность за то, чтобы все работало вместе, и это сложнее, чем кажется.

На общем хосте вы можете найти Ограничение памяти PHP бьется — особенно сложные плагины могут вызвать это. Если вам повезет, вы также получите сообщение об ошибке в виде строки «Неустранимая ошибка: допустимый объем памяти xxx байтов исчерпан», но не всегда. Вы можете исправить это, добавив следующую строку в ваш wp-config.php:

define('WP_MEMORY_LIMIT', '64M');

Я говорю, может, потому что большинство общих хостов на самом деле не позволяют увеличить лимит памяти — вы берете то, что вам дают. Возможно, пришло время рассмотреть другие формы хостинга

?

Конечно, если вы сделали резервные копии до запуска каких-либо обновлений

у вас был бы легкий путь к восстановлению. Ужасно, когда ваш сайт выходит из строя — особенно если это для вас источник дохода, а не просто хобби — но, следуя этому руководству и будучи методичным, вы должны в скором времени восстановить его.

У вас когда-нибудь была внутренняя ошибка сервера 500 или пустая страница, которая не была решена одним из них? Дайте нам знать, в чем заключалась ваша проблема и как вы ее исправили.