Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 74
2 вопроса:
Что осталось от Drupal?
И стоило ли брать Drupal?
Что осталось от Drupal?
И стоило ли брать Drupal?
От Drupal осталось всё :)
Удобная админка, быстрое создание и изменение вьюсов, гибкость темизации, огромная база знаний…
Если бы делали проект с нуля (даже на каком-нибудь framework'е), ушло бы на порядок больше времени.
По второму вопросу — не знаю, честно.
Возможно, стоило попытать счастья с какой-нибудь другой CMS, «заточенной» под магазин — например, Magento. Однако в данном случае нам было проще работать с тем продуктом, который мы хорошо знаем.
Удобная админка, быстрое создание и изменение вьюсов, гибкость темизации, огромная база знаний…
Если бы делали проект с нуля (даже на каком-нибудь framework'е), ушло бы на порядок больше времени.
По второму вопросу — не знаю, честно.
Возможно, стоило попытать счастья с какой-нибудь другой CMS, «заточенной» под магазин — например, Magento. Однако в данном случае нам было проще работать с тем продуктом, который мы хорошо знаем.
> Если бы делали проект с нуля (даже на каком-нибудь framework'е), ушло бы на порядок больше времени.
На порядок больше времени ушло бы в том случае, если бы вы с выбранным фреймворком работали впервые. У опытной и имеющей наработки команды (да даже у одного опытного программиста) времени бы ушло, наоборот, меньше.
Например, сформулировать в ORM вашего фреймворка зависимости моделей друг от друга — быстрее, чем пытаться сделать то же самое в вэб-интерфейсе Drupal Views. Вот, для примера, как это делается на Ember: emberjs.com/guides/models/defining-models/#toc_defining-relationships. Это правда очень просто и быстро. Вкуривать же, почему Views выдает пустую выборку при попытке сделать запрос с фильтрами и join'ом двух-трех таблиц, можно часами.
На порядок больше времени ушло бы в том случае, если бы вы с выбранным фреймворком работали впервые. У опытной и имеющей наработки команды (да даже у одного опытного программиста) времени бы ушло, наоборот, меньше.
Например, сформулировать в ORM вашего фреймворка зависимости моделей друг от друга — быстрее, чем пытаться сделать то же самое в вэб-интерфейсе Drupal Views. Вот, для примера, как это делается на Ember: emberjs.com/guides/models/defining-models/#toc_defining-relationships. Это правда очень просто и быстро. Вкуривать же, почему Views выдает пустую выборку при попытке сделать запрос с фильтрами и join'ом двух-трех таблиц, можно часами.
> Удобная админка…
Помойму это худшая админка для конечного пользователя
Помойму это худшая админка для конечного пользователя
Во-первых, при кэшировании запроса наш фильтр товаров стал выдавать один и тот же результат, пришлось отключить.Пропатчить вьюс можно
drupal.org/node/1055616#comment-8610445
О, супер, спасибо!
Хотя, для фильтров у которых нет фиксированных значений наверно не стоит кэш включать. Количество комбинаций получится огромным.
Патч добавлен в последней версии Views 3.8:
#1055616 by johnv, Dmitriy.trt, tomgf, ygerasimov, dawehner, zipymonkey, citlacom, tim.plunkett, vaartio, hefox: Query arguments should be replaced before generating cache ID.
#1055616 by johnv, Dmitriy.trt, tomgf, ygerasimov, dawehner, zipymonkey, citlacom, tim.plunkett, vaartio, hefox: Query arguments should be replaced before generating cache ID.
Пробовали проиндексировать чем-то вроде Apache Solr или Sphinx и для представления использовать проиндексированные данные? В качестве бонуса получите Фасетный поиск и не только.
Описанные в статье пляски с бубном — одна из четырех причин, по которым я забил на Drupal и стал учить EmberJS и Rails.
Другая причина — в отсутствии внятного цикла development -> staging -> production. Развитие уже запущенного сайта — лютая морока.
Третья — чрезвычайная запутанность внутреннего устройства Drupal. Да, это самая гибкая и функциональная CMS в мире, из числа тех, которые можно настраивать мышкой, не написав ни строчки кода. Но шаг вправо/шаг влево от штатных возможностей модулей — и всё, тупик. Осваивать программирование под Drupal я посчитал слишком трудной и неблагодарной задачей. При одинаковых трудозатратах, я предпочел стать вэб-программистом, чем починятелем примусов системы Drupal.
Четвертая причина — тормознутость разработки многих жизненноважных модулей. Мне до сих пор приходят на почту уведомления о комментариях к багрепортам и фичереквестам, которые были созданы еще для шестой версии и до сих пор не решены.
Спасибо, наигрался, сделал выводы, пора двигаться дальше.
Я не понимаю людей, которые упорно сидят на Drupal и опирают на него свой бизнес. Попробуйте пару уикендов поковырять Ruby/Rails, Python/Django, JS/Derby. Когда вы почувствуете, как вэб-приложение поднимается из нескольких элегантных строчек кода и послушно делает всё, что вы ее попросите понятным языком — вы уже не сможете смотреть в сторону Drupal.
PS Пожалуйста, не срите в карму. Я высказал честное и обоснованное мнение, опирающееся на личный опыт. И я правда не виноват, что вам почему-то слабо освоить нормальный язык программироавния и современный фреймворк. Это гораздо проще, чем кажется. Нужно пару выходных, чтобы освоиться и войти во вкус, а дальше по накатанной.
Я не могу сказать, что Drupal тянул меня на дно, это было бы сгущением красок. Напротив, он был моим автобусом в мир вэб-разработки. Но автобус ходит по одному и тому же маршруту. Пересаживайтесь с автобуса в личный автомобиль, на котором вы можете ездить куда угодно. Возьмите пару уроков вождения (это бесплатно и не больно) — и вы станете удивляться, как можно было полжизни пользоваться автобусом.
PPS Статью плюсанул.
Другая причина — в отсутствии внятного цикла development -> staging -> production. Развитие уже запущенного сайта — лютая морока.
Третья — чрезвычайная запутанность внутреннего устройства Drupal. Да, это самая гибкая и функциональная CMS в мире, из числа тех, которые можно настраивать мышкой, не написав ни строчки кода. Но шаг вправо/шаг влево от штатных возможностей модулей — и всё, тупик. Осваивать программирование под Drupal я посчитал слишком трудной и неблагодарной задачей. При одинаковых трудозатратах, я предпочел стать вэб-программистом, чем починятелем примусов системы Drupal.
Четвертая причина — тормознутость разработки многих жизненноважных модулей. Мне до сих пор приходят на почту уведомления о комментариях к багрепортам и фичереквестам, которые были созданы еще для шестой версии и до сих пор не решены.
Спасибо, наигрался, сделал выводы, пора двигаться дальше.
Я не понимаю людей, которые упорно сидят на Drupal и опирают на него свой бизнес. Попробуйте пару уикендов поковырять Ruby/Rails, Python/Django, JS/Derby. Когда вы почувствуете, как вэб-приложение поднимается из нескольких элегантных строчек кода и послушно делает всё, что вы ее попросите понятным языком — вы уже не сможете смотреть в сторону Drupal.
PS Пожалуйста, не срите в карму. Я высказал честное и обоснованное мнение, опирающееся на личный опыт. И я правда не виноват, что вам почему-то слабо освоить нормальный язык программироавния и современный фреймворк. Это гораздо проще, чем кажется. Нужно пару выходных, чтобы освоиться и войти во вкус, а дальше по накатанной.
Я не могу сказать, что Drupal тянул меня на дно, это было бы сгущением красок. Напротив, он был моим автобусом в мир вэб-разработки. Но автобус ходит по одному и тому же маршруту. Пересаживайтесь с автобуса в личный автомобиль, на котором вы можете ездить куда угодно. Возьмите пару уроков вождения (это бесплатно и не больно) — и вы станете удивляться, как можно было полжизни пользоваться автобусом.
PPS Статью плюсанул.
Я не понимаю людей, которые упорно сидят на Drupal и опирают на него свой бизнес.Потому что этот бизнес приносит им деньги, а эти деньги рождают спрос на друпал. Делать мало бюджетные сайты на рельсах или джанго сомнительное удовольствие. Заказчик платит за результат, а результат это качественный сайт. На каком ЯП или фреймворке сделан этот сайт мало кого интересует. Главное, что этот сайт работает и выполняет функции для которых он создавался.
Так я про типовые сайты-визитки и не спорю.
Но когда речь заходит о кастомном интернет-магазине с развитым каталогом, который в немодифицированном Drupal грузится пять минут на мощном ненагруженном сервере, то ситуация уже совсем другая. Когда ты прикручиваешь memcached; ставишь десяток модулей, написанных кулибиными; хачишь код CMSки; когда над одним сайтом работает не один вэбмастер, а команда из нескольких программистов, которые теряются в попытках завести этот агрегат и сидят изучают структуру SQL-запросов, которые делает CMS-ка — то вы таки вырасли из штанишек.
Вот ты понимаешь, что твои Жигули совершенно не справляются. Ты можешь пойти пересесть в Ауди, но вместо этого ты почему-то предпочитаешь мучиться, перебирая у Жигулей коробку, растачивая цилиндры и заменяя карбюратор на самодельный девайс, изготовленный рукастым соседом. Причем, Ауди выдают бесплатно, надо только научиться его водить, а обучение вряд ли займет больше времени, чем вечные мытарства с Жигулями.
Я считаю, что причина у этого только в косности мышления. Сложно заставить себя взяться за незнакомый Ауди с этими непонятными инжекторами, турбонаддувами, АБСами, коробками-автоматами и пиндосскими подушками. Родной Жигуленок «ближе к телу», к тому же Петрович говорит, что Ауди коробки-автоматы делать не умеет.
Но когда речь заходит о кастомном интернет-магазине с развитым каталогом, который в немодифицированном Drupal грузится пять минут на мощном ненагруженном сервере, то ситуация уже совсем другая. Когда ты прикручиваешь memcached; ставишь десяток модулей, написанных кулибиными; хачишь код CMSки; когда над одним сайтом работает не один вэбмастер, а команда из нескольких программистов, которые теряются в попытках завести этот агрегат и сидят изучают структуру SQL-запросов, которые делает CMS-ка — то вы таки вырасли из штанишек.
Вот ты понимаешь, что твои Жигули совершенно не справляются. Ты можешь пойти пересесть в Ауди, но вместо этого ты почему-то предпочитаешь мучиться, перебирая у Жигулей коробку, растачивая цилиндры и заменяя карбюратор на самодельный девайс, изготовленный рукастым соседом. Причем, Ауди выдают бесплатно, надо только научиться его водить, а обучение вряд ли займет больше времени, чем вечные мытарства с Жигулями.
Я считаю, что причина у этого только в косности мышления. Сложно заставить себя взяться за незнакомый Ауди с этими непонятными инжекторами, турбонаддувами, АБСами, коробками-автоматами и пиндосскими подушками. Родной Жигуленок «ближе к телу», к тому же Петрович говорит, что Ауди коробки-автоматы делать не умеет.
Так я про типовые сайты-визитки и не спорю.Малобюджетные сайты это намного больше чем «типовые сайты визитки».
Можно условно определить их объёмом работы: 2-3 недели для одного друпал разработчика средней квалификации (включая вёрстку). Это огромный сегмент рынка, в котором джанго и рельсы почти полностью отсутствуют ввиду своей неконкурентноспособности. Наивно полагать все фрилансеры и студии которые «держат» это нишу на рынке имеют закостенелый мозг и не понимают, что ауди лучше жигулей.
Еще раз. Я со сказанным вами не спорю, но когда над одним сайтом работает не один вэб-мастер, а несколько программистов (цитаты из статьи: «Дальше программисты опять достали бубен со шкафа», "«Друзья» — как то сказал наш самый опытный разработчик"), то это уже не тот уровень, о котором вы говорите.
Ну а причем тут количество программистов в проекте? Что бы оценить уровень проекта достаточно просто зайти на сайт (ссылка есть в топике). Конкретно для этого проекта, вполне вероятно, можно было использовать какую то другую платформу вместо друпала. Разумеется при наличие программистов с соответствующим опытом.
В статье описаны проблемы с производительностью, которые возникли при разработке данного конкретного магазина. И способы их решения. Но со стороны это больше похоже на расказ про то как мышки плакали и продолжали есть кактус. )
В статье описаны проблемы с производительностью, которые возникли при разработке данного конкретного магазина. И способы их решения. Но со стороны это больше похоже на расказ про то как мышки плакали и продолжали есть кактус. )
Но со стороны это больше похоже на расказ про то как мышки плакали и продолжали есть кактус. )
Об этом я и говорю! Сайт действительно не выглядит дорогим. Но он становится дорогим, когда к его разработке привлекается несколько программистов, а потом вылезают такие вот косяки, для решения которых требуется квалификация более глубокая и специализированная, чем квалификация Rails-программиста среднего пошиба.
Я уже не говорю о том, что развитие работающего Drupal-сайта — очень нетривиальная задача. Допустим, заказчик попросит добавить в каталог новые типы товаров и новые фильтры (не размножая при этом content types).
Но как это делать, если сайт уже в продакшене?
Способ, которым пользуются все программисты фреймворков — внести изменения в код, задеплоить код и прогнать миграции — для Drupal невозможен.
Официальный способ это сделать — при помощи Features. Но когда я в последний раз пользовался Drupal, Features работали неполноценно (экспортировали не всё, что нужно) и поддерживались не всеми используемыми модулями, и я не верю, что сейчас ситуация с Features принципиально изменилась к лучшему.
Что остается? Либо внучную воспроизводить фичи на продакшене, удваивая объем работы и показывая в процессе недоделанный сайт посетителям, либо вырезать отдельные таблицы и приживлять их на продакшен и изобретать кастомные миграции. Оба способа — для настоящих поедателей кактусов.
Но как это делать, если сайт уже в продакшене?
Способ, которым пользуются все программисты фреймворков — внести изменения в код, задеплоить код и прогнать миграции — для Drupal невозможен.
Официальный способ это сделать — при помощи Features. Но когда я в последний раз пользовался Drupal, Features работали неполноценно (экспортировали не всё, что нужно) и поддерживались не всеми используемыми модулями, и я не верю, что сейчас ситуация с Features принципиально изменилась к лучшему.
Что остается? Либо внучную воспроизводить фичи на продакшене, удваивая объем работы и показывая в процессе недоделанный сайт посетителям, либо вырезать отдельные таблицы и приживлять их на продакшен и изобретать кастомные миграции. Оба способа — для настоящих поедателей кактусов.
Тут стоило бы уточнить что вы имеете ввиду под типом товара: тип товара, тип ноды, или категорию товара, первое — относится к сущностям Commerce, у которых собственно есть поля с ценой и другой спец-информацией, второе — к сущностям друпала и скорее представляет контекст отображения товара, третье — вообще таксономия. И если последнее вообще работа менеджеров, то первые два, как вы и сказали, решается «фичами». Сейчас фичи экспортируют многое, но некоторых вещей, согласен, все же иногда не хватает. Правда у фич изначально была другая идеология, это не инструмент деплоя, а мини-приложения, поэтому они и представляют собой отдельные модули.
С проблемой деплоя друпал-сайта согласен, но ИМХО, это проблема не настолько серьезная, чтобы из-за нее отказываться от друпала. К тому же сейчас в разработке есть несколько перспективных модулей для деплоя, можно надеяться, у них получится хорошо сынтегрироваться с drush'ем.
С проблемой деплоя друпал-сайта согласен, но ИМХО, это проблема не настолько серьезная, чтобы из-за нее отказываться от друпала. К тому же сейчас в разработке есть несколько перспективных модулей для деплоя, можно надеяться, у них получится хорошо сынтегрироваться с drush'ем.
Проблема в том, что Drupal хранит конфигурацию в БД, и при развитии существующего сайта у вас возникает две версии: одна в продакшене, с новым контентом, и другая в девелопменте, с новыми фичами.
Нельзя просто перенести базу из девелопмента в продакшен. Вы потеряете пользовательский контент. Деплоить новые фичи путем копирования базы Drush'ем — это розовая мечта.
Базы потребуется мерджить. Но нельзя просто взять какие-то таблицы из продакшена, а какие-то из девелопмента. Это поломает сайт.
Смерджить базы, ничего не сломав, — задача нетривиальная и до сих пор нерешенная. Как говорится, если от болезни существует множество разных способов лечения, значит, она неизлечима. Я допускаю, что гиганты вроде Acquia имеют проприетарные решения, которые работают, но они ими с сообществом не поделятся, потому что это их конкурентное преимущество.
Когда я сидел на Drupal 6, я для этой задачи более или менее успешно использовал dbscripts. Проект умер, к большому сожалению, но вполне закономерно. Умер и Deploy, который вы рекомендуете, причем даже раньше, чем dbscripts, хотя успел родить сырую альфу для Drupal 7, которой я бы не рискнул пользоваться. Подобных проектов я видел много, но ни один не дорос до рабочего релиза, так что я считаю этот путь тупиковым. Уверен, со мной согласится любой разработчик, знающий значение термина «миграция».
Features — тоже не выход, потому что вы никогда не сможете нормально задеплоить с их помощью фичи реального сайта. Половина модулей не поддерживает Features или поддерживает криво или не полностью. Прошли годы, а воз и ныне там. Да и «деплоем» это назвать язык не поворачивается, потому что этот путь сопряжен с большим количеством геморроя. Выше писали, что изначально Features задумывались для другой цели, но сообщество вынуждено пытаться их использовать за неимением ничего лучше.
Про идею импорта фич руками я промолчу.
Что остается? Только ждать Drupal 8, на который вы не сможете смигрировать ни один ваш сайт. Но я уже достаточно нахлебался проблем с Drupal, чтобы потерять всякий энтузиазм и интерес.
Чтобы создать подобный Drupal конструктор — да. Чтобы создать проект, аналогичный по функционалу сайту, собранному на Drupal, потребуется столько же или меньше времени, чем на Drupal (если, конечно, речь идет о более или менее сложных сайтах вроде сабжа, а не сайтах-визитках с самым типовым функционалом). При этом поддержка и развитие такого проекта будут гораздо проще и эффективнее, чем на Drupal.
Нельзя просто перенести базу из девелопмента в продакшен. Вы потеряете пользовательский контент. Деплоить новые фичи путем копирования базы Drush'ем — это розовая мечта.
Базы потребуется мерджить. Но нельзя просто взять какие-то таблицы из продакшена, а какие-то из девелопмента. Это поломает сайт.
Смерджить базы, ничего не сломав, — задача нетривиальная и до сих пор нерешенная. Как говорится, если от болезни существует множество разных способов лечения, значит, она неизлечима. Я допускаю, что гиганты вроде Acquia имеют проприетарные решения, которые работают, но они ими с сообществом не поделятся, потому что это их конкурентное преимущество.
Когда я сидел на Drupal 6, я для этой задачи более или менее успешно использовал dbscripts. Проект умер, к большому сожалению, но вполне закономерно. Умер и Deploy, который вы рекомендуете, причем даже раньше, чем dbscripts, хотя успел родить сырую альфу для Drupal 7, которой я бы не рискнул пользоваться. Подобных проектов я видел много, но ни один не дорос до рабочего релиза, так что я считаю этот путь тупиковым. Уверен, со мной согласится любой разработчик, знающий значение термина «миграция».
Features — тоже не выход, потому что вы никогда не сможете нормально задеплоить с их помощью фичи реального сайта. Половина модулей не поддерживает Features или поддерживает криво или не полностью. Прошли годы, а воз и ныне там. Да и «деплоем» это назвать язык не поворачивается, потому что этот путь сопряжен с большим количеством геморроя. Выше писали, что изначально Features задумывались для другой цели, но сообщество вынуждено пытаться их использовать за неимением ничего лучше.
Про идею импорта фич руками я промолчу.
Что остается? Только ждать Drupal 8, на который вы не сможете смигрировать ни один ваш сайт. Но я уже достаточно нахлебался проблем с Drupal, чтобы потерять всякий энтузиазм и интерес.
Вы можете использовать мощьный «низкоуровневый» фреймворк, но чтобы написать хоть сколько нибудь похожую CMS вам потребуются годы.
Чтобы создать подобный Drupal конструктор — да. Чтобы создать проект, аналогичный по функционалу сайту, собранному на Drupal, потребуется столько же или меньше времени, чем на Drupal (если, конечно, речь идет о более или менее сложных сайтах вроде сабжа, а не сайтах-визитках с самым типовым функционалом). При этом поддержка и развитие такого проекта будут гораздо проще и эффективнее, чем на Drupal.
Features — тоже не выход, потому что вы никогда не сможете нормально задеплоить с их помощью фичи реального сайта. Половина модулей не поддерживает Features или поддерживает криво или не полностью.
Вы какие то странные вещи расказываете про Features. Можете назвать хотя бы несколько модулей из этой половины?
Это ваше единственное возражение по моему комменту? :)
Хотел в ответ на ваш вопрос дать ссылку на поиск по открытым Issues всех модулей, содержащим «features support» в заголовке, однако Drupal.org от этого падает в пресловутый WSOD.
Хотел в ответ на ваш вопрос дать ссылку на поиск по открытым Issues всех модулей, содержащим «features support» в заголовке, однако Drupal.org от этого падает в пресловутый WSOD.
Это ваше единственное возражение по моему комменту? :)Это не возражение. Просто интересно стало. На стольких разных проектах делали деплой фичами и не знали, что половина модулей их не поддерживает. У Features если другие проблемы, но вы ни одну их них не назвали.
Мой тезис был в том, что Drupal — это самая функциональная и гибкая CMS в мире, причем вся гибкость доступна в GUI, без написания строчки кода (впрочем, чтобы ей в полной мере воспользоваться, нужно изрядно поднатореть во владении Linux).
Однако это годится только для более или менее скромных типовых сайтов. Как только у вас возникнут потребности, выходящие за рамки штатных возможностей модулей, вы оказываетесь в заднице вроде описанной в сабже.
Drupal позиционирует себя как CMF, однако в этой роли это полный шлак. Сами авторы в этом расписались, приняв решение мигрировать на Symfony.
Вкладывать усилия в освоение разработки модулей на Drupal считаю совершенно неоправданным. Можно потратить то же количество времени и стать полноценным вэб-разработчиком на языке, за который не стыдно, и перспективном фреймворке. А не починяетелм примусов в вэб-студии, занимающей нишу бюджетных сайтов.
Люди, которые посвящают свою жизнь разработке на Drupal, словно надевают шоры, закрываясь от современных практик и методик вэб-разработки.
Однако это годится только для более или менее скромных типовых сайтов. Как только у вас возникнут потребности, выходящие за рамки штатных возможностей модулей, вы оказываетесь в заднице вроде описанной в сабже.
Drupal позиционирует себя как CMF, однако в этой роли это полный шлак. Сами авторы в этом расписались, приняв решение мигрировать на Symfony.
Вкладывать усилия в освоение разработки модулей на Drupal считаю совершенно неоправданным. Можно потратить то же количество времени и стать полноценным вэб-разработчиком на языке, за который не стыдно, и перспективном фреймворке. А не починяетелм примусов в вэб-студии, занимающей нишу бюджетных сайтов.
Люди, которые посвящают свою жизнь разработке на Drupal, словно надевают шоры, закрываясь от современных практик и методик вэб-разработки.
Drupal позиционирует себя как CMF, однако в этой роли это полный шлак. Сами авторы в этом расписались, приняв решение мигрировать на Symfony.А как по английски будет «Друпал полный шлак»? Лень всю статью читать. )
А как по английски будет «Друпал полный шлак»? Лень всю статью читать. )
Я лучше приведу вам кое-что по-русски:
расписа́ться
2. перен. своими поступками, поведением с полной очевидностью обнаружить, подтвердить что-либо в отношении себя
Вот кстати список проектов которые «расписались».
symfony.com/projects
symfony.com/projects
Drupal много (очень много, по меркам компьютерных технологий) развивал собственную архитектуру. Эта архитектура себя изжила, завела сообщество в тупик. Дрис по ссылке называет некоторые проблемы, правда, далеко не все и не в таких красках, как это делают люди, нахлебавшиеся Drupal по горло.
По этой причине, авторы Drupal приняли волевое решение пойти радикально другим путем. У индейцев Дакота есть такая поговорка: «Если ты понял, что едешь на мертвой лошади, лучшей тактикой будет слезть с нее». Вот это как раз тот случай. У Дриса сотоварищи хватило духу слезть с мертвой лошади архитектуры Drupal.
Заметьте, я ничего не говорю о том, что получится из сборной солянки Symfony, Zend, Backbone и наследия Drupal. Очень хочется посмеяться над этим в духе «Можно из буханки хлеба, китайских палочек и колпачков от зубной пасты сделать троллейбус. Но зачем?» Но не буду, сначала посмотрим, что у них получится.
По этой причине, авторы Drupal приняли волевое решение пойти радикально другим путем. У индейцев Дакота есть такая поговорка: «Если ты понял, что едешь на мертвой лошади, лучшей тактикой будет слезть с нее». Вот это как раз тот случай. У Дриса сотоварищи хватило духу слезть с мертвой лошади архитектуры Drupal.
Заметьте, я ничего не говорю о том, что получится из сборной солянки Symfony, Zend, Backbone и наследия Drupal. Очень хочется посмеяться над этим в духе «Можно из буханки хлеба, китайских палочек и колпачков от зубной пасты сделать троллейбус. Но зачем?» Но не буду, сначала посмотрим, что у них получится.
интеграция (не «миграция»!) с некоторыми компонентами Symfony2
Не знаю как вы, а я слово «миграция» в комментариях к этой статье употреблял только в этом значении.
Только ждать Drupal 8, на который вы не сможете смигрировать ни один ваш сайт.Глупый вопрос. А почему не сможем? )
Давайте пойдем от обратного. Когда выйдет Drupal 8, вы напишете статью на Хабр о том, как смигрировали на него один из ваших флагманских проектов на Drupal 7 или 6?
А что там такого страшного то? Прям интрига какая то. )
Страшно то, что одна половина модулей вообще недоступна для новой версии Drupal, а другая, которая доступна, не имеет (или имеет неполноценные) инструменты миграции.
В результате проще переделать сайт с нуля на новой версии Drupal, чем мигрировать существующий. А еще проще держать его на той версии, на которой он сделан (к примеру, Флибуста с Либрусеком закономерно сидят на шестой версии).
Так было с 5 -> 6 и с 6 -> 7, и движение D7CX никак делу не помогло. Я не верю, что с 7 -> 8 ситуация изменится в лучшую сторону, с учетом столь кардинальных переработок.
В результате проще переделать сайт с нуля на новой версии Drupal, чем мигрировать существующий. А еще проще держать его на той версии, на которой он сделан (к примеру, Флибуста с Либрусеком закономерно сидят на шестой версии).
Так было с 5 -> 6 и с 6 -> 7, и движение D7CX никак делу не помогло. Я не верю, что с 7 -> 8 ситуация изменится в лучшую сторону, с учетом столь кардинальных переработок.
А ну это не страшно. Я думал будут проблемы с миграцией данных. Конечно, нет смысла переводить сайт на новую мажорную версию, если не планируется координально менять функционал. По поводу D7CX, так и ведь никто не заставляет делать upgrade сразу как только появится релиз. После выхода 7-ки многие студии еще целый год делали сайты на 6-ке, что бы не тратить время на исправление багов в сырых модулях или на самостоятельное портирование их. Потом плавно перешли на D7. Так сказать на готовенькое. )
Работал с друпалом, сейчас работаю с рельсами. Не вижу ничего ужасного ни в том, ни в другом, у каждого свои задачи. Быстро сделать мощный рабочий сайт на друпале значительно проще, чем на любом из фреймворков. Что может понятнее, чем реализовать основной функционал на вьюсе и на других стандартных модулях, а потом, при необходимости, «врезаться» на любой этап билда страницы своим модулем? Я уж не говорю о таких вещах как кастомные поля для чего угодно, внятной документации по API, том же кэшировании или о готовых модулях для интеграции с внешними сервисами типа Apache Solr.
Фреймворки же, позволяют значительно проще решать простой, но ооочень нестандартный функционал, с учетом того что стандартный сложный функционал не понадобится вообще. Rails мне в этом плане очень нравится, кода мало, сам он красивый и аккуратный.
По вопросу метафоры об автобусе и личном авто… Выступаю за развитие общественного транспорта, хватит атмосферу засорять=) Легковой транспорт только для спецслужб!
Фреймворки же, позволяют значительно проще решать простой, но ооочень нестандартный функционал, с учетом того что стандартный сложный функционал не понадобится вообще. Rails мне в этом плане очень нравится, кода мало, сам он красивый и аккуратный.
По вопросу метафоры об автобусе и личном авто… Выступаю за развитие общественного транспорта, хватит атмосферу засорять=) Легковой транспорт только для спецслужб!
Про проблемы с циклом разработки я более подробно написал тут.
Если вы знаете элегантное решение этой проблемы, будьте добры, опишите кратко в ответе на тот коммент, а потом опубликуйте на Хабре статью об этом.
Про
Если вы знаете элегантное решение этой проблемы, будьте добры, опишите кратко в ответе на тот коммент, а потом опубликуйте на Хабре статью об этом.
Про
node_load не понял.
Вы тут столько много написали, вставлю свои две копейки. Отсутствие внятного цикла как вы утверждаете dev -> staging -> production давно уже решенная проблема, на таких профессиональных хостингах как Acquia, Blackmesh, Pantheon, всю «мороку» свели до нажатия двух — трех кнопок.
Вы пишете что не понимаете людей которые упорно сидят на друпал? Забавно, наверное в таких компаниях как Time сидят полные дибилы :). Обьясню популярно — большой компании наплевать на чем написанна их publishing system, большая компания хочет чтоб цена разработки была минимальной при максимальной отдаче. На сегодняшний день, Drupal в смыесле cost-to-benefit ratio выигрывает у всех вами перечеислиных связок.
Единственное в чем могу с вами согласится так это в том что это автобус, ездяший по одному маршруту. Друпал решает вполне конкретный, ограниченный набор задач.
И деийствительно, если вам надо решить задачу под которую друпал не заточен, то вам придется поискать инструмент который подходит под вашу задачу. Вот и все.
Вы пишете что не понимаете людей которые упорно сидят на друпал? Забавно, наверное в таких компаниях как Time сидят полные дибилы :). Обьясню популярно — большой компании наплевать на чем написанна их publishing system, большая компания хочет чтоб цена разработки была минимальной при максимальной отдаче. На сегодняшний день, Drupal в смыесле cost-to-benefit ratio выигрывает у всех вами перечеислиных связок.
Единственное в чем могу с вами согласится так это в том что это автобус, ездяший по одному маршруту. Друпал решает вполне конкретный, ограниченный набор задач.
И деийствительно, если вам надо решить задачу под которую друпал не заточен, то вам придется поискать инструмент который подходит под вашу задачу. Вот и все.
Отсутствие внятного цикла как вы утверждаете dev -> staging -> production давно уже решенная проблема, на таких профессиональных хостингах как Acquia, Blackmesh, Pantheon, всю «мороку» свели до нажатия двух — трех кнопок.
На это я уже отвечал.
Забавно, наверное в таких компаниях как Time сидят полные дибилы :). Обьясню популярно — большой компании наплевать на чем написанна их publishing system, большая компания хочет чтоб цена разработки была минимальной при максимальной отдаче.
Во-первых, Time.com сделан на Wordpress. Во-вторых, «такие компании как Time» не разрабатывают сайты самостоятельно. Они обращаются к другим компаниям, вэб-разработчикам.
А вот о чем думают эти компании-разработчики — как раз вопрос.
Насчет того, что Drupal — самое эффективное решение с точки зрения временных затрат, я категорически не согласен. Собственно, сабж и является наглядным примером того, как Drupal из коробки непригоден к использованию на не самых тривиальных проектах и требует плясок с бубном. И чем серьезнее проект, тем больше приходится плясать.
Я не считаю людей, выбирающих Drupal, дебилами, но не понимаю, как можно добровольно на это идти.
Кстати, хороший прирост к производительности даёт перенос полей в одну, но СВОЮ таблицу.
Любые поля прекрасно интегрируются с вьюсами на ура.
PS. Писал про это тут: habrahabr.ru/sandbox/74002
Любые поля прекрасно интегрируются с вьюсами на ура.
PS. Писал про это тут: habrahabr.ru/sandbox/74002
Пытались настроить выборку через промежуточную таблицу — через модуль shadow. Там используется похожая схема. Однако не нашли, как добавить в таблицу больше трех полей.
А в целом — да, это неплохой вариант, мы о нем всерьез задумывались.
А в целом — да, это неплохой вариант, мы о нем всерьез задумывались.
drupal.org/project/pbs не пробовали? Синтетика синтетикой, а у вас и количество полей и контент.
Интересны результаты
Интересны результаты
Да, спасибо за ссылку на статью — весьма полезно.
Не лучше ли для сайта магазина использовать e-commerce движки? :)
Наверное лучше :)
drupal commerce довольно крупный набор модулей для электронной коммерции, покрывающий почти все требования которые могут возникнуть у компании заказывающей интернет-магазин. Идеология drupal и глубокая интеграция в него, делает его невероятно гибким инструментом. Такой гибкости в e-commerce движках не встречал.
Как по мне то странно смотреть SQL запросы в самом конце… кэширование это конечно хорошо, но не проще сразу посмотреть Explain SQL запроса и оптимизировать его. Или это в Drupal считается плохим тоном? Я просто его ни когда не использовал.
в том числе непонятный deleted, который, по нашему опыту, всегда равен нулю
Как вы вообще работаете с Drupal???!!! Читайте FieldApi, господа! А если у вас, неопытный менеджер возьмет и удалит одно из полей???
Да, Друпал сложный в изучении, но поэтому прежде чем с ним начать работать эффективно, нужно очень много всего изучить, очень много.
Еще есть бандлы.
За статью спасибо! Наверное такие материалы и переубеждают меня начать изучать друпал. Ни в коем случае не осуждаю ваш выбор, просто сам разрабатываю на yii где можно легко собрать и магазин и блог и сайт и что угодно из готовых extension но периодически что-то клинит и хочется начать изучать друпал или джумалу. Но читаю такие материалы и успокаиваюсь )))
Специально залогинился, чтобы плюсануть и рассказать как это делали мы в своём проекте.
Поля в нодах — это очень медленно, потому что ноды — для контента. Вам нужно было использовать entity. Своя entity пишется за 1-2 часа. Преимущества:
Чего вы не получите, если используете entity — форма редактирования и страницу просмотра. Их нужно будет сделать самостоятельно, но тут уж нужно выбирать — или удобство редактирования ноды, или производительность. Ноды, как вы сами писали универсальны и медленная работа с большим количеством полей — это плата за эту самую универсальность.
Мой совет — советуйтесь с друпалерами. Есть куча друпал-скайп-чатов, где можно задать вопросы и не изобретать велосипед.
Обращайтесь!
Всем читать drupal.org/node/2034119, чтобы подобных грустных статей было меньше.
P.S. Да и про поиск выше — верно написали. Используйте ApacheSolr или аналоги и будет вам счастье. Стандартный поиск очень простой и для сложных вещей не годится.
Поля в нодах — это очень медленно, потому что ноды — для контента. Вам нужно было использовать entity. Своя entity пишется за 1-2 часа. Преимущества:
- все данные в одной таблице, что исключает JOINы, которые, как известно, очень медленные.
- Интеграция с views, token, rules и пр. из коробки.
- При желании можно выводить свои кастомные таблицы со сложными фильтрами, если views не устраивает.
Чего вы не получите, если используете entity — форма редактирования и страницу просмотра. Их нужно будет сделать самостоятельно, но тут уж нужно выбирать — или удобство редактирования ноды, или производительность. Ноды, как вы сами писали универсальны и медленная работа с большим количеством полей — это плата за эту самую универсальность.
Мой совет — советуйтесь с друпалерами. Есть куча друпал-скайп-чатов, где можно задать вопросы и не изобретать велосипед.
Обращайтесь!
Всем читать drupal.org/node/2034119, чтобы подобных грустных статей было меньше.
P.S. Да и про поиск выше — верно написали. Используйте ApacheSolr или аналоги и будет вам счастье. Стандартный поиск очень простой и для сложных вещей не годится.
Тут поддержу Влада Савицкого, Вы решили сделать анитипатерн магазина и я счастлив, что у Вас получилось.
1. Хорошо, что не стали с нуля писать свою CMS, а взяли Drupal Commerce — проект в который вложено 15 млн. $ с кучей модулей из коробки и огромной россыпью в репозитарии. Плохо, что скорее всего вы половину модулей не выключили (если они Вам не нужны), не взяли более лёгкий дистрибутив Drupalife Store.
2. Если пользуете Российский хостинг, то вторые грабли тормознутость HDD, DigitalOcean или подобный хостинг с SSD это ускорение на 1000% (модулей много читаются они долго).
3. PHP 5.5 c OPcach именно только так и никаких других акселераторов — прирост скорости в несколько раз в отличие от голого PHP 5.3 (а если он с APC то там акселерация начинает борется с недостатком памяти сервера — но так уж работает именно APC).
4. SOLR — отказ от него вторые крупные грабли так как он именно для этого предназначен. После этого следует что Вы строите свой HighLoad.
5. Своя entity — всё в одной таблице, что исключает JOINы (внимание нужно только для HighLoad и только когда без этого нельзя обойтись). Третьи грабли на которые Вы наступили. Но не нужно писать entity для каждого материала, только для тех, чьи поля постоянно используете. У магазина — поиск это обычно до 70% просмотренных страниц, у тематических сайтов обратное.
6. Есть модуль Database logging — если не всё хорошо с верстальщиками и т.п. может генерировать большой объём лога об ошибках в базу данных, база от этого тоже начинает тормозить переваривая большой insert перед показом каждой страницы. Поэтому нужно или исправить все ошибки, что падают в лог или отключить модуль. Правда об подозрительных дествиях на сайте Вы перестаёте быть настолько осведомлены после отключения модуля.
7. Ладно раз используете поля для тяжёлых выборок, то если не используете ревизии нод, то поставьте Field SQL norevisions — пусть база будет меньше, а диску легче (внимание нужно только для HighLoad и только когда без этого нельзя обойтись).
8. Entity cache + Memcache API and Integration или Redis и пусть Ваш кэш материалов живёт в памяти сервера а не на диске. А для магазинов ещё и commerce_entitycache обязателен.
9. Подключение модуля memcached для кэша всего остального в памяти это правильно.
10. Про cache_form хорошо Spleshka написал в статье: «Система кэширования Drupal 7. Часть первая: сегменты кэша», там всё от и до от того как и заканчивая зачем.
11. Просматривайте чего генерит views (у него на странице со списком представлений есть вкладка настройка и там галочка — показывать SQL), иногда то, что накидают через UI (например 500 связанных полей (реальный пример)) генерит не реальный JOIN.
Самое главное — спрашивайте. Про оптимизацию Drupal 6 я ешё в 2009 году писал, про оптимизацию Drupal 7 Spleshka (например: drupalace.ru/lesson/otdayom-kesh-anonimov-bez-podnyatiya-bekenda-drupal-7-nginx-memcached). К его статьям мне и добавить то нечего. Если есть вопросы по HighLoad, я всегда отвечу тут: www.drupal.ru/username/irbis
1. Хорошо, что не стали с нуля писать свою CMS, а взяли Drupal Commerce — проект в который вложено 15 млн. $ с кучей модулей из коробки и огромной россыпью в репозитарии. Плохо, что скорее всего вы половину модулей не выключили (если они Вам не нужны), не взяли более лёгкий дистрибутив Drupalife Store.
2. Если пользуете Российский хостинг, то вторые грабли тормознутость HDD, DigitalOcean или подобный хостинг с SSD это ускорение на 1000% (модулей много читаются они долго).
3. PHP 5.5 c OPcach именно только так и никаких других акселераторов — прирост скорости в несколько раз в отличие от голого PHP 5.3 (а если он с APC то там акселерация начинает борется с недостатком памяти сервера — но так уж работает именно APC).
4. SOLR — отказ от него вторые крупные грабли так как он именно для этого предназначен. После этого следует что Вы строите свой HighLoad.
5. Своя entity — всё в одной таблице, что исключает JOINы (внимание нужно только для HighLoad и только когда без этого нельзя обойтись). Третьи грабли на которые Вы наступили. Но не нужно писать entity для каждого материала, только для тех, чьи поля постоянно используете. У магазина — поиск это обычно до 70% просмотренных страниц, у тематических сайтов обратное.
6. Есть модуль Database logging — если не всё хорошо с верстальщиками и т.п. может генерировать большой объём лога об ошибках в базу данных, база от этого тоже начинает тормозить переваривая большой insert перед показом каждой страницы. Поэтому нужно или исправить все ошибки, что падают в лог или отключить модуль. Правда об подозрительных дествиях на сайте Вы перестаёте быть настолько осведомлены после отключения модуля.
7. Ладно раз используете поля для тяжёлых выборок, то если не используете ревизии нод, то поставьте Field SQL norevisions — пусть база будет меньше, а диску легче (внимание нужно только для HighLoad и только когда без этого нельзя обойтись).
8. Entity cache + Memcache API and Integration или Redis и пусть Ваш кэш материалов живёт в памяти сервера а не на диске. А для магазинов ещё и commerce_entitycache обязателен.
9. Подключение модуля memcached для кэша всего остального в памяти это правильно.
10. Про cache_form хорошо Spleshka написал в статье: «Система кэширования Drupal 7. Часть первая: сегменты кэша», там всё от и до от того как и заканчивая зачем.
11. Просматривайте чего генерит views (у него на странице со списком представлений есть вкладка настройка и там галочка — показывать SQL), иногда то, что накидают через UI (например 500 связанных полей (реальный пример)) генерит не реальный JOIN.
Самое главное — спрашивайте. Про оптимизацию Drupal 6 я ешё в 2009 году писал, про оптимизацию Drupal 7 Spleshka (например: drupalace.ru/lesson/otdayom-kesh-anonimov-bez-podnyatiya-bekenda-drupal-7-nginx-memcached). К его статьям мне и добавить то нечего. Если есть вопросы по HighLoad, я всегда отвечу тут: www.drupal.ru/username/irbis
а если он с APC то там акселерация начинает борется с недостатком памяти сервера — но так уж работает именно APCНе понял.
ЗЫ У нас PHP 5.3 + APC + соответствующий модуль для друпала — вроде, работает. Для выдачи 99 процентов материалов из кэша пришлось выделить 800 МБ — и стало хорошо.
Если модулей очень много, то с APC есть тарбл что опкод страницы начинает подходить под 150 мегабайт, который долго грузится с HDD в память, особенно если это многострадальный HDD замученный раздачей картинок заодно. Это очень много, ещё на 5.3 стал использовать вместо APC — eAccelerator. PHP 5.5 c OPcach и быстрее и памяти меньше ест.
У меня вопрос, касательно сути того, что вы делаете, а не выбранного инструмента.
Понятно, что с 185 полями свойств объекта и тысячами объектов все может основательно подтормаживать. И это еще не учитывает, что при росте масштаба все будет только хуже и владельцу магазина придется переделывать заново весь магазин. Посмотрите как сделан выбор принтера у яндекса.
Выбор сначала по ключевым 3-м параметрам (Цена, Тип устройства, тип:
market.yandex.ru/catalogmodels.xml?CAT_ID=1016608&hid=138608
удовлетворяет 80% людей, которые ищут или приобретают принтер.
Если мало — Расширенный поиск
market.yandex.ru/guru.xml?CMD=-RR%3D9%2C0%2C0%2C0-VIS%3D8070-CAT_ID%3D1016608-EXC%3D1-PG%3D10&hid=138608
И бренд и формат и WiFi
удовлетворяет еще 14% твоих пользователей
Мало? Все параметры
market.yandex.ru/guru.xml?CMD=-RR%3D9%2C0%2C0%2C0-VIS%3D8070-CAT_ID%3D1016608-EXF%3D1-EXC%3D1-PG%3D10&hid=138608
оставшиеся 6% людей (выбирающих принтер по ресурсу девелопера, или кто ищет обязательно PC FAX) тоже удовлетворены.
Экономия на ресурсах просто ошеломительная.
Вы еще сделайте возможность выборки по базе только при условии 100% заполнения всех полей. Чтобы ваш пользователь потратил кучу своего времени и вышел спецом по существующим принтерам :)
Понятно, что с 185 полями свойств объекта и тысячами объектов все может основательно подтормаживать. И это еще не учитывает, что при росте масштаба все будет только хуже и владельцу магазина придется переделывать заново весь магазин. Посмотрите как сделан выбор принтера у яндекса.
Выбор сначала по ключевым 3-м параметрам (Цена, Тип устройства, тип:
market.yandex.ru/catalogmodels.xml?CAT_ID=1016608&hid=138608
удовлетворяет 80% людей, которые ищут или приобретают принтер.
Если мало — Расширенный поиск
market.yandex.ru/guru.xml?CMD=-RR%3D9%2C0%2C0%2C0-VIS%3D8070-CAT_ID%3D1016608-EXC%3D1-PG%3D10&hid=138608
И бренд и формат и WiFi
удовлетворяет еще 14% твоих пользователей
Мало? Все параметры
market.yandex.ru/guru.xml?CMD=-RR%3D9%2C0%2C0%2C0-VIS%3D8070-CAT_ID%3D1016608-EXF%3D1-EXC%3D1-PG%3D10&hid=138608
оставшиеся 6% людей (выбирающих принтер по ресурсу девелопера, или кто ищет обязательно PC FAX) тоже удовлетворены.
Экономия на ресурсах просто ошеломительная.
Вы еще сделайте возможность выборки по базе только при условии 100% заполнения всех полей. Чтобы ваш пользователь потратил кучу своего времени и вышел спецом по существующим принтерам :)
А все поля с характеристиками принтера вы хранили в commerce product или в node display? Есть ли существенная разница )? И если есть, то где правильно хранить поля-характеристики товара?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы ускоряли Drupal Commerce