WordPress - главные проблемы новичка

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

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

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

Не все популярные плагины хороши

Есть плагины к которым просто привыкли. Кроме того, некоторые серьезные недостатки можно обнаружить только на хорошо посещаемом сайте. А большинство из "миллиона загрузок" этого плагина могли быть произведены для мало посещаемых сайтов. И на этих малопосещаемых сайтах могли просто не заметить недостатки плагина. Здесь важно то, что если есть проблемы в коде, то это уже в целом плохой признак.

Например, если простенький плагин совершает десятки (это пример из реальной ситуации) одинаковых запросов к БД (да, именно десятки), то пусть это будет незаметно, и не важно вначале, но это говорит об общем качестве. И если общее качество плагина настолько низкое, то нет никаких гарантий, что в нем нет ошибок, которые не выльются в будущем неприятными сюрпризами. Не говоря уже о том, что со временем нагрузка может возрасти и все незаметные ранее проблемы станут сразу ощутимы.

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

Плагины-дебагеры - обязательны

Речь о плагинах, которые выводят текущую информацию о том, сколько было сделано запросов, какие обнаружены ошибки, сколько памяти было использовано и пр. Без них можно пребывать в счастливой уверенности, что все в порядке, и даже не знать, что вместо 20 запросов к БД происходит 150 (речь опять о реальной ситуации). И что виной всему какой-нибудь кривой плагин (или даже несколько кривых плагинов) в которых была уверенность, потому что вроде бы много хороших оценок и закачек (хотя этот вал оценок может быть вполне просто из за красоты и удобства, или вообще - из за случайной популярности).

Вообщем плагины анализирующие систему - обязательны. На момент написания этой заметки мне больше всего понравились два из них: "Debug Bar" и "Query Monitor". Во втором есть интересный пункт "Дублирующиеся запросы", который показал мне, что популярный плагин, в котором я был уверен, выдавал десятки таких запросов, и тормозил весь сайт (при том, что его задача была - просто показать всплывающее окно один раз). Так что надо быть внимательным, не доверять рейтингам и обязательно делать простое тестирование (увлекаться сразу сложными плагинами здесь наверное не стоит - вполне хватит простых тестов хотя бы для начала).

* Эти тестирующие плагины перед запуском "вчистую" лучше отключить. Включить опять для тестирования их можно будет потом в любой момент.

Плагины кэша нужно хорошо протестировать

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

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

Встроенный Cron - большой тормоз

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

Оказывается, встроенный в WordPress механизм работы Cron имеет очень специфическую особенность, - он рассчитан на срабатывание от захода посетителей. И это имеет два последствия. Первое, - каждый посетитель, при каждом заходе, запускает проверку - нет ли сейчас у Cron заданий в ожидании? Каждый заход на сайт происходит такая проверка! Второе, - если задания есть, то они выполняются прямо в сеансе открытия посетителем страницы. Т.е. посетитель которому "не повезло" попасть на выполнение запланированного задания, запускает его своим заходом и ждет пока оно выполнится! Если сайт новый, и посетителей мало, то это будет особенно заметно, потому что задания могут скапливаться, и первый же посетитель после случайного перерыва будет их сразу все запускать (и ждать открытия страницы, пока они выполняются).

Поэтому надо включить задание для полноценного Cron на самом сервере, а Cron встроенный в WordPress (работающий от заходов посетителей) - надо отключить.

ВАЖНО! Настроенное на сервере задание Cron для WordPress надо обязательно проверить, и убедиться что оно работает правильно. Что правильно выбран пользователь от которого запускается задание. Что коннект происходит на нужный движок, и все работает так как ожидается.

Для задания "серверного Cron" можно использовать curl. Есть экзотические варианты с использованием wget, но я от них отказался.
Задание для Cron может выглядеть примерно так:
nano /etc/cron.d/wp-run :

*/10 * * * * 	 www-data 	 curl -k -u 'user:password' https://_САЙТ_.com/wp-cron.php?doing_wp_cron

wp-run - имя файла задания для Cron (можно изменить на свое)

*/10 - выполнять задание каждые 10 минут (от имени пользователя www-data)

-k - отключает проверку для httpS

-u 'user:password' - нужны, если подключение требует аутентификации (здесь просто для примера)

_САЙТ_ - доменное имя сайта

Теперь после успешного тестирования и включения Cron на сервере, нужно отключить запуск Cron из браузера посетителями.
Для этого надо в корневом каталоге движка добавить в файл конфига строку:
wp-config.php

...
define ('DISABLE_WP_CRON', true);
...

ВАЖНО! Эту строку надо добавить где-нибудь до объявления константы 'ABSPATH'.

КСТАТИ! для проверки заданий Cron есть популярный плагин WP Crontrol. В нем можно проконтролировать список заданий. Кроме того, можно установить удобный инструмент командной строки для WordPress - wp-cli.

Общий итог

Здесь перечислено далеко не все с чем приходится сталкиваться новичку. Но я и не ставил такую цель. Мне хотелось подчеркнуть только то, что очень важно, и, при этом, мало упоминается, и ошибки в чем могут иметь большие последствия.

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