Для чего подходит и не подходит WordPress

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

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

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

Разные базы пользователей

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

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

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

Ограничения при работе с пользователями

Иногда ставится задача сделать из WordPress какой-то социальный сервис. Обычно это просто многоавторский блог с неким расширенным функционалом.

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

Однако существует 1% тех, кому действительно нужен такой фукнционал. Например это несколько авторов, знакомых, которые решили совместными усилиями вести один блог.

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

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

Высокое ресурсопотребление WordPress

Тенденция такова, что новые версии WordPress потребляют всё больше и больше ресурсов. В основном дело касается памяти для PHP. Приведу небольшую статистику из своего опыта (обычные рабочие блоги с примерно одинаковым количеством плагинов [анализ потребления памяти]):

• WordPress 2.0* - около 5Мб
• WordPress 2.1-2.3.3 - 8-11Мб
• WordPress 2.5+ - 15-23Мб

В последних версиях WordPress (на данный момент 2.6) разработчики вообще убрали файловый кэш, таким образом потребление памяти может еще больше возрасти.

Само по себе потребление памяти может и не так критично, потому что многие хостинги выделяют по 32Мб для php-скриптов. Но здесь проблема в том, что это получается из-за крайней неоптимизированности самого WordPress. Я уже писал об этом - проблема в том, что в WordPress'е загружаются все файлы скопом - не зависимо от того, будут ли ни использоваться или нет. (Подробнее см. здесь в разделе «Чем не уcтраивает WordPress?»)

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

Самые же большие проблемы начинаются если посещаемость блога резко возрастает. Если перевести на цифры, то по моим наблюдением есть два критических порога: 200 хостов и 1000 хостов в сутки. В первом случае потребуется переход с самого дешевого тарифного плана на следующий; а во втором либо вас попросят перейти на VDS, либо купить самый дорогой тариф.

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

Решения. Прежде всего не стоит сразу кидаться на новые версии WordPress. Разработчики поступают довольно хитро, объявляя о сотнях исправлений, однако скромно умалчивают, что большинство из них было внесено в предыдущую версию в виде нового функционала. Наиболее удачной/последней на мой взгляд была версия 2.0.11. Если не требуется использовать виджеты и новые плагины - то она идеально подходит для большинства блогеров. Если же нужна поддержка виджетов и максимальная совместимость с плагинами, то 2.3.3 - идеальный выбор. Версии от 2.5 - ничего хорошего, кроме рюшечек и дополнительной головной боли не несут, поэтому для посещаемого блога особого смысла не имеют.

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

Богу богово, вордпрессу - блогово

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

Задача, естественно решаема, но нужно сразу же держать в голове и тот момент, что WordPress получает данные еще до того, как они будут выведены. Поэтому для формирования своего вывода потребуются дополнительные запросы к БД и т.д. В итоге опять возрастает нагрузка, что в свою очередь требует использовать кэширование уже на уровне шаблона. Поэтому совсем не удивительно, что многие WordPress-шаблоны, которые используют свой вывод создают большую нагрузку.

Чтобы оценить важность данного момента приведу цифры из недавнего заказа. Нужно было сделать десяток блоков на главной, что привело к примерно 100 запросам к БД. Лишь только используя кэширование удалось сбить их до приемлемых 18-20.

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

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

Технически это обойти очень сложно, но можно попытаться сымитировать. Например для вывода в сайдбаре группы рубрик я использую свой виджет «Группа», в котором указывается родительская рубрика и получается вывод всех её «детей». Аналогичный виджет «Последние записи», который позволяет выводить записи из одной определенной рубрики (или рубрик). То есть возможность показать такой сложный вывод существует, но на практике мы всё опять сводим к записям, рубрикам и страницам.

Можно привести еще другие примеры, но думаю этого достаточно. Нужно понимать, что WordPress - блоговый «движок» и сделать на нем какой-то другой тип сайта довольно сложно.

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