Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 288
Спасибо, основательно. Ждем следующей статьи.
за что спасибо? Статья это бред ни о чем. Какие тысячи багов, какие пережитки с Друпал 5?
>>Drupal 6 — это пик развития Drupal
У меня вопрос к автору, а писали модули для друпал 5 и друпал 6 и друпал 7 и делали сайты на этих версиях? Критичные статьи будут всегда, но не стоит паниковать на любой шорох.
>>Drupal 6 — это пик развития Drupal
У меня вопрос к автору, а писали модули для друпал 5 и друпал 6 и друпал 7 и делали сайты на этих версиях? Критичные статьи будут всегда, но не стоит паниковать на любой шорох.
С 5ой версией не работал. Будьте внимательны, о багах и пережитках пишет разработчик в первоисточнике.
Ну судя по тому что будет в Drupal 8, то еще не все потеряно.
В нем будет порядка 4000 багов, не понимаю на что вы надеятесь
4000 багов- это гражданин вообще не понял как работает багтрекер на drupal.org
Идем в самый центр кошмара drupal.org/project/drupal и о ужас! Видим 4682 открытых бага!
Одни после получения этого кошмарного знания бросаются писать статьи, другие же нажимают на циферку багов и попадают сюда drupal.org/project/issues/drupal?categories=bug где даже поверхностный взгляд неофита позволяет понять, что это общий багтрекер для вообще всех версий друпала начиная с 4-й.
Простейшие манипуляции с фильтром в заголовке страницы позволяют глубже погрузиться в кошмарность ситуации:
Для текущей версии друпал 7.15: drupal.org/project/issues/drupal?text=&status=Open&priorities=All&categories=bug&version=1708292&component=All
17 багов! Это вообще отрапортованных, не факт что все они верны.
Для текущей версии друпал 6.26 drupal.org/project/issues/drupal?text=&status=Open&priorities=All&categories=bug&version=1558054&component=All
11 багов!
Просто кошмар какая жопа накрыла друпал! Воистину, последние дни грядут!
Идем в самый центр кошмара drupal.org/project/drupal и о ужас! Видим 4682 открытых бага!
Одни после получения этого кошмарного знания бросаются писать статьи, другие же нажимают на циферку багов и попадают сюда drupal.org/project/issues/drupal?categories=bug где даже поверхностный взгляд неофита позволяет понять, что это общий багтрекер для вообще всех версий друпала начиная с 4-й.
Простейшие манипуляции с фильтром в заголовке страницы позволяют глубже погрузиться в кошмарность ситуации:
Для текущей версии друпал 7.15: drupal.org/project/issues/drupal?text=&status=Open&priorities=All&categories=bug&version=1708292&component=All
17 багов! Это вообще отрапортованных, не факт что все они верны.
Для текущей версии друпал 6.26 drupal.org/project/issues/drupal?text=&status=Open&priorities=All&categories=bug&version=1558054&component=All
11 багов!
Просто кошмар какая жопа накрыла друпал! Воистину, последние дни грядут!
Речь о гражданине Daniel F. Kudwien
После комментария Delirium дальше можно не читать. Автор посрамлён в цифрах выше. Ниже ничего умнее не будет. Спасибо Delirium.
Хотелось бы уточнить для себя, — а незакрытые баги предыдущих версий текущей ветки куда-то испаряются с новым релизом? Т.е. всё что незакрытым висит в багтрекере Drupal 7.14 уже исправлено в 7.15?
Просто интересно как тут у вас багтрекер устроен :)
Просто интересно как тут у вас багтрекер устроен :)
А в версии 6.23 всего два бага. Видимо, нужно ей пользоваться?
То, что баг добавили для какой-то версии, не означает автоматически, что его нет в других версиях.
Конечно среди этих 8000 есть некорректная информация, но тем не менее ваши ссылки и аргументация не до конца верны.
То, что баг добавили для какой-то версии, не означает автоматически, что его нет в других версиях.
Конечно среди этих 8000 есть некорректная информация, но тем не менее ваши ссылки и аргументация не до конца верны.
Да нет, это просто вы ерунду написали в ответ.
Цифра 11 и 17 такое же вранье, как 8000
Обоснуйте.
Только не нужно рассказывать про сотни багов, которые коварно таятся внутри стабильных версий, но их просто еще никто не нашел.
Только не нужно рассказывать про сотни багов, которые коварно таятся внутри стабильных версий, но их просто еще никто не нашел.
При добавлении бага указывается, на какой версии он встретился.
Фильтр показывает, сколько багов добавлено с указанием номера выбранной версии.
Вышла новая минорная версия, в ней нашли другие баги, добавили.
Старые не переносятся в новую.
Фильтр показывает, сколько багов добавлено с указанием номера выбранной версии.
Вышла новая минорная версия, в ней нашли другие баги, добавили.
Старые не переносятся в новую.
Замечательно. Это верно.
Но, во-первых, с некоторой вероятностью в свежей версии этого бага уже нет, во-вторых, «баги» зарегистрированные как таковые могут вообще багами не являться, ведь добавлять их может любой зарегистрированный на друпал.орг пользователь.
Поэтому тут как ни крути идет игра в цифры и можно настоящими багами считать например только подтвержденные тикеты, со статусом «needs work».
Но, во-первых, с некоторой вероятностью в свежей версии этого бага уже нет, во-вторых, «баги» зарегистрированные как таковые могут вообще багами не являться, ведь добавлять их может любой зарегистрированный на друпал.орг пользователь.
Поэтому тут как ни крути идет игра в цифры и можно настоящими багами считать например только подтвержденные тикеты, со статусом «needs work».
Да. Все так. :)
Допустим такую ситуацию:
1. Я нашел баг в 7.10 (допустим)
2. Зарепортил его для 7.10
3. Вышла версия 7.11, баг для 7.10 все еще висит как необработанный(или как там у вас оно называется)
4. Применяем фильтры для 7.11 — и о чудо, этого бага там нет!
А его пофиксили-то? Отнюдь.
Так что, пожалуйста, не доказывайте с пеной у рта что багов там нет, они никуда не девались. Их конечно не 4к+, но и не так мало как Вы указали.
Искренне надеюсь что когда-нибудь разработчики друпала все-таки образумятся, соберутся с силами и сообществом и сделают рефакторинг ядра, оптимизируют все что можно и наконец-то друпал станет идеальным инструментом.
1. Я нашел баг в 7.10 (допустим)
2. Зарепортил его для 7.10
3. Вышла версия 7.11, баг для 7.10 все еще висит как необработанный(или как там у вас оно называется)
4. Применяем фильтры для 7.11 — и о чудо, этого бага там нет!
А его пофиксили-то? Отнюдь.
Так что, пожалуйста, не доказывайте с пеной у рта что багов там нет, они никуда не девались. Их конечно не 4к+, но и не так мало как Вы указали.
Искренне надеюсь что когда-нибудь разработчики друпала все-таки образумятся, соберутся с силами и сообществом и сделают рефакторинг ядра, оптимизируют все что можно и наконец-то друпал станет идеальным инструментом.
Ну вы не стесняйтесь.
С пеной у рта отправляйтесь по вышеприведенным ссылкам и посчитайте кол-во багов для 7-й версии, не считая -dev ветки.
Откройте уже глаза общественности.
С пеной у рта отправляйтесь по вышеприведенным ссылкам и посчитайте кол-во багов для 7-й версии, не считая -dev ветки.
Откройте уже глаза общественности.
А что ее открывать? Надо смотреть не по отдельным минорным версиям 7.15, 7.16 и т.п., а по всей ветке 7.x
В трекере, я так понимаю, это фильтр 7.x issues:
drupal.org/project/issues/drupal?text=&status=Open&priorities=All&categories=bug&version=7.x&component=All
30 страниц багов. Некоторым багам — по 4-5 лет, и они до сих пор со статусом active
А в остальном, прекрасная маркиза, все хорошо, все хорошо
В трекере, я так понимаю, это фильтр 7.x issues:
drupal.org/project/issues/drupal?text=&status=Open&priorities=All&categories=bug&version=7.x&component=All
30 страниц багов. Некоторым багам — по 4-5 лет, и они до сих пор со статусом active
А в остальном, прекрасная маркиза, все хорошо, все хорошо
Когда-то решил использовать друпал, жутко тормозил у моего хостера, спросил совета у русскоязычного сообщества друпала и получил почти единогласный ответ — «твой хост говно, юзай нормальный хост», среди тонны таких неадекватных комментов был совет глянуть на запросы к бд. Тем временем поставил на локальный хост этот же друпал — ситуация не изменилась, проблемы те же что и на реальном хостинге — over 50 запросов к бд для отрисовки одной стат.страницы, около десяти запросов идут по 2-3 секунды. Это, имхо, ненормально.
И вот как не имея мазохистических наклонностей использовать друпал?
И вот как не имея мазохистических наклонностей использовать друпал?
Как я уже говорил, drupal обладает продвинутой системой кеширования, вы просто не знаете как ей пользоваться.
Жертвам же говнохостинга советую замечательный хостинг it-patrol.ru спецом заточенный под друпал и с вменяемыми ценами.
Жертвам же говнохостинга советую замечательный хостинг it-patrol.ru спецом заточенный под друпал и с вменяемыми ценами.
Все возможные советы по оптимизации и кэшированию прочитал и использовал. Не помогло.
Называть какой-либо хостинг говнохостингом только из-за того что один единственный друпал там виснет, это, знаете, странно. Скорее какая-то CMS имеет право называться говноцмской потому-что она даже со всеми возможными приблудами для кэширования работает хуже чем та же джумла «из коробки»
Называть какой-либо хостинг говнохостингом только из-за того что один единственный друпал там виснет, это, знаете, странно. Скорее какая-то CMS имеет право называться говноцмской потому-что она даже со всеми возможными приблудами для кэширования работает хуже чем та же джумла «из коробки»
У друпала есть вполне себе четко обозначенные минимальные требования к хостингу. То что на ваших хостингах работают сайты визитки, не говорит о том, что там будет работать друпал.
И да, большинство отечественных хостингов проходят именно по категории говно, потому что предлагают ресурсов как-будто на дворе начало 2000-х, за совершенно невменяемые деньги.
И да, большинство отечественных хостингов проходят именно по категории говно, потому что предлагают ресурсов как-будто на дворе начало 2000-х, за совершенно невменяемые деньги.
Кстати, раз вы знаете о работе друпала в достаточном объеме, не подскажите зачем ему такое количество запросов к бд?
Вы битрикс не использовали? Не? После битрикса друпал просто мегалайтcms.
А количество запросов напрямую зависит от количества модулей, и 50 запросов вполне нормально, плата за гибкость.
Но я бы всё же задумался, как могут простые запросы по ключу выполняться по 2-3 секунды?
Наверняка, БД-хост у хостера был на отдельном хосте (скороговорка то какая!), да ещё и как всегда просаженный. Русоникс? Мажордомо? Мастерхост?
А количество запросов напрямую зависит от количества модулей, и 50 запросов вполне нормально, плата за гибкость.
Но я бы всё же задумался, как могут простые запросы по ключу выполняться по 2-3 секунды?
Наверняка, БД-хост у хостера был на отдельном хосте (скороговорка то какая!), да ещё и как всегда просаженный. Русоникс? Мажордомо? Мастерхост?
Вы вполне можете удовлетворить свое любопытство самостоятельно.
Для начала, кеш друпала по умолчанию в БД, и он использует её как key-value хранилище, забирая оттуда различные значения очень простыми запросами. Если вам принципиально изменить этот момент, и вы почему-то зациклились на количестве запросов, используйте под кеш тот же memcached.
Хотя такое решение при нормальной настройке mysql, может быть и не производительнее.
Если у вас drupal 7 и таблицы в innodb, то вам надо innodb нормально настроить. Настройки innodb по умолчанию, мягко говоря не оптимальны. Об этом немало есть в сети, поинтересуйтесь.
Хотя такое решение при нормальной настройке mysql, может быть и не производительнее.
Если у вас drupal 7 и таблицы в innodb, то вам надо innodb нормально настроить. Настройки innodb по умолчанию, мягко говоря не оптимальны. Об этом немало есть в сети, поинтересуйтесь.
Легко, и без всякого мазахизма — запросов и 150 может быть, и 200. Если нет проблемы на хостинге с идиотским ограничением кол-ва запросов в единицу времени, это может работать весьма быстро, т.к. в большинстве запросы очень лёгкие.
Если вы умудрились наставить бездумно пачку модулей, и получить-таки действительно тяжёлые запросы, то тут надо пинять не на сам друпал, а на модули и собственную компетентность как разработчика, если вы не можете понять, откуда это берётся.
Ну и если хостер ограничивает-таки кол-во запросов в единицу времени, то от него надо бежать вне зависимости от CMS.
Если вы умудрились наставить бездумно пачку модулей, и получить-таки действительно тяжёлые запросы, то тут надо пинять не на сам друпал, а на модули и собственную компетентность как разработчика, если вы не можете понять, откуда это берётся.
Ну и если хостер ограничивает-таки кол-во запросов в единицу времени, то от него надо бежать вне зависимости от CMS.
Линк нужен еще
Печально. Хотя сам уже давно под Drupal не пишу, но как-то казалось (в основном по инфе с Хабра), что как раз идёт редизайн ядра, построение поддерживаемой ООП-архитектуры.
Блин, ну а вот что выбрать? Какую нормальную ЦМС с большим сообществом, кроме WP?
Drupal 6 вполне достойная вещь для своих задач. Хотя я перешел на CMF (rails)
Из минусов D6 разве что старый jQuery, но это, наверно, решается.
Из минусов D6 разве что старый jQuery, но это, наверно, решается.
В своё время у меня остро стоял этот вопрос — сейчас рад что выбрал Yii.
Если интересует что-то большее чем сайты-визитки- бери D7, не ошибешься.
Статья дурная, полна много лет как устаревшими сведениями.
Статья дурная, полна много лет как устаревшими сведениями.
Посмотри в сторону Joomla! CMS
Joomla 2.5 — текущая долгосрочная версия рассчитанная на длительность 18 месяцев.
Промежуточные версии до следующей долгосрочной Joomla 3.5 будут выходить каждые 6 месяцев с этим коротким сроком жизни.
Краткосрочная версия Joomla 3.0 уже выходит в конце сентября и будет иметь на борту обновленную Платформу Joomla, Twitter Bootstrap для интерфейса админки и фронта, полная на уровне ядра поддержка мобильных устройств.
Над Joomla 3.0 работает Кайл Ледбеттер (Kyle Ledbetter) — UI/UX дизайнер, руководитель команды JUX (Joomla Юзабилити) и инженер по эргономики компании Ebay.
Что касается сообщества и самой системы, то можете посмотреть на инфографику 6-ти летней истории и сделать выводы, что Joomla не так уж и плоха, как ее описывают: joomla-ua.org/news/portal/1764-infografika-6-richnoji-istoriji-joomla.
P.S.: Я понимаю, что сейчас мой ответ заминусуют, заплюют рьяные противники Joomla, но я дал ответ на поставленный вопрос, если кому не нравиться Joomla давайте не будем устраивать споры и делать перекрестные минусования.
Joomla 2.5 — текущая долгосрочная версия рассчитанная на длительность 18 месяцев.
Промежуточные версии до следующей долгосрочной Joomla 3.5 будут выходить каждые 6 месяцев с этим коротким сроком жизни.
Краткосрочная версия Joomla 3.0 уже выходит в конце сентября и будет иметь на борту обновленную Платформу Joomla, Twitter Bootstrap для интерфейса админки и фронта, полная на уровне ядра поддержка мобильных устройств.
Над Joomla 3.0 работает Кайл Ледбеттер (Kyle Ledbetter) — UI/UX дизайнер, руководитель команды JUX (Joomla Юзабилити) и инженер по эргономики компании Ebay.
Что касается сообщества и самой системы, то можете посмотреть на инфографику 6-ти летней истории и сделать выводы, что Joomla не так уж и плоха, как ее описывают: joomla-ua.org/news/portal/1764-infografika-6-richnoji-istoriji-joomla.
P.S.: Я понимаю, что сейчас мой ответ заминусуют, заплюют рьяные противники Joomla, но я дал ответ на поставленный вопрос, если кому не нравиться Joomla давайте не будем устраивать споры и делать перекрестные минусования.
Мне не нравится, когда пишут «нравиться» вместо «нравится».
Извини, сделал опечатку, но при чем тут твоя реплика?
Я хотел сказать, что не поклонник Joomla, минусовать за неё я полагаю ниже своего достоинства, а придраться же к чему-то надо. К тому же в комментарии ниже у Вас та же ошибка, так что я решил, что Вы не в курсе.
Когда в Joomla будет нормальный движок шаблонов, а не каша из PHP и HTML кода?
У них довольно не плохой MVC подход к шаблону. Если же не нравиться стандартное решение, то есть несколько фреймворков-движков для шаблонов, которые используются как в Joomla, Drupal, WP.
Я думаю, PHP сам по себе является отличным шаблонизатором. И если в шаблонах использовать только вывод информации то это решение будет гораздо более оптимальным, чем использование шаблонизаторов, которые в итоге все равно приводят все к «каше из PHP и HTML кода» и потом выводят.
У шаблонизаторов более лаконичный синтаксис, даже просто вывод (экранированный) переменной, сравните {{var}} и
Есть, конечно, ситуации, где использование шаблонизаторов неоправдано, но большинство проектов к ним, имхо, не относится.
<?=e($var)?> (в девичестве <?php echo htmlspecialchars($var, ENT_QUOTES, 'UTF-8') ?>), не говоря о, например, наследовании шаблонов (в нативных шаблонах это делается через перехват вывода посредством ob_*). Они дают меньше возможностей испортить (намеренно или случайно) работу приложения, да и сдерживают порывы внести в шаблон логику не относящуюся к логике приложения.Есть, конечно, ситуации, где использование шаблонизаторов неоправдано, но большинство проектов к ним, имхо, не относится.
Не хочется ее использовать до тех пор, пока у нее шаблоны через какую-то хитрую задницу закручены непонятным перемешиванием html и php
Каждый хвалит свое — поэтому советую MODX Revolution. Большое сообщество, много документации.
Полная свобода разработки и оформления сайта. В любой момент можете спустить на уровень чистого PHP и HTML, никто не помешает.
Давно работаю с MODX и ни разу не пожалел о своем выборе.
Может немного не в тему, но вот заметка об основных особенностях MODX Revolution, очень субъективная, конечно.
Полная свобода разработки и оформления сайта. В любой момент можете спустить на уровень чистого PHP и HTML, никто не помешает.
Давно работаю с MODX и ни разу не пожалел о своем выборе.
Может немного не в тему, но вот заметка об основных особенностях MODX Revolution, очень субъективная, конечно.
Странный и не удобный фреймворк в основе, которым по какой-то странной иронии так гордятся создатели. Хранение php кода в БД. Небольшое и довольно унылое сообщество, где всего несколько человек понимают, что они делают и как вообще работает ModX. И много других замечательных «особенностей». =) Но работать на этом можно, напильник только нужен большой.
CMS/CMF MODx 2 Revo!
DLE наше все -)
А вы меньше читайте истерических статей и меньше верьте на слово их авторам. =)
Всё так. Автор написал же "Данной статьей, я хотел предостеречь новчиков, которые стоят перед выбором: какую CMS/CMF использовать в качестве основного интрумента и посмотреть в сторону других решений", а вы, насколько я знаю, уважаемый земляк, таковым давно не являетесь :)
Довольно обоснованная статья, спасибо. Было интересно почитать.
Довольно обоснованная статья, спасибо. Было интересно почитать.
Процитирую с drupal.ru:
Правильно я на joomla перешел. Joomla эволюционирует в лучшую CMS, а Drupal так ничего нового и не привнес. Использование хуков и игнорирование возможностей ООП вместо прекрасно-подходящего для Web — MVC — это тупик.
Правильно я на joomla перешел. Joomla эволюционирует в лучшую CMS, а Drupal так ничего нового и не привнес. Использование хуков и игнорирование возможностей ООП вместо прекрасно-подходящего для Web — MVC — это тупик.
Жаль у джумлы не такое дружное сообщество. ИМХО друпал лидер по различным конференциям и стремлением разработчиков делиться информацией.
Я забыл поднять табличку Сарказм :)
Ну почему не дружное? Довольно таки и дружное.
Почти каждый месяц устраиваются Joomla! Day по всему миру (ближайшее будет проходить в Польше).
Очень развито русское сообщество и украинское тоже активно себя проявляет.
Если же не нравиться атмосфера официоза или не охота общаться с «буржуями» иногда можно побывать на неофициальных посиделках с бокалом пиво в русском или украинском сообществе :)
Почти каждый месяц устраиваются Joomla! Day по всему миру (ближайшее будет проходить в Польше).
Очень развито русское сообщество и украинское тоже активно себя проявляет.
Если же не нравиться атмосфера официоза или не охота общаться с «буржуями» иногда можно побывать на неофициальных посиделках с бокалом пиво в русском или украинском сообществе :)
Не надо цитировать жумловодов. Один жумловод, там же, на друпал.ру сказал следующее:
Drupal гораздо хуже Joomla, у него только модули, а у Joomla — модули, компоненты, плагины, мамботы
Drupal гораздо хуже Joomla, у него только модули, а у Joomla — модули, компоненты, плагины, мамботы
Если вы увидели слово «мамботы», то либо это было сообщение 4-5-летней давности, либо человек видел Joomla в последний раз как раз в этот период.
Заумные аргументы таковых вообще не стоит принимать во внимание. ИМХО этот джумлавод очень поверхностно знаком как с Joomla так и с Drupal. Тут дело даже не в самих модулях, а в терминологии. Модуль Drupal = любое Расширение Joomla (за исключением шаблонов, так как тема Drupal не является модулем). Мамбот?.. нет, не слышал. Это наверное из курса истории CMS.
Я с Joomla начинал, да и сейчас периодически возвращаюсь. И с Drupal тоже работал. Как не пинаться, но Drupal — не та система с которой нужно начинать. Я затрахался с ним еще на первых этапах. Однако Drupal добротнее Joomla в разы и это видно прямо по первым шагам.
Joomla — простаяговносистема система. Хороша в освоении, расширениях и сообщество сильное
Drupal — более гибкий и «сырой» чтоле… Отличная система для более профессиональной работы.
А дальше фреймворки будут :)
Joomla — простая
Drupal — более гибкий и «сырой» чтоле… Отличная система для более профессиональной работы.
А дальше фреймворки будут :)
Не понимаю вас.
как может «сырое» решение лучше «подходить для профессиональной работы»?
Joomla — простая система. Хороша в освоении, расширениях и сообщество сильное
Drupal — более гибкий и «сырой» чтоле… Отличная система для более профессиональной работы.
как может «сырое» решение лучше «подходить для профессиональной работы»?
«Сырой» употреблено в смысле «Не из коробки, требует мозговой деятельности»
Вы, вероятно, меня не так поняли.
Когда вы берете готовое решение и пытаетесь отладить / отредактировать его под себя, Вам приходится пилить чужой готовый код. В сырой системе достаточно просто написать под себя, не копаясь. Ну для меня точно. Переделки занимают столько же времени, сколько написание с нуля.
Так вот Drupal, по сравнению с Joomla более сырой.
Использование 100% готовых решений — все таки прерогатива начинающих разрабов.
Когда вы берете готовое решение и пытаетесь отладить / отредактировать его под себя, Вам приходится пилить чужой готовый код. В сырой системе достаточно просто написать под себя, не копаясь. Ну для меня точно. Переделки занимают столько же времени, сколько написание с нуля.
Так вот Drupal, по сравнению с Joomla более сырой.
Использование 100% готовых решений — все таки прерогатива начинающих разрабов.
В Drupal даже относительно простой сайт вряд ли обойдётся без написания кода (или использования CCK и ко), но когда на Joomla доходит до кода, то возможностей кастомизации оказывается меньше.
Как правило, почти всё что в БД поддаётся features-азации, а тут и контроль версий появляется.
Очень удобная штука для деплоя при серьёзной разработке
Очень удобная штука для деплоя при серьёзной разработке
Честно говоря, большинство «разработчиков» нельзя и на расстояние выстрела подпускать к написанию модулей к друпалу.
Практически каждый раз, когда приходится поддерживать сделанный неизвестными героями сайт, обнаруживается пучек самописных модулей, которые мало того, что повторяют функционал уже готовых и более чем популярных модулей, да еще и написаны так, что там инъекция на инъекции сидит.
Насчет систем контроля версий вы правы. К счастью, уже есть и немало облегчает разработку модуль features. Но хотелось бы большего конечно.
Практически каждый раз, когда приходится поддерживать сделанный неизвестными героями сайт, обнаруживается пучек самописных модулей, которые мало того, что повторяют функционал уже готовых и более чем популярных модулей, да еще и написаны так, что там инъекция на инъекции сидит.
Насчет систем контроля версий вы правы. К счастью, уже есть и немало облегчает разработку модуль features. Но хотелось бы большего конечно.
Во времена перехода с 5 на 6 приходилось частенько.
Очевидно под словом «сырой» имеется в виду «полуфабрикат», который, как известно, нужно готовить.
Помнится, как-то давным давно я что-то писал кому-то на Друпале, вроде это была 6ка. Еще тогда я тупо шизел от этого гавнокода и думал, что оно вот-вот загнется.
Но, походу, у какого-то сраного манагера хватило ума расписать инвесторам какой это «чудо» продукт и уже есть 7я версия и даже верстается 8ка… Это ужасно…
250+ девелоперов? Идрить колотить — это индусов или пакистанцев набрали что ли? Нахрена столько то????
4000-8000 описаных багов в трекере? да я не видел одновременно более 50-60, и то даже не в альфе!
5 человек это способны создать за 3-4 месяца с нуля до стейбл беты и это не шутка. Какой-же все это слив бабла и не профессионализм… И как это можно использовать и расхваливать — не понимаю…
Но, походу, у какого-то сраного манагера хватило ума расписать инвесторам какой это «чудо» продукт и уже есть 7я версия и даже верстается 8ка… Это ужасно…
250+ девелоперов? Идрить колотить — это индусов или пакистанцев набрали что ли? Нахрена столько то????
4000-8000 описаных багов в трекере? да я не видел одновременно более 50-60, и то даже не в альфе!
5 человек это способны создать за 3-4 месяца с нуля до стейбл беты и это не шутка. Какой-же все это слив бабла и не профессионализм… И как это можно использовать и расхваливать — не понимаю…
>>как забил на PHP
А мне нравится создавать изящные и быстрые решения. Мне нравится WEB и Десктоп. И мне по барабану какой это язык.
А будет это питон, ява, перл, пых-пых, си-шарп, или даже обычный В(изуал)Б(ейсик)А(для приложений) — мне пофигу, зависит от постановки задачи — ибо программер — это программер, а не кодер одного двух языков ;)
А мне нравится создавать изящные и быстрые решения. Мне нравится WEB и Десктоп. И мне по барабану какой это язык.
А будет это питон, ява, перл, пых-пых, си-шарп, или даже обычный В(изуал)Б(ейсик)А(для приложений) — мне пофигу, зависит от постановки задачи — ибо программер — это программер, а не кодер одного двух языков ;)
да и вам на здоровье :) да вот только более быстрого веб шаблонизатора с возможностями сложной логики, с достаточным (относительно) уровнем ООП, работой с регекстами и прочим «блекджеком и шлюхами» для веба, чем пХП, не изобрели пока ;)
это относилось к Вашему комментарию на забивание инструментария, который тоже никак не был подвязан к топику — ибо нигде не говорилось о языках ;)
А если серьезно, Д7 отличается от Д6 в первую очередь (потому как сразу видно) проработанным интерфесом управления сайтом. Это его основное преимущество перед основными конкурентами (Wordpress, Joomla), т.к. только в Д7 можно нормально настроить редакторский интерфейс и объяснить клиенту как этим пользоваться без тонны документации и костылей.
Но это же и основная проблема Д7 из-за позднего включения в основную ветку разработки, что потянуло за собой кучу ошибок и нестыковок.
Но опять же, на данный момент Д7 достаточно стабилен, как и его основные модули. Так что сейчас нужно смотреть на Д8, чтобы не повторилась эта история.
Но это же и основная проблема Д7 из-за позднего включения в основную ветку разработки, что потянуло за собой кучу ошибок и нестыковок.
Но опять же, на данный момент Д7 достаточно стабилен, как и его основные модули. Так что сейчас нужно смотреть на Д8, чтобы не повторилась эта история.
Что за люди пишут такие статьи?) Больше похоже не на критику «изнутри», а негодование конкурирующей платформы. А именно: что я бы стал делать, если бы мне захотелось очернить вордпресс, например? Вижу несколько простых шагов:
1. Критика изнутри, с которой тяжело спорить, ссылки на статьи, которые есть в любых спорах между разработчиками по поводу продукта. Черт возьми, даже при создании простого приложения калькулятора 4 года назад в группе разработчиков, с которой работал, я помню внутренний отзыв о том что «архитектура не имеет будущего». Это нормально, хуже когда нет этих споров, нет «болезни за продукт» и нет поиска лучших архитектурных решений. В друпале это все есть, будем же благодарны неравнодушному сообществу.
2. Находим старый, повторяющийся мем о минусах разработки. К примеру в joomla это может быть вопрос ЧПУ, в друпале — MVC, на который все пытаются ткнуть пальцем. Главное — упомянуть в статье, без «разбора», это запоминающийся момент.
3. Находим компанию, которая отказалась от сотрудничества с продуктом. Идеально — если это, к примеру, сервис продажи готовых тем. Неважно, что изначально была допущена ошибка в планировании — веб-разработчикам drupal не очень нужны «готовые темы», это не пользователи блог-платформы wordpress, которым нужно «запустить блог за 10 минут», это большие студии которые пишут серьезные продукты на данной CMS, которым наивно предлагать «готовый дизайн», имеющий множество нареканий в области стандартов верстки.
Вуаля, разоблачительная статья готова!)
1. Критика изнутри, с которой тяжело спорить, ссылки на статьи, которые есть в любых спорах между разработчиками по поводу продукта. Черт возьми, даже при создании простого приложения калькулятора 4 года назад в группе разработчиков, с которой работал, я помню внутренний отзыв о том что «архитектура не имеет будущего». Это нормально, хуже когда нет этих споров, нет «болезни за продукт» и нет поиска лучших архитектурных решений. В друпале это все есть, будем же благодарны неравнодушному сообществу.
2. Находим старый, повторяющийся мем о минусах разработки. К примеру в joomla это может быть вопрос ЧПУ, в друпале — MVC, на который все пытаются ткнуть пальцем. Главное — упомянуть в статье, без «разбора», это запоминающийся момент.
3. Находим компанию, которая отказалась от сотрудничества с продуктом. Идеально — если это, к примеру, сервис продажи готовых тем. Неважно, что изначально была допущена ошибка в планировании — веб-разработчикам drupal не очень нужны «готовые темы», это не пользователи блог-платформы wordpress, которым нужно «запустить блог за 10 минут», это большие студии которые пишут серьезные продукты на данной CMS, которым наивно предлагать «готовый дизайн», имеющий множество нареканий в области стандартов верстки.
Вуаля, разоблачительная статья готова!)
Вы серьезно? «группа разработчиков» работала над калькулятором и разговоры об «архитектуре» не были шуткой? :)
Я в контексте статьи. Тогда мы скорее холиварили на тему js фреймворка, вообще для проекта, не только для конкретного приложения. Но началось именно из мелочи — функционала калькулятора. И лозунги были в формате: «через полтора года мы не сможем это поддерживать за разумные деньги». Привел в качестве примера, как на мелочи может разгореться спор о вариантах решения. И если это бывает в мелочах, то в больших проектах — значительно чаще. Не стоит забывать что друпал — очень публичный проект, значительно более публичный чем многие другие cms и фреймворки, во многом из-за распределенного по всему миру большого и активного сообщества. В нем нормально привлечь внимание к недостаткам в виде статьи или записи в блоге. Но автор данного поста не указывает контекст. Приводит ссылку на graker.ru/news/2011/08/26/kak_smyt_makiyazh_so_svini_ili_vykhod_iz_krizisa, но не указывает, какие мысли в комментариях там проскальзывают, в том числе приведу цитату автора перевода: «Многие, и я в их числе, считают это заблуждением. Если в достаточной степени разобрался с апи — ни с какими проблемами бороться не надо, разрабатывай на здоровье :)».
В общем попахивает заказным постом «в негатив».
В общем попахивает заказным постом «в негатив».
Да норм статья — вполне конструктивнгая критика и, главное, по полочкам разложена.
Это Ваши посты больше смахивают на посты дева друпала, пытающегося выгородить это-непонятно-что ;)
Это Ваши посты больше смахивают на посты дева друпала, пытающегося выгородить это-непонятно-что ;)
Но вы же не будете спорить что «по полочкам разложена» довольно однобоко?) Согласитесь, не может быть чтобы «не было позитива» в обзоре CMS, если она обслуживает около 2% сайтов в интернете и имеет очень громкие «истории внедрения»?) Вот и хочется добавить толику объективности…
Стоп-стоп-стоп — а почему это Вы решили, что это обзор CMS? Как я увидел еще во время чтения — это всего лишь попытка указать явные и конкретные недостатки этого продукта, основываясь на внутренних данных (кол-во тикетов, попытка при таком их кол-ве ввети критиклы через пару лет, динамика изменения их статуса и кол-во разработчиков) — может эта инфа просто даст возможность кому-то подумать при выборе инструментария.
И то, что у автора нет похожей инфы по другим продуктам, ничего не значит — я бы, будучи в раздумьях, после таких цифирей точно бы не взял эту коробку для дальнейшей разработки
И то, что у автора нет похожей инфы по другим продуктам, ничего не значит — я бы, будучи в раздумьях, после таких цифирей точно бы не взял эту коробку для дальнейшей разработки
Понял, заканчиваю спор. Просто формат подачи материалов показался мне некорректным. Попробовал обратить на это внимание — не получилось. Ну что же, остается извиниться что видимо зря затеял обсуждение и отнял ваше время.
Человек совсем не разобрался в цифрах (если интересно, выше мой комментарий по этому поводу).
Статьи на которые он ссылается уже минимум год как устарели.
Статьи на которые он ссылается уже минимум год как устарели.
кто-то мою картинку взял с тачкой и девушкой с деньгами. Когда-то я заказывал ее у фрилансера за $80
Может он Вам передал всего лишь право на франшизу или на частное некоммерческое использование, оставив за собой право на обьект авторского права? ;)
Спасибо за разрешение использовать изображение. Первоисточник видимо здесь: romanpushkin.blogspot.com/2010/07/blog-post_28.html
кстати, выбрал эту картинку из огромной выдачи google, потому что цвет авто схож с цветом логотипа Drupal
Автор слишком зациклен на багах. Тут проблема в голове.
Я, например, работаю с друпалом уже лет 5, и сейчас первый раз узнал количество критических багов. Хм…
Использую данную систему как конструктор, очень удобно. Даже сделал недавно несложную CRM тупо на D7+CCK+Views — заказчик доволен, всё именно так, как нужно, без единой строчки кода.
Не понимаю, зачем вообще кодить в Дру и смотреть сколько там багов. Дело нехитрое — ищи, устанавливай, настраивай модули и в путь. Для 80% сайтов уже всё написано.
Кто хочет — делает, кто не хочет — ищет причины. Я делаю, а вы?
Я, например, работаю с друпалом уже лет 5, и сейчас первый раз узнал количество критических багов. Хм…
Использую данную систему как конструктор, очень удобно. Даже сделал недавно несложную CRM тупо на D7+CCK+Views — заказчик доволен, всё именно так, как нужно, без единой строчки кода.
Не понимаю, зачем вообще кодить в Дру и смотреть сколько там багов. Дело нехитрое — ищи, устанавливай, настраивай модули и в путь. Для 80% сайтов уже всё написано.
Кто хочет — делает, кто не хочет — ищет причины. Я делаю, а вы?
автор, скорей всего, относится к разряду разработчиков, в отличии от многочисленой армии «конструкторов» визиток и сталкивался с проблемами, о которых Вы и помыслить не могли за все 5ть лет своей работы «работы с Друпалом»
автор, скорей всего, относится к разряду разработчиков, в отличии от многочисленой армии «конструкторов» визиток и сталкивался с проблемами
Наверняка у такого автора и портфолио есть, как друпал-продуктов, так и других?) В противном случае хочу поинтересоваться основанием такого заявления.
Как тут уже выяснили, эта статья — перевод годовой давности. Автор оригинала — сам активный разработчик ядра друпала.
Так что автор этой статьи уже на хабре — «скорее всего» — никто в разработке и звать никак.
(Визитки я делал еще до друпала)
Так что автор этой статьи уже на хабре — «скорее всего» — никто в разработке и звать никак.
(Визитки я делал еще до друпала)
А CRM немножко посложнее? Шаг в сторону — расстрел? Нет, я не против Друпала, но так пиарить…
Полностью согласен с автором, до сих пор не понимаю причину народной любви к друпалу, сколько не сталкивался с ним — всегда были проблемы…
Выделение по всей статье слова Drupal жирным — это такое хитрое анти-СЕО? :) Выделять нужно то, на что ставится акцент, на что нужно обратить внимание. Так как вся статья про Drupal, то выделять это слово каждый раз смысла нет.
Статья, к сожалению, очень слабая.
Человек похоже не справился с задачей, побежал искать оправданий своего непонимания в интернет.
Нахватался обрывочных сведений из блогов многолетней давности и вывалил сюда плохопереведенную кашу.
Человек похоже не справился с задачей, побежал искать оправданий своего непонимания в интернет.
Нахватался обрывочных сведений из блогов многолетней давности и вывалил сюда плохопереведенную кашу.
Согласен с автором, но аргументация подобрана не верно.
Автор зациклился на багах — в любом продукте они есть. К тому же, баг багу рознь, и многие из тех, что зарегистрированы в трекере, вам просто не удастся повторить. Так что не пугайте новичков большими цифрами.
Основной линией аргументации должно быть то, что ядро Друпала очень устарело. Система хуков была революцией еще пять лет назад, но сегодня вызывает лишь улыбку. Работа с формами — тихий ужас, массивы тройной вложенности — это нормально, переводы строк — в БД, кэш — в БД. По любому чиху Друпал лезет в базу, генерируя по 200 запросов на страницу.
А хуже всего, что в ответ на это тебе отвечают одной и той же дебильной фразой — «вы не умеете его готовить». Хм, а чьи же тогда эти N сайтов, где в подвале стоит моя почта?
У меня тоже есть что посоветовать новичкам: учите фреймворки. Имхо, эра CMS прошла. На арену вышли такие прекрасные языки, как Питон и Руби, а вместе с ними — Джанго и Рельсы, способные превратить веб-разработку в удовольствие.
А Друпал, как верно замечено в статье — старый больной зверь. Система стала слишком громоздкой и не реагирует на свои же сигналы. Мой прогноз состоит в том, что кто-то форкнет Друпал, но форкнет очень удачно — оставит для публики только название, а сам перепишет ядро, выкинув хлам, сделает нормальные формы, gettext-переводы, файловый кэш.
Но для этого нужно осознать, что в Друпале действительно нужна революция, а не постоянное исправление багов.
Автор зациклился на багах — в любом продукте они есть. К тому же, баг багу рознь, и многие из тех, что зарегистрированы в трекере, вам просто не удастся повторить. Так что не пугайте новичков большими цифрами.
Основной линией аргументации должно быть то, что ядро Друпала очень устарело. Система хуков была революцией еще пять лет назад, но сегодня вызывает лишь улыбку. Работа с формами — тихий ужас, массивы тройной вложенности — это нормально, переводы строк — в БД, кэш — в БД. По любому чиху Друпал лезет в базу, генерируя по 200 запросов на страницу.
А хуже всего, что в ответ на это тебе отвечают одной и той же дебильной фразой — «вы не умеете его готовить». Хм, а чьи же тогда эти N сайтов, где в подвале стоит моя почта?
У меня тоже есть что посоветовать новичкам: учите фреймворки. Имхо, эра CMS прошла. На арену вышли такие прекрасные языки, как Питон и Руби, а вместе с ними — Джанго и Рельсы, способные превратить веб-разработку в удовольствие.
А Друпал, как верно замечено в статье — старый больной зверь. Система стала слишком громоздкой и не реагирует на свои же сигналы. Мой прогноз состоит в том, что кто-то форкнет Друпал, но форкнет очень удачно — оставит для публики только название, а сам перепишет ядро, выкинув хлам, сделает нормальные формы, gettext-переводы, файловый кэш.
Но для этого нужно осознать, что в Друпале действительно нужна революция, а не постоянное исправление багов.
в друпале концепция очень даже ок — все что нужно — просто нанять одного хорошего системного архитектора, одного хорошего архитектора БД и пару тройку не рядовых девелоперов + одного грамотного верстальщика на финале — и будет «новая революционная ЦМСка», которая еще пару лет будет закрывать все потребности рынка, как это было когда-то
Правильно отвечают. Потому что вы не разобрались с системой кеширования в друпале и теми сторонними модулями, которые для него есть. На друпале делают огромные сайты с миллионами посещений ежедневно и происходит это отнюдь не вопреки легендарным «200 запросов на страницу».
Друпал не только не «старый и больной», он вместе с Аквией еще нас всех переживет.
Друпал не только не «старый и больной», он вместе с Аквией еще нас всех переживет.
))))) приведите примеры много миллионно посещаемых сайтов? для таких посещений в друпале через чур много инклудов ;)
Навскидку ubuntu.com, leagueoflegends.com, forbes.ru
Обажжите — насколько я знаю, эти сайты кастривали и кастомизировали изначальный Друпал по максимуму в пост разработке (когда уволили изначальных девелоперов). Просто потому, что это было дешевле на определенный момент времени, чем редевелопмент.
Теперь же они, теоретически, готовы переделаться, но овчинка не стоит выделки.
Все тоже самое, что и у нас с ЗендФреймворком на одном из проектов:)
Теперь же они, теоретически, готовы переделаться, но овчинка не стоит выделки.
Все тоже самое, что и у нас с ЗендФреймворком на одном из проектов:)
Друпал по сути своей гибкий конструктор.
Вы совершенно правы, каждый такой сайт серьезно оптимизировался под нагрузки (обычно это заключается в постановке ряда кеширующих модулей и точечный запил их под свои требования).
Тем не менее, сайты построены и успешно работают.
Вы совершенно правы, каждый такой сайт серьезно оптимизировался под нагрузки (обычно это заключается в постановке ряда кеширующих модулей и точечный запил их под свои требования).
Тем не менее, сайты построены и успешно работают.
тут не заслуга друпала, а больше заслуга девов, которые заставили сайт на друпале летать )))) в общем — друпал я не хочу обижать (мне он нравится, и это я уже говорил, но бэ большую часть кода переписал бы или заставил переписать) — не стоит приводить топ сайты — в этом фреймворке есть конкретные изьяны, но, готов согласиться (окончательно и таки да!) об этом не стоит знать рядовым пользователям и конструкторам :)
Все дело в том, что написанный на коленке хоть сколько нибудь сложный сайт, который не делает «200 запросов к БД» все-равно перестает летать уже на десятках тысячах посетителей.
С ростом количества посетителей все быстро упирается в то, что нужны отдельные сервера под БД, отдельные сервера под апачи, отдельные сервера под кеширующие прокси.
И вот тут то для наколеночников разверзаются бездны проблем синхронизации, распараллеливания и прочее и прочее.
А прелесть друпала как раз в том, что он умеет гибко масштабироваться.
Специально заточенный под высокую нагрузку pressflow, модули кеширования типа boost-а и вот уже остается лишь напильником какие-то персональные узкие места выпиливать (хотя это тоже далеко не просто, и требует специфических навыков).
Слабое место друпала- как раз простенькие сайты на российских говнохостингах, где дерут втридорога, а ресурсов дают с гулькин этот самый. Тут да, хотя и с помощью того же boost-a можно частично решить проблему, лучше таки взять другой движок.
С ростом количества посетителей все быстро упирается в то, что нужны отдельные сервера под БД, отдельные сервера под апачи, отдельные сервера под кеширующие прокси.
И вот тут то для наколеночников разверзаются бездны проблем синхронизации, распараллеливания и прочее и прочее.
А прелесть друпала как раз в том, что он умеет гибко масштабироваться.
Специально заточенный под высокую нагрузку pressflow, модули кеширования типа boost-а и вот уже остается лишь напильником какие-то персональные узкие места выпиливать (хотя это тоже далеко не просто, и требует специфических навыков).
Слабое место друпала- как раз простенькие сайты на российских говнохостингах, где дерут втридорога, а ресурсов дают с гулькин этот самый. Тут да, хотя и с помощью того же boost-a можно частично решить проблему, лучше таки взять другой движок.
Там от друпала только robots.txt.
Фром спортбокс.ру вись лове (15 000 000 хитов).
Фром спортбокс.ру вись лове (15 000 000 хитов).
Шутку понял, смешно.
А в чём шутка? Поделитесь?
Перечисленные порталы работают на шестой версии, использовать шестую версию без серьёзных модификаций для серьёзных нагрузок практически нереально
Перечисленные порталы работают на шестой версии, использовать шестую версию без серьёзных модификаций для серьёзных нагрузок практически нереально
Да вот комментарии ваши почитал habrahabr.ru/users/rxb/comments/page3/
А с тем, что друпал нужно оптимизировать под высокие нагрузки никто и не спорит.
Тем не менее, от него там, мягко говоря, не только роботс.тхт остался :)
А с тем, что друпал нужно оптимизировать под высокие нагрузки никто и не спорит.
Тем не менее, от него там, мягко говоря, не только роботс.тхт остался :)
Отвечают неправильно. У таких проблем серьезная проблема с логикой.
Критика не означает, что я не умею готовить Друпал.
А критикую я потому, что работаю с фреймворками и вижу элегантные решения.
Критика не означает, что я не умею готовить Друпал.
А критикую я потому, что работаю с фреймворками и вижу элегантные решения.
*у таких людей
Дело не в критике как таковой, а в ее обоснованности. Если критика необоснована, вывод простой- пациент не разобрался.
Да, во фреймворках полно элегантных решений. Но вот беда, как только нужно построить что-то сложнее домашней странички, начинается страшное.
Еще страшнее становится, если возникает потребность строить что-то сложнее домашней странички по много раз в месяц, да каждый раз с заточкой под конкретного клиента.
Так что CMS/CMF в обозримой перспективе не умрут.
Да, во фреймворках полно элегантных решений. Но вот беда, как только нужно построить что-то сложнее домашней странички, начинается страшное.
Еще страшнее становится, если возникает потребность строить что-то сложнее домашней странички по много раз в месяц, да каждый раз с заточкой под конкретного клиента.
Так что CMS/CMF в обозримой перспективе не умрут.
Не первая уже статья про внутреннюю кухню Друпала, после которой, у не знающего Друпал человека, возникает ощущение полного тотального полярного животного, застойного болота, безнадеги, бесперспективности, убогости и прочего.
На самом же деле, в 95% случаев использования Друпала, о внутренних проблемах данной CMS вы никогда не узнаете и будете довольны как слоны на водопое от его возможностей.
На самом же деле, в 95% случаев использования Друпала, о внутренних проблемах данной CMS вы никогда не узнаете и будете довольны как слоны на водопое от его возможностей.
Для меня это тоже странно. Я на Хабр уже более года не заходил. Работаю на запад — тут Друпал цветет и пахнет, и разработчики активно переходят на Друпал. Я сам сейчас практически постоянно работаю с миграцией сайтов с других ЦПС на Друпал. Захожу в ХАБР — а тут похоронные песни Друпалу поют, очень странно. При чем, поют почему — потому что разработчики Друпала 7 делились своими предложениями. Переводчики взяли негатив, написали статьи на уровне желтой прессы. Я вижу смысл такое делать в политике. Но в веб-разработке — какой кайф?!
Когда продукт создается сильным сообществом, которое способно критиковать себя, выявлять и решать проблемы — это очень важный плюс такому сообществу. Например, самокритика проекта при создании Друпал 7 позволила сделать эту версию гораздо лучше всех предыдущих. А в 8 версии, Друпал бросает вызовам базовым ограничениям своего ядра и перебирается на Symphony в качестве движка. В 8 версию будет также включена новая система редактирования и управления контентом, с инлайн-редактированием Sparkle, и поддержка мобильных устройств в ядре. И вот в то время, как все затаив дыхание следят за тем что будет с Друпал 8, у на стут на хабре все еще жуют сопли из-за какой-то критики, которая была в разработке Друпал 7.
Когда продукт создается сильным сообществом, которое способно критиковать себя, выявлять и решать проблемы — это очень важный плюс такому сообществу. Например, самокритика проекта при создании Друпал 7 позволила сделать эту версию гораздо лучше всех предыдущих. А в 8 версии, Друпал бросает вызовам базовым ограничениям своего ядра и перебирается на Symphony в качестве движка. В 8 версию будет также включена новая система редактирования и управления контентом, с инлайн-редактированием Sparkle, и поддержка мобильных устройств в ядре. И вот в то время, как все затаив дыхание следят за тем что будет с Друпал 8, у на стут на хабре все еще жуют сопли из-за какой-то критики, которая была в разработке Друпал 7.
Недовольства и необоснованные обвинения в том, что пост является заказным — это вполне ожидаемая реакция (в первую очередь от ярых приверженцев продукта).
Прошу еще раз обратить внимание на то, что в статье отсутствует реклама какого-либо конкурирующего продукта.
У меня нет желания подливать масла в огонь, «мериться пиписьками» и отвечать на провокации троллей.
Практика показывает, что подобного рода споры бессмысленны (все равно каждый останется при своем мнении).
«Единственный способ понравиться всем — это, бл..., умереть!» (с)
Никоим образом не хотел никого обидеть, лишь привел факты, которые могут быть интересны тем, кто озадачен вопросом выбора рабочего инструмента. Особо опасных троллей уверяю, что ваши попытки расстроить меня своими дерзкими заявлениями в мой адрес не приведут к результату. Удачи в ваших проектах!
Прошу еще раз обратить внимание на то, что в статье отсутствует реклама какого-либо конкурирующего продукта.
У меня нет желания подливать масла в огонь, «мериться пиписьками» и отвечать на провокации троллей.
Практика показывает, что подобного рода споры бессмысленны (все равно каждый останется при своем мнении).
«Единственный способ понравиться всем — это, бл..., умереть!» (с)
Никоим образом не хотел никого обидеть, лишь привел факты, которые могут быть интересны тем, кто озадачен вопросом выбора рабочего инструмента. Особо опасных троллей уверяю, что ваши попытки расстроить меня своими дерзкими заявлениями в мой адрес не приведут к результату. Удачи в ваших проектах!
То, что напрямую не указывается конкурент никоим образом не отбивает мнения о заказном характере статьи.
Насчет же фактов. Вас самого не смущает, что самые свежие ваши (точнее даже не ваши, а тех людей чьи посты из блогов вы перевели) факты датированы августом прошлого года?
Насчет же фактов. Вас самого не смущает, что самые свежие ваши (точнее даже не ваши, а тех людей чьи посты из блогов вы перевели) факты датированы августом прошлого года?
Ну хорошо, по вашему ситуация изменилась и текущий релиз 7-ой ветки удобен, логичен и лишен проблем?!
Ну раз вы ответили — «Да!», то почему бы теперь вам не направить свою буйную энергию на помощь сообществу и пользователям, которые сталкиваются с немалым количеством проблем при использовании 7-ой версии, о чем свидетельствуют многочисленные ветки официального и других крупных форумов по Drupal, датированные этим годом (раз уж вы так привязались к датам).
Ну раз вы ответили — «Да!», то почему бы теперь вам не направить свою буйную энергию на помощь сообществу и пользователям, которые сталкиваются с немалым количеством проблем при использовании 7-ой версии, о чем свидетельствуют многочисленные ветки официального и других крупных форумов по Drupal, датированные этим годом (раз уж вы так привязались к датам).
Я не евангелист от друпала, за всех говорить не могу.
В том наборе функционала, что нужен лично мне, у 7-ки нет видимых проблем (перешел на нее чуть менее полугода назад).
Если вы нашли такое немалое количество проблем, может укажете на них? Я про системные проблемы, а не сто мильонов тем вида «как мне поставить друпал»? или «как мне добавить вот такой функционал»?
Как раз и получилась бы интересная и актуальная статья.
В том наборе функционала, что нужен лично мне, у 7-ки нет видимых проблем (перешел на нее чуть менее полугода назад).
Если вы нашли такое немалое количество проблем, может укажете на них? Я про системные проблемы, а не сто мильонов тем вида «как мне поставить друпал»? или «как мне добавить вот такой функционал»?
Как раз и получилась бы интересная и актуальная статья.
Бред какой то в каждом утверждении :)
С 7 версией — да изменилась. Недостатки были есть и будут, как и в любом здоровом и развивающемся продукте (кстати вы бы ещё 8-ю ветку тут похаяли и об огромной куче её багов написали:) ). Как вы правильно заметили — недостатков нет только у умерших продуктов. Отсюда вывод — всё в порядке.
Большинство приверженцев так и оказывают помощь. Ибо количество вариантов использования, и вариантов решения любой задачи очень много. Зачастую помощь заключается в совете, что и как лучше использовать в каждом конкретном случае.
1) хронология застыла где-то в прошлом веке (её, товарищ… сейчас август 2012) а заморозка кода 8 — февраль 2013
2) "© когда-то выступил один из лидеров команды" — ну и что из этого следует? Мало ли кто и с чем выступает… :)
3) имеем недостатки — естественно имеем, мы же растем и развиваемся (в отличии от мертвечины, которую навязывает автор)
4) прогноз — намертво увязнет. Ну как бы это помягче, чтобы вас не обидеть :). Посмотрим через год кто в чём увязнет.
5) есть ли выход — для автора точно нет. Если он предлагает распылить силы на исправление 8к непонятных фич, а не десятка редко-встречающихся багов — то да можно увязнуть надолго.
Вердикт — лучше подошла бы картинка мужика на кровате с женщиной со словами — «родная, извини не смог». Он больше соответствует описанию не сложившихся взаимоотношений автора с этой замечательной CMF. Ну не шмагла понять и освоить…
С 7 версией — да изменилась. Недостатки были есть и будут, как и в любом здоровом и развивающемся продукте (кстати вы бы ещё 8-ю ветку тут похаяли и об огромной куче её багов написали:) ). Как вы правильно заметили — недостатков нет только у умерших продуктов. Отсюда вывод — всё в порядке.
Большинство приверженцев так и оказывают помощь. Ибо количество вариантов использования, и вариантов решения любой задачи очень много. Зачастую помощь заключается в совете, что и как лучше использовать в каждом конкретном случае.
1) хронология застыла где-то в прошлом веке (её, товарищ… сейчас август 2012) а заморозка кода 8 — февраль 2013
2) "© когда-то выступил один из лидеров команды" — ну и что из этого следует? Мало ли кто и с чем выступает… :)
3) имеем недостатки — естественно имеем, мы же растем и развиваемся (в отличии от мертвечины, которую навязывает автор)
4) прогноз — намертво увязнет. Ну как бы это помягче, чтобы вас не обидеть :). Посмотрим через год кто в чём увязнет.
5) есть ли выход — для автора точно нет. Если он предлагает распылить силы на исправление 8к непонятных фич, а не десятка редко-встречающихся багов — то да можно увязнуть надолго.
Вердикт — лучше подошла бы картинка мужика на кровате с женщиной со словами — «родная, извини не смог». Он больше соответствует описанию не сложившихся взаимоотношений автора с этой замечательной CMF. Ну не шмагла понять и освоить…
Да, история с коре-разработчиками, их ограничения, уход «крутых» компаний и прочее не есть хорошая история, надеюсь Дрис сделал свои выводы.
>> на 2012 год ситуация с 7кой пока что мало улучшилась. В намеченном релизе 8-ки все относящееся к ядру теперь будет вынесено в папку core.
В реальной разработке с этими не сталкивался.
>> Как видите события развиваются плачевно. Только в новых проектах: Dashboard, Shortcut, Toolbar и Overlay более 150 неисправленных багов и задач.
да, это минус, можно было не включать в «ядро», и я их просто отключаю :)
>> на 2012 год ситуация с 7кой пока что мало улучшилась. В намеченном релизе 8-ки все относящееся к ядру теперь будет вынесено в папку core.
В реальной разработке с этими не сталкивался.
>> Как видите события развиваются плачевно. Только в новых проектах: Dashboard, Shortcut, Toolbar и Overlay более 150 неисправленных багов и задач.
да, это минус, можно было не включать в «ядро», и я их просто отключаю :)
Кстати, в то время когда «Rockettheme3 прощается с Drupal», другая известная студия JoomlArt, создала отдельное подразделение занимающееся разработкой тем под Drupal — Themebrain
Глянул бегло на фото — подумал, что Цыплухин вещает о Друпале %)
>> Данной статьей, я хотел предостеречь новчиков, которые стоят перед выбором: какую CMS/CMF использовать в качестве основного интрумента и посмотреть в сторону других решений…
Мне, к сожалению пока не известна другая CMS равноценная по гибкости и универсальности. Ведь, по сути, на Drupal можно склепать сайт отвечающий любым капризам и поставленным задачам… Я конечно понимаю, настоящая крутизна — это фреймворки и «голый» php. Но пока php не освоил, остается прибегать к помощи/мощи какой-нибудь универсальной CMS
Мне, к сожалению пока не известна другая CMS равноценная по гибкости и универсальности. Ведь, по сути, на Drupal можно склепать сайт отвечающий любым капризам и поставленным задачам… Я конечно понимаю, настоящая крутизна — это фреймворки и «голый» php. Но пока php не освоил, остается прибегать к помощи/мощи какой-нибудь универсальной CMS
как вспомню про Views, CCK, Context, Panels… у какой CMS такой функционал можно найти?
MODX
Я кое-что слышал про MODX. Но так и не смог разобраться с ней. Может вы подскажете где можно найти хорошее учебное пособие по ней
Вот буду «пилить» своего ведущего разработчика написать статью на эту тему на его проекте modx.by. =)
Могу еще порекомендовать bezumkin.ru.
Могу еще порекомендовать bezumkin.ru.
Простите, но ни аналога views, ни panels ни context в modX нет.
И что? Как-то справляемся без таких названий. А может, они и есть, но называются иначе? =)
Поясните, пожалуйста, что реализуют перечисленные вами вещи?
Поясните, пожалуйста, что реализуют перечисленные вами вещи?
Справляться не значит решать оптимально задачу. Любой сайт можно сделать на любом движке и без него, только большинство сочетаний «задача — инструмент» будет куда хуже работать, или требовать больше затрат на разработку, или на поддержку…
Я работал и с Drupal и с ModX, и могу сравнивать, а не делать как вы голословных утверждений.
Views это инструментарий, позволяющий гибко делать выборки данных и визуализировать результаты. Причём выборки могут делаться не просто из набора документов или их полей, а с различными фильтрами, связями между данными различных модулей, и визуализироваться различными способами, причём набор способов расширяем различными дополнительными модулями. Например, можно сделать табличку или слайдшоу или…
Аналог слегка похожий getResources + getPage, но на порядки скромнее.
Результат можно получить в modX с написав, немалое количество кода, используя фреймворк xPDO, лежащий в основе modX(та ещё пакость, надо заметить), или в простейшем случае, применив вышеописанные аддоны. В Drupal это делается несколькими кликами.
Panels даёт возможность гибко управлять структурой страницы, размещать в нужных местах нужные модули, и.т.п. Ничего аналогичного в modX нет в принципе. Почитайте документацию по этому модулю на drupal.org, поймёте что это. Результат может быть достигнут в modX большим количеством разных шаблонов, и соответственно, проблемой для того, кто публикует информацию.
Context позволяет гибко задавать условия показа различных блоков на различных страницах в зависимости от большого количества факторов. В modx это реализуется либо огромным количеством шаблонов, либо огромным количеством условий в коде шаблона. Это сильно усложнит и поддержку и использование сайта.
Ну и напоследок, вы предлагаете использовать modX вместо Drupal? Так вот хотя бы ознакомьтесь с тем, что вы хотите заменить — поймёте, что до Drupal modX ох как далеко, и с нынешними темпами эта ситуация не изменится ровно никогда.
Я работал и с Drupal и с ModX, и могу сравнивать, а не делать как вы голословных утверждений.
Views это инструментарий, позволяющий гибко делать выборки данных и визуализировать результаты. Причём выборки могут делаться не просто из набора документов или их полей, а с различными фильтрами, связями между данными различных модулей, и визуализироваться различными способами, причём набор способов расширяем различными дополнительными модулями. Например, можно сделать табличку или слайдшоу или…
Аналог слегка похожий getResources + getPage, но на порядки скромнее.
Результат можно получить в modX с написав, немалое количество кода, используя фреймворк xPDO, лежащий в основе modX(та ещё пакость, надо заметить), или в простейшем случае, применив вышеописанные аддоны. В Drupal это делается несколькими кликами.
Panels даёт возможность гибко управлять структурой страницы, размещать в нужных местах нужные модули, и.т.п. Ничего аналогичного в modX нет в принципе. Почитайте документацию по этому модулю на drupal.org, поймёте что это. Результат может быть достигнут в modX большим количеством разных шаблонов, и соответственно, проблемой для того, кто публикует информацию.
Context позволяет гибко задавать условия показа различных блоков на различных страницах в зависимости от большого количества факторов. В modx это реализуется либо огромным количеством шаблонов, либо огромным количеством условий в коде шаблона. Это сильно усложнит и поддержку и использование сайта.
Ну и напоследок, вы предлагаете использовать modX вместо Drupal? Так вот хотя бы ознакомьтесь с тем, что вы хотите заменить — поймёте, что до Drupal modX ох как далеко, и с нынешними темпами эта ситуация не изменится ровно никогда.
Спасибо за разъяснение. Я болею за MODX, не как разработчик, а как менеджер и пользователь в данном топике. В помощь могу позвать Alroniks, чтобы он сказал, есть ли такое сейчас в MODX и насколько оно просто в использовании?
По поводу замены Drupal'а MODX'ом. Я где нибудь агитировал за смену? Разве говорил, что одно лучше/хуже другого? Я лишь предлагаю альтернативу на вопрос: «А что, если не?»
По поводу замены Drupal'а MODX'ом. Я где нибудь агитировал за смену? Разве говорил, что одно лучше/хуже другого? Я лишь предлагаю альтернативу на вопрос: «А что, если не?»
Все зависит от задач. Контексты в MODx есть, но не в том смысле, как они есть в Drupal (особенности терминологии). Что касается вывода данных, то все гибко и настраиваемо, разве что может и не в 2 клика, а в 5. Выводить можно так же любыми способами. Есть типы данных для ресурсов, есть input и output для дополнительных параметров, есть фильтры. Можно вместо фильтров подставлять сниппеты, они тоже будут выполнять свою задачу. Все есть, но немного в другом виде, нежели в Drupal.
Что касается панелей. У MODX абсолютная свобода относительно шаблонов. Если нам нужны какие-то хитрые панели, то делаем их в виде чанков и вставляем в нужные шаблоны. Можно конечно написать модуль, который будет этим управлять, но если его еще не написали, значит нет в нем необходимости. Остальные инструменты решают свои задачи и делают это хорошо.
Я не сравниваю Drupal и MODx, я защищаю MODx по вашим пунктам, так как достаточно давно с ним работаю и знаю, что свою задачу он выполняет очень хорошо. Но опять же, все зависит от задач. Не всегда можно использовать MODx, он не панацея. Как и Drupal собственно.
Что касается панелей. У MODX абсолютная свобода относительно шаблонов. Если нам нужны какие-то хитрые панели, то делаем их в виде чанков и вставляем в нужные шаблоны. Можно конечно написать модуль, который будет этим управлять, но если его еще не написали, значит нет в нем необходимости. Остальные инструменты решают свои задачи и делают это хорошо.
Я не сравниваю Drupal и MODx, я защищаю MODx по вашим пунктам, так как достаточно давно с ним работаю и знаю, что свою задачу он выполняет очень хорошо. Но опять же, все зависит от задач. Не всегда можно использовать MODx, он не панацея. Как и Drupal собственно.
>Что касается панелей.
>Можно конечно написать модуль, который будет этим управлять, но если его еще не написали, значит нет в нем необходимости. Остальные инструменты решают свои задачи и делают это хорошо.
Скорее потому, что такую задачу решать-то в общем и некому. Неудачный фреймворк, довольно скудная документация, очень маленькое комюнити и соответственно мало серьёзных разработчиков.
Ну и опять же, либо шаблоны с большим количеством ветвлений => сложность в поддержке, либо много шаблонов => сложность в работе с сайтом.
И так практически во всём, на самом-то деле. Я хорошенько копнув вглубь, и попытавшись реализовать достаточно сложный проект, сильно разочаровался в modX. Хотя на первый взгляд он и кажется довольно привлекательным.
>Можно конечно написать модуль, который будет этим управлять, но если его еще не написали, значит нет в нем необходимости. Остальные инструменты решают свои задачи и делают это хорошо.
Скорее потому, что такую задачу решать-то в общем и некому. Неудачный фреймворк, довольно скудная документация, очень маленькое комюнити и соответственно мало серьёзных разработчиков.
Ну и опять же, либо шаблоны с большим количеством ветвлений => сложность в поддержке, либо много шаблонов => сложность в работе с сайтом.
И так практически во всём, на самом-то деле. Я хорошенько копнув вглубь, и попытавшись реализовать достаточно сложный проект, сильно разочаровался в modX. Хотя на первый взгляд он и кажется довольно привлекательным.
>по сути, на Drupal можно склепать сайт отвечающий любым капризам и поставленным задачам
У меня не очень большой опыт работы с разными CMS но скажите, на какой системе нельзя «сделать сайт, отвечающий всем капризам»? Всегда вопрос лишь в затраченном времени, и, как следствия, стоимости за допилку. А там уж хоть Drupal, хоть Joomla, хоть Битрикс…
У меня не очень большой опыт работы с разными CMS но скажите, на какой системе нельзя «сделать сайт, отвечающий всем капризам»? Всегда вопрос лишь в затраченном времени, и, как следствия, стоимости за допилку. А там уж хоть Drupal, хоть Joomla, хоть Битрикс…
Автор статьи хотя бы пробовал в деле Drupal 7?
Вы внимательно читали статью?
А вы расскажите, с какими проблемами столкнулись. По пунктам.
Вот с какими проблемами столкнулся автор:
«Не вдаваясь в подробности приведу несколько примеров, чтобы аргументировать свой посыл.
Источник — упоминаемая вверху статья автора habrahabr.ru/sandbox/45337/
«Не вдаваясь в подробности приведу несколько примеров, чтобы аргументировать свой посыл.
- Функциональность позволяющая задавать Правила доступа в панели Администрирование -> Управдения пользователями в Drupal 7 отсутствует. Заменил модулем Access Rules.
- Модуль Profile отсутствует в списке модулей Drupal 7. Оказывается он помечен, как устаревший и по умолчанию скрыт в profile.info Решение проблемы: drupal.org/node/874026
- В Drupal 7 типы CCK полей Node reference и User reference по умолчанию отсутствуют. Итак, где взять типы полей Node reference и User reference в Drupal 7?
Решение: модуль, реализующий функционал полей-ссылок на ноды и пользователей называется References. В настоящее время автор занимается тесной интеграцией модуля с Views третьей версии.
- Для реализации группа полей в Drupal 7, по типу — как это было в Drupal 6, использовал модуль Field Group.
- И еще с десяток дополнительных модулей.
Источник — упоминаемая вверху статья автора habrahabr.ru/sandbox/45337/
Можно конечно долго ругать Друпал. Но чем заменить. Джумла и ВП не вариант (ибо ток хуже)
Аргументируйте чем MODX лучше Drupal
Modx — не знаю чем он лучше
Я не писал, что он лучше. Я лишь рекомендовал что-то на замену. О Drupale только слышал и один раз видел админку года 2 назад. Уже тогда она была жутко отстающей от современных тенденций UX.
Весь ужас ситуации в том, что в друпал нет «админки» в обычном понимании этого слова. Так что даже и не знаю что вы там такое видели.
В том и дело. Было что-то наложенное древовидное на интерфейс. Возможно, это были кривые руки разработчика, но все же…
Я вот серьезно не хочу спорить о том, лучше ли MODx Drupal'а? Хочу лишь сказать, что на рынке CMF у Drupala единственный серьезный конкурент и это MODx. Typo3, Joomla, Wordpress это все классические CMS, у них другая ниша. Ф фреймворки типа Kohana, Yii стоят еще на ступень выше. Как-то так.
Из самых банальных полезных вещей могу перечислить следующие:
— возможность управления как html, так и flash сайтами;
— поддержка из коробки двух СУБД — MySQL и MSSQL (готовится поддержка PostgreSQL); да и вообще работа с базой реализована через прослойку xPDO, так что при желании, хоть на Oracle можно запустить MODx;
— работа как на Apache, так и на nGinx;
— мощный и при этом очень простой шаблонизатор;
— хранение шаблонов как в БД, так и в статике в виде файлов;
— подключение внешних CDN для хранения статики;
— встроенное неплохое кеширование;
— никаких требований к верстке;
— отличные URL;
— настраиваемые типы ресурсов.
Это лишь на первый взгляд, что лично нам очень удобно. Могу позвать сюда Alroniks, который может рассказать о внутряке MODx, если у него будет желание.
Я вот серьезно не хочу спорить о том, лучше ли MODx Drupal'а? Хочу лишь сказать, что на рынке CMF у Drupala единственный серьезный конкурент и это MODx. Typo3, Joomla, Wordpress это все классические CMS, у них другая ниша. Ф фреймворки типа Kohana, Yii стоят еще на ступень выше. Как-то так.
Из самых банальных полезных вещей могу перечислить следующие:
— возможность управления как html, так и flash сайтами;
— поддержка из коробки двух СУБД — MySQL и MSSQL (готовится поддержка PostgreSQL); да и вообще работа с базой реализована через прослойку xPDO, так что при желании, хоть на Oracle можно запустить MODx;
— работа как на Apache, так и на nGinx;
— мощный и при этом очень простой шаблонизатор;
— хранение шаблонов как в БД, так и в статике в виде файлов;
— подключение внешних CDN для хранения статики;
— встроенное неплохое кеширование;
— никаких требований к верстке;
— отличные URL;
— настраиваемые типы ресурсов.
Это лишь на первый взгляд, что лично нам очень удобно. Могу позвать сюда Alroniks, который может рассказать о внутряке MODx, если у него будет желание.
Ошибся TYPO3 тоже CMF, сюда еще Movable Type добавить можно.
В общем на рынке CMF есть такой выбор:
— Drupal
— MODx
— TYPO3
— Movable Type
Кто знает еще что-то?
В общем на рынке CMF есть такой выбор:
— Drupal
— MODx
— TYPO3
— Movable Type
Кто знает еще что-то?
Древовидное может быть где угодно. Там фишка в том, что у друпала как такогого нет «жестких правил верстки», потому что практически весь вывод регулируется через темы.
Да, скажем, у друпала6 есть стандартная тема гарланд, под которую можно написать «жесткие правила», но если взять, скажем, тему zen или какой-нибудь fusion, «жесткие правила» будут совсем другие. В общем, все очень гибко настраивается.
Про MODx ничего пока сказать не могу, сколько нибудь плотно с ним не работал.
Но вот список фич не впечатлил, все это давно есть в друпал.
Да, скажем, у друпала6 есть стандартная тема гарланд, под которую можно написать «жесткие правила», но если взять, скажем, тему zen или какой-нибудь fusion, «жесткие правила» будут совсем другие. В общем, все очень гибко настраивается.
Про MODx ничего пока сказать не могу, сколько нибудь плотно с ним не работал.
Но вот список фич не впечатлил, все это давно есть в друпал.
Возможно, сходимся в том, что возможности одинаковы. Но несомненным плюсом MODx является то, что сам проект молод, а 2.0 был переписан 2 года назад с нуля на основе опыта 1.0. Логика подсказывает, если руки разработчиков MODx прямые, он однозначно в меньшей степени должен быть обременен устаревшими техниками и парадигмами программирования.
Из комментов вижу, что Drupal 8 переписывается с нуля. Возможно, это улучшит его ситуацию.
Из комментов вижу, что Drupal 8 переписывается с нуля. Возможно, это улучшит его ситуацию.
Ну, сама по себе молодость и переписка с нуля- очень сомнительные достижения.
Скажем, про друпал можно сказать что он успешно и много лет на рынке, отличается стабильностью (если не лезть в девелоперские альфа-бета ветки) и высокой защищенностью.
Компания Acquia строит все более крупный и доходный бизнес на его основе.
На мой взгляд это гораздо более существенные плюсы, позволяющие рассчитывать на поддержку на годы вперед.
Не говоря уже о том, что пусть и с определенными граблями, но поддерживается апгрейд со старых версий движка на новые.
Скажем, про друпал можно сказать что он успешно и много лет на рынке, отличается стабильностью (если не лезть в девелоперские альфа-бета ветки) и высокой защищенностью.
Компания Acquia строит все более крупный и доходный бизнес на его основе.
На мой взгляд это гораздо более существенные плюсы, позволяющие рассчитывать на поддержку на годы вперед.
Не говоря уже о том, что пусть и с определенными граблями, но поддерживается апгрейд со старых версий движка на новые.
Да, надежность, проверенная годами записывается в плюс к Drupal. Но и MODx уже существует порядка 6 лет. Просто активное продвижение началось с выходом ветки 2.0.
За CMF MODx стоит MODX LLC, в которую «выросли» основатели проекта и строят сейчас на ее основе серьезный бизнес. Например, задача этого года у них — запуск MODX Cloud, очень интересной штуки, особенно для начинающих разработчиков или просто для небольших и средних проектов.
Пока MODx пережил только один переход с ветки на ветку, сопровождавшийся полной сменой архитектуры, потому автоматического апгрейда не было. Но дальше, обещается.
Кстати, вспомнил про офигительный плюс MODx — менеджер пакетов (модулей) с зависимостями и прочим! В следующем году обещают существенные улучшения этой функциональности и возможность подключения собственных репозиториев с пакетами расширений! Пользователи никсов оценят это по достоинству! Ничего подобного в CMS/CMF, реализованного на таком уровне я не видел.
За CMF MODx стоит MODX LLC, в которую «выросли» основатели проекта и строят сейчас на ее основе серьезный бизнес. Например, задача этого года у них — запуск MODX Cloud, очень интересной штуки, особенно для начинающих разработчиков или просто для небольших и средних проектов.
Пока MODx пережил только один переход с ветки на ветку, сопровождавшийся полной сменой архитектуры, потому автоматического апгрейда не было. Но дальше, обещается.
Кстати, вспомнил про офигительный плюс MODx — менеджер пакетов (модулей) с зависимостями и прочим! В следующем году обещают существенные улучшения этой функциональности и возможность подключения собственных репозиториев с пакетами расширений! Пользователи никсов оценят это по достоинству! Ничего подобного в CMS/CMF, реализованного на таком уровне я не видел.
Ну что ж, удачи проекту MODx! :)
Зависимости между модулями в Drupal были чуть ли не с рождения :), как и модулей из репозитария, установочные профили для системы.
Я не думаю, что в «революционной» 2 версии MODX сделали что-то, чего нет в Drupal.
А молодость и слабое распространение — вроде как в минус системе.
Большое распространение и время позволяет выявить все слабые стороны и поработать над их улучшением. А на drupal работает порядка 2% сайта (с джумлой они делят 2 место после WP).
Я не думаю, что в «революционной» 2 версии MODX сделали что-то, чего нет в Drupal.
А молодость и слабое распространение — вроде как в минус системе.
Большое распространение и время позволяет выявить все слабые стороны и поработать над их улучшением. А на drupal работает порядка 2% сайта (с джумлой они делят 2 место после WP).
В тему в ленте нашел. =)
Ах, да, еще как-то под простой сайт года три назад верстал. Меня убили жесткие правила верстки для последующей интеграции с Drupal.
Товарищ Вы пропустили мировую революцию:
1. Ядро восьмёрки работает на Symfony 2.
2. Новый движок рендера: Twig, может столько, что голова кругом.
3. Базовый функционал панелей (Panels), вёрстки под разные устройства и Views в ядре — уже на подходе.
4. Аналог Rules (события и правила) в ядре (вы ещё не используете Rules + Views + Panels, тогда Вы в каменном веке).
5. Инлайновое редактирование уже есть и для Drupal 7.
6. Количество документации по продукту больше только у продуктов Microsoft.
7. Количество человек в пересчёте на человеко-месяц участвующих в спринтах на конференциях по улучшению ~= можно свой маленький завод обслуживать (от 3 000 человек в течении недели исправляют то, что им не нравятся в системе во время конференции, кстати как раз в Мюнхене на следующей неделе).
Вы необъективны если не видели сборки drupal.org/project/spark и drupal.org/project/panopoly.
Но когда нужно отомстить заказчику и посадить его на краник IT терроризма, то:
1. Сайт должен быть самописный, что б любой функционал добавлялся дорого и долго.
2. Должен быть написан на С++, что б писался долго и чтоб его никто не понял.
3. К нему не должно быть много документации.
4. Он должен быть комически дорог в производстве (всё же пишем сами).
5. Он не должен решать проблем бизнеса клиента (хотя сайт делается для этого и всё равно на чём он написан).
6. Вы не должны хотеть заработать денег — это банально собирать крутые сайты, лучше похарткодить.
7.…
Как то так.
1. Ядро восьмёрки работает на Symfony 2.
2. Новый движок рендера: Twig, может столько, что голова кругом.
3. Базовый функционал панелей (Panels), вёрстки под разные устройства и Views в ядре — уже на подходе.
4. Аналог Rules (события и правила) в ядре (вы ещё не используете Rules + Views + Panels, тогда Вы в каменном веке).
5. Инлайновое редактирование уже есть и для Drupal 7.
6. Количество документации по продукту больше только у продуктов Microsoft.
7. Количество человек в пересчёте на человеко-месяц участвующих в спринтах на конференциях по улучшению ~= можно свой маленький завод обслуживать (от 3 000 человек в течении недели исправляют то, что им не нравятся в системе во время конференции, кстати как раз в Мюнхене на следующей неделе).
Вы необъективны если не видели сборки drupal.org/project/spark и drupal.org/project/panopoly.
Но когда нужно отомстить заказчику и посадить его на краник IT терроризма, то:
1. Сайт должен быть самописный, что б любой функционал добавлялся дорого и долго.
2. Должен быть написан на С++, что б писался долго и чтоб его никто не понял.
3. К нему не должно быть много документации.
4. Он должен быть комически дорог в производстве (всё же пишем сами).
5. Он не должен решать проблем бизнеса клиента (хотя сайт делается для этого и всё равно на чём он написан).
6. Вы не должны хотеть заработать денег — это банально собирать крутые сайты, лучше похарткодить.
7.…
Как то так.
«Данной статьей, я хотел предостеречь новичков, которые стоят перед выбором: какую CMS/CMF использовать в качестве основного инструмента и посмотреть в сторону других решений (об этом в следующей статье).»
Как можно на основе своих примитивных суждений основанных на малом опыте и устаревших материалах давать кому то рекомендации.
Как можно на основе своих примитивных суждений основанных на малом опыте и устаревших материалах давать кому то рекомендации.
8й друпал на столько сильно был (и продолжает) переписан, что это уже абсолютно другой новый продукт.
Соответственно релиз 8й версии как-нибудь 0.9 Beta.
Вы уж меня простите, но каждый раз когда мне приходится работать с друпалом (а прошлый проект делался именно на друпале, причем на голосовании, на чем делать проект, все, кто проголосовал за друпал уволились через 2-3 месяца, при этом проект длился год), мне становится грустно.
Я честно пытался его полюбить. Изучал API, прочитал пару книг, ходил на конференции DrupalConf.
Но, каждый раз у меня перед глазами стояла функциональность фреймворков (Zend, Yii и др) и я с огромным облегчением вздохнул, когда мне предложили уйти на другой проект на Yii.
Соответственно релиз 8й версии как-нибудь 0.9 Beta.
Вы уж меня простите, но каждый раз когда мне приходится работать с друпалом (а прошлый проект делался именно на друпале, причем на голосовании, на чем делать проект, все, кто проголосовал за друпал уволились через 2-3 месяца, при этом проект длился год), мне становится грустно.
Я честно пытался его полюбить. Изучал API, прочитал пару книг, ходил на конференции DrupalConf.
Но, каждый раз у меня перед глазами стояла функциональность фреймворков (Zend, Yii и др) и я с огромным облегчением вздохнул, когда мне предложили уйти на другой проект на Yii.
Это «выгрызки» из ASP.NET?
Посмотрел yiiframework.com.ua/ru/news/7-materialy-konferentsii-yiiconf-v-kieve-2012 — в шоке.
В любом месте одни заплатки, засады и в каждом месте всё руками дописывать/доводить… Каждый раз изобретать велики, бррр…
С огромным облегчением останусь на Drupal, время важнее, чем программирование ради программирования при каждом чихе :).
Посмотрел yiiframework.com.ua/ru/news/7-materialy-konferentsii-yiiconf-v-kieve-2012 — в шоке.
В любом месте одни заплатки, засады и в каждом месте всё руками дописывать/доводить… Каждый раз изобретать велики, бррр…
С огромным облегчением останусь на Drupal, время важнее, чем программирование ради программирования при каждом чихе :).
Крепись, Вася. Ты ещё Симфони 2 не видел…
Ну каждому своё :) Тем более, вы сравниваете свой основной инструмент и «посмотрел» материалы с конференции. Это в стиле «Пастернака не читал, но осуждаю».
Чтобы понять, что именно вам больше нравится — надо поработать на обоих инструментах. А уж с Друпалом я заработал не один седой волос (особенно когда патчил модуль, для работы Друпала с Ораклом).
Честно говоря, мне больше нравится первый Zend
Но, Yii тоже очень неплох.
Время — да. Мне недавно подкинули халтурку, доска объявлений по аренде, я её сделал на 7м Друпале.
Т.е. небольшие проекты — идеально. Но, при больших проектах — все становится довольно печально.
Естественно это мое имхо, я знаю о монстрах, написанных на Друпале.
Однако, система роутинга в модулях — это довольно неудачное решение. А хуки, которые используются для вызова определенные части имени функций — приходится это учитывать, чтобы случайно имя функции не совпало с хуком. А недавно я голову сломал, почему Друпал версии 7.15 (последней) ругается, что нужно срочно обновить ядро. Оказалось, что у меня был самописный модуль
Но, интересные вещи есть. Крон с модулем Ultimate Cron — действительно удобен. Views — отлично, пока дело не касается чего-то изменить на уровне запросов с помощью хандлеров. CCK (в 6м на уровне модуля, в 7м включили в ядро) — тоже гуд.
Чтобы понять, что именно вам больше нравится — надо поработать на обоих инструментах. А уж с Друпалом я заработал не один седой волос (особенно когда патчил модуль, для работы Друпала с Ораклом).
Честно говоря, мне больше нравится первый Zend
Но, Yii тоже очень неплох.
Время — да. Мне недавно подкинули халтурку, доска объявлений по аренде, я её сделал на 7м Друпале.
Т.е. небольшие проекты — идеально. Но, при больших проектах — все становится довольно печально.
Естественно это мое имхо, я знаю о монстрах, написанных на Друпале.
Однако, система роутинга в модулях — это довольно неудачное решение. А хуки, которые используются для вызова определенные части имени функций — приходится это учитывать, чтобы случайно имя функции не совпало с хуком. А недавно я голову сломал, почему Друпал версии 7.15 (последней) ругается, что нужно срочно обновить ядро. Оказалось, что у меня был самописный модуль
billing, и после переименования этого модуля проблема решилась.Но, интересные вещи есть. Крон с модулем Ultimate Cron — действительно удобен. Views — отлично, пока дело не касается чего-то изменить на уровне запросов с помощью хандлеров. CCK (в 6м на уровне модуля, в 7м включили в ядро) — тоже гуд.
Cмотрел код 8 вот тут https://github.com/drupal/drupal/tree/8.x Меня убивает каша из HTML и PHP. Хочется чего то вроде http://croogo.org — структурированного и понятного, но не Cake. И в итоге, выбрать совсем нечего. Wordpres — жуткий код и игнорирование современных парадигм, Joomla :(, про дупал такие ужасы только что узнал, MODx — все красиво, пока в код не нужно лезть. Есть еще fork-cms.com — очень прилично выглядит, но я отхватил 502 ошибку при первом же переносе на новый хостинг и хрен пойми что там. Печально все. Есть еще www.pyrocms.com, но опят же, не хочется загонять себя в рамки Codeigniter и иже с ним. Пол царства отдам, за CMS на Laravel с копозером
Каша из HTML и PHP? Это где?
MODx — все красиво, пока в код не нужно лезть
А можно подробнее, что там некрасивого, если залезть в код? Просто интересно.
Очевидно, непонятные буковки. =)
Как обычно каждый сторонник какой-то системы видит говнокод в конкурирующих. Это как в том неприличном стихотворении Пушкина. =)
Как обычно каждый сторонник какой-то системы видит говнокод в конкурирующих. Это как в том неприличном стихотворении Пушкина. =)
Код хороший. Сама идеология системы не устраивает. Править код в админке — это ересь. Не холивара ради. Я согласен, что MODx хороший вариант, пока не нужно, что то что не входит в ее функционал.
Во-первых, уже почти год, код можно хранить в статике и работать с ним через любимую IDEшку. И мы сейчас разрабатываем плагин по управлению статическим кодом, который будет позволять подхватывать файловую структуру исходников и автоматом ее запихивать в админку.
Во-вторых, MODX, как никто заточен под разработку кастомных решений.
Во-вторых, MODX, как никто заточен под разработку кастомных решений.
Весь код легко выносится в файлы и правится через FTP/SFTP. В дальнейшем, на продакшене файлы можно убрать и все будет в БД + кэш.
В функционал MODX Revolution не входит практически ничего — она поставляется без расширений. Думаю, вы его просто не видели и говорите про Evolution — а это совершенно разные вещи.
Заметка по ссылке — очень глупая, и опять же, она строго про Evolution.
В функционал MODX Revolution не входит практически ничего — она поставляется без расширений. Думаю, вы его просто не видели и говорите про Evolution — а это совершенно разные вещи.
Заметка по ссылке — очень глупая, и опять же, она строго про Evolution.
На хабре 3 здоровых статьи о том как написать расширение для modx «Doodles» (болванки), использующем пользовательскую таблицу базы данных для хранения объектов, называемых «Doodles», которые имеют имя и описание. И получается, что проще, быстрее и приятней решить задачу том же Yii. Опять же, оговорюсь, что функционал у MODx очень большой и проблему начинаю возникать, только когда нужно что то выходящее за рамки
Вы сравниваете полноценный фреймворк с CMF. Давайте не будем путать теплое с мягким.
Как-то сложилось представление, что CMF это полноценный фреймворк + уже реализованные сущности типа страниц, навигации по ним и прочие типовые задачи, а главное админка для управления ими.
Тогда предложите мне, как разделить Drupal/MODX/TYPO3 и YII/Kohana/Symfony. Вот Симфони называет себя Web Framework, например, Kohana и Yii — PHP Framework.
Даже не в названиях дело, вы правда считаете что проекты, разграниченные мной на условные группы можно сравнивать за рамками этих групп?
Даже не в названиях дело, вы правда считаете что проекты, разграниченные мной на условные группы можно сравнивать за рамками этих групп?
Так и разделить, первая группа — просто фреймворки (говорим php — подразумеваем веб), вторая — CMF. Грубо говоря, вторая — это первая с предустановленными модулями/плагинами/бандлами, реализующими функциональность CMS из коробки.
Ничего не понял. Первая — Drupal/MODX/TYPO3? Вторая — Yii/Kohana/Symfony?
Наоборот. В общем CMF это пересечение возможностей и функциональности фреймворков и CMS. С одной стороны — гибкость и простота расширения в любом месте процесса преобразования запроса в ответ, с другой — из коробки уже реализованы сущности и способы управления ими, специфичные для типичных сайтов, такие как «страницы», «меню» и т. п.
Писать так расширения нужно только, если вы хотите положить их затем в общий репозиторий. Поверьте мне, я их много написал.
MODX позволяет писать на чистом PHP и проблемы могут возникнуть только, если ваша задача выходит за рамки этого языка программирования.
MODX позволяет писать на чистом PHP и проблемы могут возникнуть только, если ваша задача выходит за рамки этого языка программирования.
Вот за что обожаю хабр, так это за объективные комментарии и расстановку всех точек над и.
Теперь заинтригован почитать следующую статью автора (продолжение) — какую CMS/CMF использовать в качестве основного инструмента.
Теперь заинтригован почитать следующую статью автора (продолжение) — какую CMS/CMF использовать в качестве основного инструмента.
Нельзя построить нормальную архитектуру поверх сломанной (PHP) инфрастуктуры языка.
Она сломана только у тех, у кого умение обращаться с РНР начального уровня.
Достаточно долго писал модули для друпала. Потому перешел на руби и рельсы.
Понять ограниченность языка используя только этот язык — в принципе невозможно. Тут все как у психиаторов: «нельзя вылечить себя находясь внутри» (с)
Например, у ruby, более пресказуемое поведение в плане языка чем у PHP. И core libs тоже более логичные.
Хотя конечно написание модулей для Drupal — несложное (если хотя бы одну книжку по архитектуре друпала целиком прочитать) и денежное занятие.
Понять ограниченность языка используя только этот язык — в принципе невозможно. Тут все как у психиаторов: «нельзя вылечить себя находясь внутри» (с)
Например, у ruby, более пресказуемое поведение в плане языка чем у PHP. И core libs тоже более логичные.
Хотя конечно написание модулей для Drupal — несложное (если хотя бы одну книжку по архитектуре друпала целиком прочитать) и денежное занятие.
А пробовали symfony, yii, kohana, zf?
На kohana очень давно написал какое-то поделие для бизнеса в котором я тогда работал.
В остальном все php-фреймворки казались мне какими-то… уродливыми чтоли, вроде и правильно все, но получается много шума и лишних движений.
А вы пробовали писать на ruby и рельсах?
После этого php кажется где-то на уровне бейсика по отношению затраченных усилий/полученный результат.
И да, большинство MVC-фрейморков в php было слизано именно с RoR. Так зачем работать с вторичным продуктом (который к тому же фатально потерял изящность при переписывании на «плоском» php (дада тут речь про развитую рефлексию и динамичность всех сущностей в руби)) если проще и приятнее использовать оригинал?
В остальном все php-фреймворки казались мне какими-то… уродливыми чтоли, вроде и правильно все, но получается много шума и лишних движений.
А вы пробовали писать на ruby и рельсах?
После этого php кажется где-то на уровне бейсика по отношению затраченных усилий/полученный результат.
И да, большинство MVC-фрейморков в php было слизано именно с RoR. Так зачем работать с вторичным продуктом (который к тому же фатально потерял изящность при переписывании на «плоском» php (дада тут речь про развитую рефлексию и динамичность всех сущностей в руби)) если проще и приятнее использовать оригинал?
Kohana реализует hmvc, этим она мне и нравится
> большинство MVC-фрейморков в php было слизано именно с RoR
А можете теперь обосновать это? Ну к примеру, сделать таблицу всех PHP фреймворков с указанием пруф ссылки где говорится что данный фреймворк был «слизан» с ROR.
А можете теперь обосновать это? Ну к примеру, сделать таблицу всех PHP фреймворков с указанием пруф ссылки где говорится что данный фреймворк был «слизан» с ROR.
Википедию почитайте, даты появления фреймворков.
Первым поплярным MVC веб фреймворком был Spring, появившийся за пару лет до рельс. MVC там было одним из модулей, плюс это ява, энтерпрайз, совсем другой мир. Ни о каком rapid web development там не шло речи. Вернее шло, но лишь по сравнению с JavaBeans.
Всё остальное более-менее популярное тех лет из цмсок-фреймворков оперировало понятиями модулей/виджетов, пока в 2004 году гики из 37signals на никому неизвестном языке для шелл скриптов не написали ноль-какую-то версию рельс.
А дальше со всё ускоряющимися темпами оно стало набирать популярность и расползаться по другим языкам программирования.
На счёт «слизан» пожалуй говорить некорректно, скорее RoR очень сильно влиял и продолжает влиять до сих пор на технологии других языков. Хотя попытки «слизать» действительно были, но, как написал roller выше, из-за ущербности языка воплотить все концепции рельс очень трудно, и даже если выходит, то итог получается громоздкими и уродливыми(конечно по сравнению с реализацией на руби. если ты не видел другого, лучшего, то текущей уродливости просто не будешь замечать).
Первым поплярным MVC веб фреймворком был Spring, появившийся за пару лет до рельс. MVC там было одним из модулей, плюс это ява, энтерпрайз, совсем другой мир. Ни о каком rapid web development там не шло речи. Вернее шло, но лишь по сравнению с JavaBeans.
Всё остальное более-менее популярное тех лет из цмсок-фреймворков оперировало понятиями модулей/виджетов, пока в 2004 году гики из 37signals на никому неизвестном языке для шелл скриптов не написали ноль-какую-то версию рельс.
А дальше со всё ускоряющимися темпами оно стало набирать популярность и расползаться по другим языкам программирования.
На счёт «слизан» пожалуй говорить некорректно, скорее RoR очень сильно влиял и продолжает влиять до сих пор на технологии других языков. Хотя попытки «слизать» действительно были, но, как написал roller выше, из-за ущербности языка воплотить все концепции рельс очень трудно, и даже если выходит, то итог получается громоздкими и уродливыми(конечно по сравнению с реализацией на руби. если ты не видел другого, лучшего, то текущей уродливости просто не будешь замечать).
Пробовал. На рельсах я, бывает, пишу прототипы веб-приложений, деплою их на хероку, показываю заказчику и, после утверждения переписываю на symfony. Один раз только меня попросили доработать рельсовое приложение и оставить его на heroku, только домен прикрутить. На symfony мне дорабатывать было бы проще и, подозреваю, дорабатывая, я создал кучу костылей не в Ruby- и не в RoR-way'е. В частности не пользовался рефлексией и динамичностью больше, чем наследоваться от ActiveRecord::Base и т. п.
А насчёт «слизано»: имхо, нет, заимствуют удачные идеи, не более. Скажем автор symfony прямо говорил, что часть он взял из RoR, часть из Django (правда я не понял какую), а часть решил написать так как считает лучшим. А во второй версии вообще от многого наследия RoR отказался, в частности от того же ActiveRecord по умолчанию, вместо него по умолчанию DataMapper+Repository+UnitOfWork+… А вообще неудивительно, что фреймворки использующие одни и те же паттерны (MVC, ActiveRecord, Message/DynamicRouter и т. д.) похожи друг на друга.
А насчёт «слизано»: имхо, нет, заимствуют удачные идеи, не более. Скажем автор symfony прямо говорил, что часть он взял из RoR, часть из Django (правда я не понял какую), а часть решил написать так как считает лучшим. А во второй версии вообще от многого наследия RoR отказался, в частности от того же ActiveRecord по умолчанию, вместо него по умолчанию DataMapper+Repository+UnitOfWork+… А вообще неудивительно, что фреймворки использующие одни и те же паттерны (MVC, ActiveRecord, Message/DynamicRouter и т. д.) похожи друг на друга.
Мне кажется, что сравнивать Друпал с фреймворками не вполне справедливо. Да, это не просто CMS, а CMF, но все же не чистый фреймворк. Конечно, за ядром Друпала тянется длинный исторический шлейф (хотя и не такой длинный, как за Битриксом, к примеру, так как друпальцы не боятся иногда ломать обратную совместимость). Но ведь сила Друпала еще и в его сообществе: в том количестве модулей, которые для него уже написаны тысячами людей до вас.
Вот, например, я только что сделал на сайте логин c помощью социальных сетей (модуль ulogin). Но дополнительно расширил его при помощи мощнейшего модуля Rules, чтобы поля, возвращаемые из соц.сетей, автоматически записывались в нужные поля профиля. И всё это без единой строчки кода. Конечно, всё это можно написать и самому, но зачем каждый раз изобретать велосипед, если особой надобности в этом нет?
Наверное, есть и другие CMS с такими мощными модулями, как CCK, Views, Rules и пр., но я о них просто не знаю. Если в вашей следующей статье вы про них напишете, с удовольствием почитаю. А пока это не более чем необоснованная критика.
Вот, например, я только что сделал на сайте логин c помощью социальных сетей (модуль ulogin). Но дополнительно расширил его при помощи мощнейшего модуля Rules, чтобы поля, возвращаемые из соц.сетей, автоматически записывались в нужные поля профиля. И всё это без единой строчки кода. Конечно, всё это можно написать и самому, но зачем каждый раз изобретать велосипед, если особой надобности в этом нет?
Наверное, есть и другие CMS с такими мощными модулями, как CCK, Views, Rules и пр., но я о них просто не знаю. Если в вашей следующей статье вы про них напишете, с удовольствием почитаю. А пока это не более чем необоснованная критика.
Да это Цыплухин на.
А мое внимание недавно привлекла CMS Concrete5 (русский сайт). На Хабре про нее ничего не нашел, но в обзоре рынка CMS за 2011 год (на англ.) она показала фантастический рост доли рынка.
Сейчас пробую на ней сделать следующий сайт. Поковырял примеры модулей, все очень приятно выглядит, и не громоздко. Утверждается, что с этой CMS и пользователю удобно, и разработчику легко. Интересно было бы услышать мнения.
Сейчас пробую на ней сделать следующий сайт. Поковырял примеры модулей, все очень приятно выглядит, и не громоздко. Утверждается, что с этой CMS и пользователю удобно, и разработчику легко. Интересно было бы услышать мнения.
Без всяких сомнений: бесплатный вклад в разработку и интересы коммерческих предприятий — в целом, несовместимы
Совместимы. Linux тому отличный пример. Scratch your own itch.
Совместимы. Linux тому отличный пример. Scratch your own itch.
Мы все умрём! Аааа!
Статья годичной давности, а перевод баянистый, на хабре он уже был и ещё один перевод можно найти здесь.
Перед тем как критиковать автора (не переводчика), нужно хотя бы примерно представлять кто он такой.
Daniel F. Kudwien (sun) один из ключевых работчиков ядра друпала. Кроме этого, он является одним из самых продуктивных контрибьютеров в друпал сообществе. Смотрите список модулей в его профиле.
В статье описываются внутренние проблемы, которые происходили при разработке Drupal 7. В последствии эта статья стала активно использоваться в анти-друпал публикациях, причем в абсолютно перевернутом контексте.
Один важный момент, который нужно учитывать при прочтении статьи. Половина разработчиков ядра работает в одной компании (aquia). Есть мнение, что одна из причин кризиса это то, что aquia перестала уделять достаточно внимания разработки ядра друпала. А в некоторых случаях даже пыталась адаптировать его под свои коммерческие интересы. Как раз в этот период начались попытки привлечь новых контрибьютеров в разработку ядра. Со стороны это выглядело как попытка заменить качество на количество.
Drupal 7.0 вышел в январе 2011 года. И он действительно был очень не стабильным. По факту её можно было называть бетой.
Примечательно, что огромное количество багрепортов уже присутствовало к моменту выхода этой версии, но тем не менее это не остановило релиз. Дрис составил релиз план, согласно которому, Drupal 7 должен был выйти как только не останется ни одного критического бага. Мажорные баги остались на втором плане. Показательный момент, после релиза значительная часть багов была исправлена сообществом, однако, следующая минорная версия вышла только через 5 месяцев. Вероятно, из каких то маркетинговых соображений.
P.S. На данный момент актуальная версия 7.15 — вполне стабильное решение.
Можно сказать, что Drupal 7 сейчас находится в пике своей популярности и бОльшая часть пробем, описанных в статье уже не актуальна.
Сам Dan F. Kudwien iсейчас сейчас активно учавствует в разработке Drupal 8.
Перед тем как критиковать автора (не переводчика), нужно хотя бы примерно представлять кто он такой.
Daniel F. Kudwien (sun) один из ключевых работчиков ядра друпала. Кроме этого, он является одним из самых продуктивных контрибьютеров в друпал сообществе. Смотрите список модулей в его профиле.
В статье описываются внутренние проблемы, которые происходили при разработке Drupal 7. В последствии эта статья стала активно использоваться в анти-друпал публикациях, причем в абсолютно перевернутом контексте.
Один важный момент, который нужно учитывать при прочтении статьи. Половина разработчиков ядра работает в одной компании (aquia). Есть мнение, что одна из причин кризиса это то, что aquia перестала уделять достаточно внимания разработки ядра друпала. А в некоторых случаях даже пыталась адаптировать его под свои коммерческие интересы. Как раз в этот период начались попытки привлечь новых контрибьютеров в разработку ядра. Со стороны это выглядело как попытка заменить качество на количество.
Drupal 7.0 вышел в январе 2011 года. И он действительно был очень не стабильным. По факту её можно было называть бетой.
Примечательно, что огромное количество багрепортов уже присутствовало к моменту выхода этой версии, но тем не менее это не остановило релиз. Дрис составил релиз план, согласно которому, Drupal 7 должен был выйти как только не останется ни одного критического бага. Мажорные баги остались на втором плане. Показательный момент, после релиза значительная часть багов была исправлена сообществом, однако, следующая минорная версия вышла только через 5 месяцев. Вероятно, из каких то маркетинговых соображений.
P.S. На данный момент актуальная версия 7.15 — вполне стабильное решение.
Можно сказать, что Drupal 7 сейчас находится в пике своей популярности и бОльшая часть пробем, описанных в статье уже не актуальна.
Сам Dan F. Kudwien iсейчас сейчас активно учавствует в разработке Drupal 8.
Раз уж решили сравнивать Drupal c фреймворками, то надо определиться, что именно сравнивать.
Если сравнивать качество кода, то тут беспорно Drupal проигрывает, как и любая другая CMS.
Фреймворки чаще обновляются и имеют более современную архитектуру. У них меньше проблем с производительностью. Они легче адаптируются под разные задачи. И ещё, им не важна совместимость между мажорыми версиями и им не нужно поддерживать устаревшие версии PHP (Drupal 7 — PHP 5.2, Drupal 6 — PHP 4).
Если сравнивать с коммерческой точки зрения, то тут ситуациия координально противоположная.
По соотношению цена/качество Друпал в своём сегменте рвёт конкрурентов на запчасти. «Не объяснимая любовь народа к Друпалу» объяснется вполне объяснимой любовью народа к деньгам. Друпал позволяет вам в одиночку делать сложные проекты, для которых в других случаях требуется целая команда зендистов/питонистов/рубистов.
Заказчику, который умеет считать деньги, очень трудно объяснить что его друпал сайт сделал на «неправильном» коде. Особенно если этот сайт отлично работает.
Если сравнивать качество кода, то тут беспорно Drupal проигрывает, как и любая другая CMS.
Фреймворки чаще обновляются и имеют более современную архитектуру. У них меньше проблем с производительностью. Они легче адаптируются под разные задачи. И ещё, им не важна совместимость между мажорыми версиями и им не нужно поддерживать устаревшие версии PHP (Drupal 7 — PHP 5.2, Drupal 6 — PHP 4).
Если сравнивать с коммерческой точки зрения, то тут ситуациия координально противоположная.
По соотношению цена/качество Друпал в своём сегменте рвёт конкрурентов на запчасти. «Не объяснимая любовь народа к Друпалу» объяснется вполне объяснимой любовью народа к деньгам. Друпал позволяет вам в одиночку делать сложные проекты, для которых в других случаях требуется целая команда зендистов/питонистов/рубистов.
Заказчику, который умеет считать деньги, очень трудно объяснить что его друпал сайт сделал на «неправильном» коде. Особенно если этот сайт отлично работает.
Полностью согласен с автором статьи. Причем, пришел к такому заключению самолично и независимо, несмотря на то, что я приверженец и однолюб этой системы с 2007 года. Как я писал ранее:
«Главная ошибка. Зачем делать следующую версию с несовместимостью со старой по модулям? Я понимаю, что ядро надо развивать и прочее, но те разработчики, которые трудились над модулями 6-ки не станут сызнова создавать что-то для следующих версий. А именно модули, я считаю, были популяризатором системы.
Что бы я делал. Я бы оставил 6 ветку. И все время оптимизировал её. Минимизировал код, полировал. Чистил, чистил и чистил. Кроме того, привел в порядок и почистил модули. То есть удалил бы все никчемные задумки, оставил бы самые востребованные и их бы так же оптимизировал и чистил, чистил.
Когда 6 версия была бы полностью отполирована я бы продолжил модифицировать ядро. Однако, опять же с сохранением модульной совместимости с 6 версией.
А так считаю, что эстафетная палочка теперь в руках MODx»
«Главная ошибка. Зачем делать следующую версию с несовместимостью со старой по модулям? Я понимаю, что ядро надо развивать и прочее, но те разработчики, которые трудились над модулями 6-ки не станут сызнова создавать что-то для следующих версий. А именно модули, я считаю, были популяризатором системы.
Что бы я делал. Я бы оставил 6 ветку. И все время оптимизировал её. Минимизировал код, полировал. Чистил, чистил и чистил. Кроме того, привел в порядок и почистил модули. То есть удалил бы все никчемные задумки, оставил бы самые востребованные и их бы так же оптимизировал и чистил, чистил.
Когда 6 версия была бы полностью отполирована я бы продолжил модифицировать ядро. Однако, опять же с сохранением модульной совместимости с 6 версией.
А так считаю, что эстафетная палочка теперь в руках MODx»
Верно подмечено. Инициатива сейчас действительно перешла к MODX, о чем свидетельствует рост ее популярности, выражающийся в количестве установок.
Да какая там инициатива, вы что всерьёз думаете, что хоть сколько-нибудь заметная часть тех, кто разрабатывал сайты на основе Drupal перейдут на modX? Да не будет такого, максимум посмотрят, поплюются — и уйдут искать более зрелое решение. Этот продукт на голову ниже, даже 5 Drupal и ещё очень долго будет таким, даже если проблемы которые описываются в этой истеричной статье станут реальностью, а в реальности всё куда лучше, чем описано.
А чего вы так разволновались? Вы решили опровергнуть каждое взысканное здесь в пользу MODX мнение? =)
Да, я как бы и не волнуюсь, просто большинство высказывавшихся, просто не знают, о чём говорят. =)
Сделайте что-нибудь не совсем примитивное на Drupal и на modX, и сможете сравнить и понять, о чём я пишу.
Сделайте что-нибудь не совсем примитивное на Drupal и на modX, и сможете сравнить и понять, о чём я пишу.
Проблема в том, что никто не пытался здесь сравнивать MODX и Drupal. Был задана вопрос об альтернативе и дан ответ. Вот и все.
Вы настойчиво предлагаете modX, как альтернативу, не понимая, что пока это несравнимые проекты, и modX и близко не альтернатива Drupal. Я вам и предлагаю поэтому сравнить, и понять почему.
Ни разу не убедили на фоне вашей патологической не любви к MODX.
При чём тут моя нелюбовь вообще? Я не говорю, что modX так уж плох, я говорю о том, что ему ещё рости и рости, чтобы начать хоть как-то конкурировать с Drupal, особенно на проектах сложенее домашней странички или бложека, для которых есть более удачные решения чем и modX и Drupal.
Ну посмотрите вы хоть на modx.com/extras/ и на drupal.org/project/modules
Если не можете качественно оценить, оцените хотя бы количественно что-ли… А лучше посортируййте модули по популярности, и почитайте описания, и сравните с тем, как бы вы делали то же самое в modX, если уж не хотите посмотреть на Drupal вживую, и понять мои аргументы на собственном опыте.
Посмотрите также на документацию. Посмотрите на размер комюнити… Неужели это тоже вам ни о чём не говорит?
Ну посмотрите вы хоть на modx.com/extras/ и на drupal.org/project/modules
Если не можете качественно оценить, оцените хотя бы количественно что-ли… А лучше посортируййте модули по популярности, и почитайте описания, и сравните с тем, как бы вы делали то же самое в modX, если уж не хотите посмотреть на Drupal вживую, и понять мои аргументы на собственном опыте.
Посмотрите также на документацию. Посмотрите на размер комюнити… Неужели это тоже вам ни о чём не говорит?
Джон Вандюк уже в рельсах засветился, например
6-ка уже очень устаревшая, из-за совместимости с PHP4, а вы предлагаете остановить систему в развитии навсегда?
Через пару лет после такого решения Друпал вобще никто использовать не будет.
Через пару лет после такого решения Друпал вобще никто использовать не будет.
Большинство проблем Друпала, о которых здесь говорят, методом полировки не решаются.
Полагаю, что проблема «семерки» как раз в том, что разработчики не рискнули полностью оторваться от накопленного багажа и совершить действительную революцию, которая вдохновила бы авторов модулей на воссоздание их в новой версии. Получилось ни то, ни се. И совместимости нет, и нововведений мало.
В итоге многие модули так и остались в «шестерке». И вообще, у многих модулей вижу надписи «ищется новый модератор/автор». Авторы модулей отворачиваются от Друпала. И это действительно большая проблема.
Полагаю, что проблема «семерки» как раз в том, что разработчики не рискнули полностью оторваться от накопленного багажа и совершить действительную революцию, которая вдохновила бы авторов модулей на воссоздание их в новой версии. Получилось ни то, ни се. И совместимости нет, и нововведений мало.
В итоге многие модули так и остались в «шестерке». И вообще, у многих модулей вижу надписи «ищется новый модератор/автор». Авторы модулей отворачиваются от Друпала. И это действительно большая проблема.
Это не совсем так. Авторы оставляют тот или иной модуль, если теряют к нему интерес. Сейчас, функционал по работе полей, особенно, унифицируется (был унифицирован уже в версии 7), и многие модули, которые были портированы из Друпала 6, стали ненужными, и их поддерживают минимально только чтобы обеспечить работу существующих сайтов с этими модулями.
Что касается архитектурных ограничений системы, то на самом деле, полировка тут не решает. Решает проблему переход на фреймфорк Symphony в качестве движка, который будет в Drupal 8. Это будет большой скачек, многое поменяется. И Друпал еще больше станет фреймоворком чем CMS. Но это то, чего разработчики хотят от Друпала — не просто готовую ЦМС-ку, а гибкуи и мощную систему, из которой можно собрать ЦМС-ку под нужды заказчика, и потом изменять ее, если потребудется.
Так тчо пока что Друпал развивается великолепно. Единственная возможная проблема — если переход на Symfony окажется неудачным, и система стант слишком большой или неповоротливой. Но вот разработчики уверяют, что как раз будет наоборот — система стант более ООП-шной, сдвинется сильно в сторону MVC, и станет еще более привлектельной для разработчиков.
Что касается архитектурных ограничений системы, то на самом деле, полировка тут не решает. Решает проблему переход на фреймфорк Symphony в качестве движка, который будет в Drupal 8. Это будет большой скачек, многое поменяется. И Друпал еще больше станет фреймоворком чем CMS. Но это то, чего разработчики хотят от Друпала — не просто готовую ЦМС-ку, а гибкуи и мощную систему, из которой можно собрать ЦМС-ку под нужды заказчика, и потом изменять ее, если потребудется.
Так тчо пока что Друпал развивается великолепно. Единственная возможная проблема — если переход на Symfony окажется неудачным, и система стант слишком большой или неповоротливой. Но вот разработчики уверяют, что как раз будет наоборот — система стант более ООП-шной, сдвинется сильно в сторону MVC, и станет еще более привлектельной для разработчиков.
В общем, топик перерос в холивар в стиле «Windows vs Linux», жаль.
Это Цыплухин, посоны.
Обычная ошибка архитектуры ядра — нативное MVC, т.е. отсутствие как такового MVC.
Я вообще не понимаю почему, архитекторы используют в ядре много контроллеров, из-за этого и ошибка, можно спокойно сделать один расширяемый контроллер ядра, сразу бы убрались 90% багов. Но нет, извините, это надо полностью похоронить совместимость со старыми версиями. Короче, сами пилят сук на котором сидят.
Я считаю единый контроллер не только упростит разработку, но и увеличит скоростные х-ки, и сделает легче разработку сторонних модулей. Кстати такая архитектура уже опробована специалистами — это полная революция в cms
Я вообще не понимаю почему, архитекторы используют в ядре много контроллеров, из-за этого и ошибка, можно спокойно сделать один расширяемый контроллер ядра, сразу бы убрались 90% багов. Но нет, извините, это надо полностью похоронить совместимость со старыми версиями. Короче, сами пилят сук на котором сидят.
Я считаю единый контроллер не только упростит разработку, но и увеличит скоростные х-ки, и сделает легче разработку сторонних модулей. Кстати такая архитектура уже опробована специалистами — это полная революция в cms
Статья неверно передает и истолковывает факты в корне. Когда разрабатывается система, в ней всегда много багов, и они закрываются. Когда закрываются все критчиеские баги, и остаются только незначительные и неподтвержденные баги, или редкие баги, которые возникают только в лчень редких случаях, систему выпускают, и неокторое время обкатывают. Это нормально. И то, что Drupal продолжает активно расти на западе, и всё больше компаний переходят на Drupal — тоже это показывает.
Так вот теперь по сути, в чем собственно проблема? Проблема в том, что при разработке Drupal 7 вывились философские проблемы — низкоуровневый движок системы занимает слишком много времени разработчиков Drupal. Это решается в Drupal 8 переходом на фремворк Symphony 2 в качестве низкоуровневого движка. Вот это включение мощного ООП — корректного дижка как «драйвера» для Drupal, и решает те вопросы, которые были подняты. Насколько это будет успешно — посмотрим. Но сейчас, Drupal цветет и пахнет, и проекты во всем мире переходят на Drupal толпами. Я работаю сейчас день и ночь над миграцией в Drupal, отбоя нет.
Так вот теперь по сути, в чем собственно проблема? Проблема в том, что при разработке Drupal 7 вывились философские проблемы — низкоуровневый движок системы занимает слишком много времени разработчиков Drupal. Это решается в Drupal 8 переходом на фремворк Symphony 2 в качестве низкоуровневого движка. Вот это включение мощного ООП — корректного дижка как «драйвера» для Drupal, и решает те вопросы, которые были подняты. Насколько это будет успешно — посмотрим. Но сейчас, Drupal цветет и пахнет, и проекты во всем мире переходят на Drupal толпами. Я работаю сейчас день и ночь над миграцией в Drupal, отбоя нет.
Друпал, что ни говори, действительно мощная система.
Мощная потому, что позволяет решать задачи любого уровня на приемлемом уровне абстракции — тем самым устраняя необходимость что-то где-то «подхачить» или подсунуть «чанк» (что, в принципе, одно и то же). Если же и приходится дописывать самому — то это делается штатными способами и отлично версионируется.
Что хочу сказать: Друпал как продукт — действительно бесподобен, а вот инфраструктура его с некоторых пор начинает хромать. Я связываю это с небезызвестной кривой изучения Друпала, которая с течением времени только увеличивает крутизну, тем самым замедляя скорость «обращения» юзеров в Друпал-разработчиков и мэинтейнеров. А это, в свою очередь, отражается на скорости закрытия заявок — и в конечном счёте сказывается на притоке новых адептов.
Чтобы не быть голословным, я провёл небольшое исследование. Суть его заключается в следующем: изо дня в день я анализировал (и продолжаю анализировать) количество активных заявок для ядра Друпал, двух самых крутых магазинов под Друпал (Ubercart и Drupal Commerce), Views, CCK, CTools и около десятка самых популярных (согласно официальной статистике) модулей. Для непосвящённых: статус «active» заявка имеет ровно до тех пор, пока на неё не обратит внимание кто-то из разработчиков — тогда он может или написать патч и перевести в статус «needs review», или отложить, или закрыть. Соль в том, что пока заявка «активная», это означает, что никакого внятного ответа не предоставлено. Анализируя то, как меняется количество активных заявок изо дня в день, я хотел получить представление о том, соответствует ли «человекосила» Друпал-мэинтейнеров потоку пользовательской активности. Проще говоря, возможно, Друпалу просто не хватает рук?
Текст статьи-исследования. Статья на английском — но графики в переводе не нуждаются.
Выяснилось, что количество активных заявок растёт угрожающе монотонно. И, на мой взгляд, это говорит НЕ о том, что Друпал плох. Как раз наоборот — он слишком хорош и заслуживает большего, но пока не в силах обуздать шквал интересующихся.
Кстати, друпалерам на заметку: в отличие от многих предыдущих докладчиков, у меня есть решение этой проблемы. Сайт, на котором расположена статья, является первой платформой для краундфандинга Друпал патчей. Если эта тема заинтересует, напишу статью на Хабре.
Мощная потому, что позволяет решать задачи любого уровня на приемлемом уровне абстракции — тем самым устраняя необходимость что-то где-то «подхачить» или подсунуть «чанк» (что, в принципе, одно и то же). Если же и приходится дописывать самому — то это делается штатными способами и отлично версионируется.
Что хочу сказать: Друпал как продукт — действительно бесподобен, а вот инфраструктура его с некоторых пор начинает хромать. Я связываю это с небезызвестной кривой изучения Друпала, которая с течением времени только увеличивает крутизну, тем самым замедляя скорость «обращения» юзеров в Друпал-разработчиков и мэинтейнеров. А это, в свою очередь, отражается на скорости закрытия заявок — и в конечном счёте сказывается на притоке новых адептов.
Чтобы не быть голословным, я провёл небольшое исследование. Суть его заключается в следующем: изо дня в день я анализировал (и продолжаю анализировать) количество активных заявок для ядра Друпал, двух самых крутых магазинов под Друпал (Ubercart и Drupal Commerce), Views, CCK, CTools и около десятка самых популярных (согласно официальной статистике) модулей. Для непосвящённых: статус «active» заявка имеет ровно до тех пор, пока на неё не обратит внимание кто-то из разработчиков — тогда он может или написать патч и перевести в статус «needs review», или отложить, или закрыть. Соль в том, что пока заявка «активная», это означает, что никакого внятного ответа не предоставлено. Анализируя то, как меняется количество активных заявок изо дня в день, я хотел получить представление о том, соответствует ли «человекосила» Друпал-мэинтейнеров потоку пользовательской активности. Проще говоря, возможно, Друпалу просто не хватает рук?
Текст статьи-исследования. Статья на английском — но графики в переводе не нуждаются.
Выяснилось, что количество активных заявок растёт угрожающе монотонно. И, на мой взгляд, это говорит НЕ о том, что Друпал плох. Как раз наоборот — он слишком хорош и заслуживает большего, но пока не в силах обуздать шквал интересующихся.
Кстати, друпалерам на заметку: в отличие от многих предыдущих докладчиков, у меня есть решение этой проблемы. Сайт, на котором расположена статья, является первой платформой для краундфандинга Друпал патчей. Если эта тема заинтересует, напишу статью на Хабре.
Прочитал статью немного стал нервничать тк Drupal очень нравится, кроме того раньше это была моя основная платформа для разработки. И хотя паниковать конечно не стоит, но в целом я согласен с автором. Дело не в том что кто-то фильтром в багтрекере пользоваться не умеет, а меня тоже очень расстраивало когда, например после выхода очередной версии еще несколько месяцев приходится ждать когда появится более менее стабильная версия сторонних модулей. Конечно можно написать и свой модуль, но вы представляете написать свой cck? на это нужно куча времени и денег.
И вот проходит какоето время, основные баги пофиксили, все вроде подтянули свои версии, набили руку на новом api и тут опять выходит новая версия Druapl (facepalm), опять куча баг, опять проблемы с секурностью в Views. Я не к тому что новая версия это плохо, я только за прогресс, если сообщество так отстает по скорости разработки и фиксов зачем так часто выпускать новые версии? Чтобы мы могли збить больше денек с заказчика? Шеф вышла новая версия Druapl, еще быстрее, еще мощнее надо обновится!
Лучше CMF чем друпал не видел, но и такого количества багов и важных модулей в версии dev и beta тоже.
И вот проходит какоето время, основные баги пофиксили, все вроде подтянули свои версии, набили руку на новом api и тут опять выходит новая версия Druapl (facepalm), опять куча баг, опять проблемы с секурностью в Views. Я не к тому что новая версия это плохо, я только за прогресс, если сообщество так отстает по скорости разработки и фиксов зачем так часто выпускать новые версии? Чтобы мы могли збить больше денек с заказчика? Шеф вышла новая версия Druapl, еще быстрее, еще мощнее надо обновится!
Лучше CMF чем друпал не видел, но и такого количества багов и важных модулей в версии dev и beta тоже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему не Drupal?