Как не надо готовить Drupal или о том, что у меня под капотом
Многие пытающиеся подружиться с Drupal не совсем верно оценивают возможности системы и, довольно часто, прибегают к не совсем идеологически верным методам при решении своих задач. Drupal достаточно сложен и неуклюж, что для крупных проектов является некоторого рода барьером. Расскажу про свой опыт и попытки сделать нечто вроде системы комфортной для себя и лишенной недостатков, накопившихся со временем.
— Are you mad, bro?
— Yes! I am.
Уже где-то писал, что основная проблема в избыточности. Т.e. это как бы не совсем полноценный фрэймворк и уже далеко не просто CMS. Это достаточно мощный комбайн, который можно сравнить по строению с архитектурой Linux.
О плюсах и минусах вы можете почитать самостоятельно; пишут об этом много и часто. Я же попробую написать о вредном, о модификации ядра и некоторого рода перестройке архитектуры.
Собственно, что я сделал? Знакомство мое с системой началось с версии 4, но в силу малого опыта и отсутствия задач, которые с помощью Drupal я мог бы решить, капля мною оценена не была, хотя и заинтересовала. Дальше были другие движки, достаточно много, и в итоге, с нова Drupal, но уже 6й.
Завел я себе бложик, начав самой пожалуй тупой проблемы, когда при инсталляции нужно скопировать файл настроек. Начал понемногу систематизировать знания, писать, интересоваться SEO и повышать скил во front-end.
Вот тут и начали возникать проблемы: старая версия jQuery, ассорти из модулей, некоторые проблемы по части внутренней оптимизации и прочее, прочее, прочее. Большинство косяков конечно-же лечится модулями, но чтобы получить то, что было нужно мне это количество выходило неприлично большим. Админка превращалась в какое-то феерический спагетти из примочек, настроек и прочего барахла.
Мне это не нравилось и я начал тупо хакать ядро, постоянно получая по ушам от сообщества, где-то ставя свои правки, где-то перетягивая с модулей. В общем-то очень скоро меня задолбали обновления т.к. после них приходилось постоянно ревьювить код и снова хакать.
Сейчас ситуация стабилизировалась и обновлений 6й ветки не предвидится, а у меня под капотом уже даже не 6ка наверное. Внес более 50ти правок в ядро, переписал достаточно большую часть клиентских скриптов, запатчил очень многое по части кэша, кое-что взял с PressFlow и решений отдельных разработчиков.
За пару лет я перепилил достаточно многое и уже даже наверное не вспомню всего. Не трогалась лишь база данных, лишь изредка ковырял с помощью Schema на предмет косяков.
Получилось очень неплохо, я считаю, и есть идея оформить это все в отдельную сборку ориентированную на среднего формата сайты. На самом деле это мало кому будет интересно и я это прекрасно понимаю, однако, все таки сделаю.
Судя по тому, что я видел во внутренностях некоторых крупных проектов, которые от Drupal используют только оболочку(theming), систему блоков и очень малую часть потенциала, могу сделать вывод, что эта сборка отлично подойдет и для нагруженных сайтов.
Все стабильно и время затрачиваемое на обновления можно вполне использовать для развития того, что уже есть. Бэкпорт с седьмой ветки дело достаточно простое.
Я бы настоятельно не рекомендовал повторять этого с версиями ядра находящимися в активной поддержке, будет много слез и боли.
Зачем я это делал? Опыт, понимание архитектуры и API, повышение скила и т.д. Что думаете?
думаю, на drupal.org стоит выложить - пусть сообщество оценит.
> Сейчас ситуация стабилизировалась и обновлений 6й ветки не предвидится
1 февраля релиз
ох, прошляпил. буду ждать тогда
может тогда имеет смысл запостить свои патчи в Issue queue? или они сильно-сильно меняют текущую логику и поломают сайт при обновлении ядра?
Ну в общем то некоторые модули написаны через жопу(у меня, например, скриптового региона footer нет вообще, но какой-нибудь гуглосерчь работать без него не сможет).
Поэтому мне пришлось переписывать кое-что под свою конфигруацию. Дело по большей части не в патчах. Их слишком много для того, чтобы это ревьювилось.
Я изначально не ставил целю сделать сборку, делал just for fun, для себя. Если вы возьмете PressFlow, то там тоже достаточно много поправлено именно по части ядра. И как бы я один, а один в поле не воин. Помощь и советы не помешали бы.
Смысл то простой. Избежать самых банальных проблем и сделать минимальный набор маст-хэв в одной коробке.
Скинь я приведу все к друпалвэй
Там все нормально. Просто я патчи руками накатывал, надо отбивки и прочее в порядок привести( :D ). Ну и как бы у нас есть замечательная папочка с шелами для проверки code-style ;)
Смысла нет. Щас обновление выйдет можно будет ковырять.
Я поимаю, конечно, что хакать ядро быстрее, но почему было не наложить свои изменения хуками? Ну все нужные хуки есть? Большие потери производительности? Почему?
А потому, что у них тоже свои приоритеты есть. Попробуйте и поймете, что это не всегда дает желаемый результат. Ну и как бы сам по себе хук — это костыль.
Ну приоритеты расставить вроде как можно. Тут проблем быть не должно. Много кода получается... Не сильно знаком с друпал. При использовании хуков в друпал прежний код (который перекрывается хуком) все равно обрабатывается, в том числе делаются запросы к базе?
Просто как приятно зато, обновления движка без проблем.
Ну да, тогда вы придете к хаканию модулей. Возможно есть какой-то модуль который все эти хуки сможет переставить. Пусть они будут контриб, но, в данном случае, Drupal и есть набор нужных модулей.
Дело в том, что логику одного из ваших хуков может тупо накрыть другой хук.
Есть великое число сайтов, которым возможностей 7ки будет лишку
Не хотелось бы продолжать и разжигать hollywar на тему, что православнее ... Все действительно проще.
Отправить комментарий