Вы выбираете систему управления контентом для вашего очередного сайта? Позвольте мне бросить пару камней в сторону Drupal. Теоретически Drupal – это CMS, позвляющая вам управлять сайтом творчески, проявлять все свои креативные возможности и простым способом реализовывать все свои задумки. Однако в реальности, конфигурация и поддержка сайта на Друпале – это сплошной кошмар.
Я готов признать, что Drupal хорошо подходит для маленьких сайтов: поставили, загрузили кастомную тему и заливаем потихоньку контент, не зная никаких проблем. Но если вы задумали создать серьёзный сайт с множеством кастомного функционала и рассчитанные на относительно большой объём трафика Droople, как я уже окрестил его, никак не может быть лучшим выбором для вас.
Апологеты использования данной CMS могут протестовать и доказывать мне, что использование каких-то определённых кастомных модов пофиксит все вызывающие у меня нарекания ошибки и проблемы. Но это не имеет значения: CMS, требующая установки каких-то там модов от энтузиастов и третьих лиц – это нонсенс.
Ладно, без лишних размышлений перейдём к разбору по пунктам, почем Drupal не подходит для многих проектов, приложив к каждому пункту разъяснение и обоснование (так называемые Why It’s Bad) такой позиции.
1. Drupal хранит всё, абсолютно всё в базах данных.
Базы данных прекрасно подходят для хранения паролей, контента и бесчисленного множества других вещей. Вот только к этим вещам не относятся "Views", т.е. фактически шаблоны. Да-да, шаблоны. В базе данных. Drupal хранит шаблоны в базе данных.
Лучшие практики настойчиво рекомендуют использовать системы контроля версий, тот же Subversion или Git которые, среди прочего, позволяет двум разработчикам "скачать" один и тот же код, чтобы работать над ним одновременно. К сожалению, для разработчиков Drupal, настройки базы данных, как правило, не хранятся в системе управления версиями. Это означает, что у двух разработчиков нет простого способа координации совместной работы. Кроме того, вам придётся потратить немало времени перенося одинаковые настройки на несколько серверов, если у вас сайт с большими объёмами трафика, требующий балансировки нагрузки, или на промежуточный сервер, где вы хотите, просматривать изменения перед тем, как выпускать их в жизнь.
Что ещё Drupal хранит в базе данных? Логи. В базе данных. Логи в Drupal хранятся в базе данных.
WIB: В логах записываются посещения вашего сайта, а также другая полезная информация, те же ошибки, к примеру. Если у вас сайт генерирует много трафика, то логи обычно становятся большими, и счёт уже идёт совсем не десятками мегабайт. Однако, если ваш проект не является каким-то гиперважным и совершенно секретным, нет смысла хранить их все. А если вы регулярно делаете бэкапы, а я думаю, что конечно делаете, весь этот объём бесполезной информации переносится с каждым бэкапом. Кроме того при возникновении ошибки у вас возникает потребность предоставить администратору или какому-то стороннему программисту доступ к базе данных. А это далеко не всегда приятно, когда кто-то роется в вашей базе – высока угроза потерять важные данные из-за какой-нибудь глупой ошибки в запросе.
2. Drupal чертовски сложен в освоении и настройке.
В старые добрые времена создание сайта означало HTML-кодирование страничек, а потом последующая их закачка на сайт. Изменения в контент производились не менее прямым способом – странички скачивались, перекодились и заливались обратно. С развитием интернета желающих администрировать свой сайт людей и не знающих при этом HTML становилось всё больше, и для них появились системы управления контентом – посредники, которые позволяли пользователю войти в систему, поправить все, что ему надо, и отправить обратно, без каких-то особых интеллектуальных усилий и специфических знаний. Причем разобраться в таких CMS можно вполне и за день.
А теперь возьмите Drupal. Данная CMS, друзья мои, столь раздута, что требуется несколько дней, если не недель, для неспециалистов, чтобы узнать разобраться что там вообще к чему. В самом деле, мои клиенты так запуганы интерфейсом Drupal, что по-прежнему посылают мне контент и просят меня вставить его для них.
WIB: Сам смысл CMS как инструмента – это обеспечение возможности обновления сайта неспециалистом. Я думаю, что обычный человек может научиться основам HTML и заливки по FTP за несколько недель. Таким образом, если CMS занимает у вас недели, чтобы с ней хоть как-то разобраться, и вам при этом все еще нужен технарь, который помогал бы вам понять какие-то сложные моменты, значит CMS просто напросто не выполняет свою задачу по упрощению процесса обновления сайта.
Почему Drupal так трудно использовать? Из-за сочетания плохой юзабилити и запутанной навигации. В качестве примера плохой юзабилити Drupal можно привести необходимость дважды подтверждать изменения, прежде чем они будут сохранены, при этом кнопка Save часто находится, фиг знает где. Что касается проблем навигации: создание поста в блог находится в разделе "Create content", но редактирование этого же поста осуществляется в разделе "Manage content" , а заполнение контентом сайдбара происходит в разделе "Site Building / Blocks". Чего?
3. Сделан Drupal отвратительно.
У Drupal есть целая история уязвимостей, и написан он в уродливом спагетти-код стиле. (Ребята, вы слышали о классах? Объектах? Наследовании? Ах, Nevermind).
Не стоит забывать и о сложности поддержки сайтов с Drupal. Когда выходит новая версия CMS, ваши старые темплейты и прочий код подвергается серьёзной угрозе, и требуется время и, соответственно/ усилия, чтобы после обновления всё заработало, как прежде. Да, у всех фреймворков бывают проблемы со старыми API, однако на своём веку я не встречал примеров, чтобы простой апгрейд версии CMS мог иметь столь драматические последствия, да и часто встречаются специальный встроенный функционал в новых версиях для упрощения миграции кода.
4. Drupal отнюдь не дружественен к своим пользователям.
В интернете поднялась шумиха насчет новой трэйдмарк политики Drupal, которая явно противоречит духу open source сообщества. Почему же вы так яростно защищаете свой торговый знак в Drupal, когда ваш продукт такой открытый и великолепный, а? А потом так яростно сражаетесь с последствиями такой политики в виде сайта Drupalsucks.com? (Новые правила использования торговой марки Drupal и соответствующего лого требуют получения на это лицензии у владельца).
Заключение
Если вы создаёте низкобюджетный сайт без каких-либо наворотов, то Drupal вам вполне может подойти. Если же ваш сайт всё-таки посложнее, и вам приходится нанимать оксюморонного Drupal девелопера, чтобы он сделал так, чтобы что-нибудь работало, то уж лучше тогда нанять спеца по Ruby on Rails – нервов потрачено будет раза в два меньше, а CMS в результате уж точно не хуже.
P.S Имеются в виду под темплейтами не tpl файлы, а Drupal Views
P.P.S И да, поиск в Drupal тоже sucks
P.P.P.S. Да, и для шаблонов, хранимых в файловой системе, допущения именования для оверрайдинга конкретного элементов, ужасны. Например, block-block-5.tpl.php содержит автоматически сгенерированный идентификатор файла. Таким образом, если нод / блок имеет разные ID в разных средах (dev и продакшн), вам не повезло, и шаблон не будет работать.
Оригинал | Источник: robozen.com
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.