За три года, что я работаю в web-разработке мне как-то удавалось избегать самого популярного в мире движка, не считая совсем мелких правок. Но мне приходилось слышать от коллег различные мнения от «Какое извращение превращать блог в магазин, форум и все, что угодно!» до «Вполне адекватная CMS для небольших проектов.» И вот предоставилась возможность поработать с WordPress воочию.

Первый блин

Надо сказать, что странности начались с самого начала. Оказалось, что в текущей версии прямо в ядро включена возможность функционирования в режиме «multisite», т.е. такой режим в котором на одной и той же копии движка работают несколько сайтов. Сам этот факт для меня весьма удивительный. Я могу представить себя ситуацию, при которой мне необходима будет такая система, но включать этот функционал в ядро? И тем более использовать его для размещения никак не связанных друг с другом сайтов, кроме того факта, что они принадлежат одной компании. Это мне не понятно.

Как и любая работа над сайтом, эта началась для нас с копирования сайта (точнее сайтов) на наш сервер и бекапа. Почему мы даже для мелких работ используем демо-версию сайта я напишу отдельно.

В переносе мультисайта мне помогли заметки SiteHint.ru и WP MAGAZINE. Как я понял, сложности связанные с этим давно известны сообществу WP и обсуждать их смысла нет. Наверное, этой заметки бы не было, если бы сайт «завелся» сразу после этого без проблем.

Настоящее веселье

Самое интересное началось, когда я думал, что перенос уже завершен успешно. Один из разделов (всего один и самый важный!) загружался не до конца. То есть просто в какой-то момент html код обрывался, как говорится «на самом интересном месте».

«Плавали, знаем», подумал я и стал искать, как включить ошибки. Перепробовал все, что можно от включения в конфиге, путем определения констант:

define(‘WP_DEBUG’, false);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);

до прямых директив

ini_set(‘log_errors’,’On’);
ini_set(‘display_errors’,’Off’);
ini_set(‘error_reporting’, E_ALL );

Ничего ни на экране, ни в логах. Все чисто, но где-то работа скрипта обрывается.
«Уф», подумал я, и приступил к ковырянию в скриптах. Что бы не мучить читателя сразу расскажу о результатах расследования. Оказалось, что падает кеширование, а именно функция

update_meta_cache(‘post’, $post_ids);

А в ней проблема возникает во время запроса кэша из БД:

$meta_list = $wpdb->get_results( “SELECT $column, meta_key, meta_value FROM $table WHERE $column IN ($id_list) ORDER BY $id_column ASC”, ARRAY_A );

И, наконец, изучив объект $wpdb я нашел место падения

while ( $row = @mysqli_fetch_object( $this->result ) ) {
$this->last_result[$num_rows] = $row;
$num_rows++;
}

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

Решение

Убрав собачку я увидел уже истинную причину проблем:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 81 bytes) in /var/www/path_to_script/wp-db.php on line 1684

Временно забыть о проблеме с памятью удалось заменив в wp-config.php

define(‘WP_MEMORY_LIMIT’, ‘64M’);

На

define(‘WP_MEMORY_LIMIT’, ‘128M’);

Конечно, нужно искать причину, почему скрипт «жрет» столько оперативки, но это уже не срочно.

Как так

После всей это истории у меня остался один вопрос. Как так получилось, что самый популярный в мире движок, которым пользуются в том числе новички, не выводит ошибки? Возможно, там есть какая-нибудь своя функцию обработки ошибок с помощью set_error_handler(). Но мне не удалось нагуглить, как это все включить.

Пока эти вопросы остались для меня без ответа. Если что-то изменится, напишу продолжение поста.

P.S. Все вышесказанное о движке WordPress 4.1.8