Заметки на память для начинающих вебмастеров, web-программирование, создание блогов, сайтов, продвижение и монетизация

Здравствуйте, уважаемые читатели и посетители блога 4remind.ru. В этой статье речь пойдет о проблеме со входом в панель управления (админку) блогов на движке WordPress, с которой столкнулись или могут столкнуться некоторые из новичков.

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

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

Для более менее опытных или особо нетерпеливых скажу сразу, что основная причина кроется в состоянии флага настроек PHP output_buffering. Поставьте PHP флаг output_buffering в состояние «on» и проблема скорее всего сразу же решится.

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

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

    display_errors = On

Во первых, это можно проделать в файле php.ini, если Вы конечно знаете где он находится, имеете к нему доступ, и если на хостинге разрешено изменять настройки PHP.

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

php_flag display_errors on

Если же файл .htaccess отсутствует в корневом каталоге сайта, то его необходимо там создать. В принципе файл .htaccess можно создать и не в корневом каталоге, а там, где находятся вызываемые вами скрипты, которые генерируют ошибки выполнения.

И в третьих, флаг display_errors может быть установлен из самого PHP скрипта вызовом функции ini_set()

После включения вывода ошибок PHP при моих испытаниях я получал вот примерно такие ошибки при попытке входа в админку WordPress:

    Warning: Cannot modify header information - headers already sent by (output started at
             /.../.../wp-content/themes/ваша-тема/functions.php:1) in
             /.../.../wp-includes/pluggable.php on line 669

Не буду глубоко вдаваться в теорию, и скажу вкратце, что часть информации из ошибки
«Cannot modify header information - headers already sent»
меня практически сразу навела на мысль о том, что при работе скриптов на сайте происходит рассогласование. Другими словами сервер уже выдал браузеру часть информации, которая еще нужна была другому скрипту для выполнения своей операции, то есть один из скриптов или его функции уже отправили браузеру часть пакетов, не дожидаясь и не учитывая того, что еще другой скрипт или функция должны были добавить свою часть к отправке.

Решением проблемы послужит включение буферизации вывода в PHP, и нужно всего лишь включить флаг PHP output_buffering либо в файле php.ini (если у вас конечно есть доступ к php.ini файлу)

    output_buffering = On

либо добавив следующую строчку в файл .htaccess

    php_flag output_buffering on

Есть правда одно замечание по поводу флага output_buffering... Установив его значения во включенное состояние следует учитывать то, что при буферизации вывода скрипты PHP будут аккумулировать свои выходные данные в памяти на сервере хостинга, что может привести к ситуации, когда выделенной для вашего сайта памяти может не хватить, и в результате некоторые запросы к сайту не будут обработаны, пока память не освободится. Это как правило может быстро проявиться, когда у сайта большая и интенсивная посещаемость. Чтобы избежать подобной ситуации для флага PHP output_buffering предусмотрено вместо значения «on» устанавливать размер буфера в байтах, например так

    output_buffering = 4096

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

Обычно на хостинге, где уже есть предустановленный WordPress, особенно последних версий, флаг PHP output_buffering уже включен, и вышеописанных ошибок как правило не возникает. Но меня конечно удивило то, что в движке WordPress 3.3.1 при первом же запуске, конфигурации, да и в последующих операциях не проверяется возможность появления подобной ситуации. Будем надеяться, что в последующих версиях эту проблему устранят.

Кроме приведенного выше примера, когда проблема решалась с помощью директивы PHP output_buffering, могут быть и другие ситуации.
Если, скажем, Вы отредактировали какой-нибудь скрипт, например файл конфигурации wp-config.php, и перед отправкой его на сервер сохранили в кодировке, отличной от настроек вашего сайта и базы данных для него, то кроме описанной в этой статье проблемы могут появиться и другие.
Во избежание неприятностей старайтесь всегда проверять кодировку символов в изменяемых вами файлах. В WordPress по умолчанию применяется кодировка UTF-8, так что и файлы после редактирования или копирования тоже нужно сохранять в кодировке UTF-8. Я например для редактирования скриптов использую бесплатный редактор Notepad++, но и с ним новичку нужно быть внимательным, так как в нем есть два режима преобразования в кодировку UTF-8: "Преобразовать в UTF-8" и "Преобразовать в UTF-8 без BOM". Выбирайте второй вариант «Преобразовать в UTF-8 без BOM».

На этом пожалуй пока закончим.
Удачной Вам установки и запуска блогов на движке WordPress!

Метки: htaccess, PHP, WordPress