Пользователь
30,2
рейтинг
11 сентября 2011 в 17:01

Разработка → Кризис Drupal перевод

В последнее время наметились довольно очевидные признаки того, что можно назвать критическим этапом в развитии Drupal.

Февраль 2008: началась разработка Drupal 7.

Октябрь 2008: 285 незакрытых багов для Drupal 7.

Март 2009: Пришёл специалист по переделке интерфейса Drupal 7 (D7UX).

Июнь 2009: 3120 незакрытых багов (13 763 в общей сложности).

Сентябрь 2009: Первоначально предполагалось заморозить код на этом этапе, но решили разработать (с нуля) ещё 10 новых фич и включить их в состав Drupal 7.

Январь 2010: Вышла первая альфа Drupal 7, полная критических багов в новых APIs, но ещё больше багов в вышеупомянутых новых фичах.

Июль 2010: Слишком много багов и потеря фокусировки; Drupal вводит новую категорию «основных» багов, чтобы хоть как-то выделить самые приоритетные из этого огромного количества.

Октябрь 2010: Вышла первая бета Drupal 7.

Январь 2011: Вышел Drupal 7.0, с более чем 300 незакрытыми «основными» багами и без возможности нормального апгрейда.

Май 2011: Для Drupal 8 назначен второй человек для обработки баг-репортов, чтобы справиться с багами из Drupal 7.

Июнь 2011: Более 200 критических и «основных» багов переименованы в «нормальные».

Июль 2011: Новое ограничение на максимально допустимое количество критических багов (15) и основных багов/задач (200) эффективно блокировала прогресс в разработке Drupal 8.

Август 2011: 4153 незакрытых багов (22 181 всего — почти вдвое больше, чем два года назад), апгрейд по-прежнему затруднён для многих пользователей, застрявших на Drupal 6, близкий к нулю прогресс в разработке Drupal 8.

Только в новых модулях Dashboard, Shortcut, Toolbar и Overlay насчитывается более 150 незакрытых багов. Эти модули были сделаны с нуля после заморозки кода (что неудивительно, если учитывать, что их дизайн был спроектирован всего за шесть месяцев до этого), их частично пришлось переписывать, и именно они оказали серьёзное влияние на задержку выпуска Drupal 7.

Из-за D7UX и решения сделать новый функционал в последний момент была демотивирована большая группа ключевых разработчиков, в том числе поэтому до сих пор не закрыты многие важные проблемы в API и подсистемах ядра Drupal.

В новых подсистемах Drupal 7 заложена большая сложность и взаимозависимости, в результате чего новички не могут в этом разобраться и помочь с закрытием багов. Почти все баги требуют глубокого знания подсистем и полного понимания последовательности действий. Если не получить поддержку опытных ключевых разработчиков, то вряд ли есть шансы продвинуться вперёд в разработке Drupal 8. В то же время большое количество этих ключевых разработчиков сейчас работают над несущественными частями проекта, снизив свой вклад в разработку ядра практически до нуля. 19% ключевых разработчиков, включая двух человек, имеющих право вносить изменения в код, являются теперь штатными сотрудниками одной компании, что угрожает конфликтом интересов сейчас и в будущем.

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

Есть только одна возможность вернуть контроль над проектом:
  1. Сделать drupal.org/project/standard новым путём по умолчанию для загрузки Drupal.
  2. Избавиться от лишнего функционала в ядре и обеспечить поддержку остального.
  3. Прекратить заботиться о мелочах, а сконцентрироваться на реальных и кошмарных огрехах в дизайне ядра.
  4. Окончательно и бесповоротно принять новую архитектуру ядра Drupal, сделать его простым и быстрым. Не нужно больше ностальгического балласта.
Хватит красить губной помадой огромную свинью! Нет никакой возможности поддерживать существующего кошмарного монстра с недоделанным функционалом. Ключевым разработчикам уже надоело слушать сказки о том, что со всеми багами можно справиться за счёт маркетинга и привлечения новых контрибьюторов. Чем больше мы будем верить этому, тем дольше придётся ждать релиза Drupal 8.
Перевод: Daniel F. Kudwien
Анатолий Ализар @alizar
карма
749,5
рейтинг 30,2
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (209)

  • –73
    «Нет никакой возможности поддерживать существующего кошмарного монстра с недоделанным функционалом» — пора бросать его и переходить на Joomla!
    • –37
      Рекомендую обратить внимание на движок Wiki Media. У него есть очень важное преимущество — справляется с огромными нагрузками и быстро генерит страницы. А далее нанимаете программиста и он из этого делает конфетку по вашим требованиям. :)
      • +10
        Проще написать свой движок, нежели сделать из вики что-то удобное в использовании :-)
        • –3
          И кстати это правильно. Потому что открытые движки атакуются постоянно. Просматривая логи, каждый день натыкаюсь на атаки, которые выискивают известные файлы, известных cms на предмет дырок и багов. Я думаю, если бы использовали для своих клиентов известные cms — уже давно бы поломали клиентов, отсюда и репутацию. Я не думаю, что у нашей студийной cms нет дырок, но так как она закрытая — найти их очень тяжело.
          • +2
            Старый добрый миф о надёжности closed source.
            • 0
              Ну почему сразу миф? Факты говорят о противоположном.

              Хотя, можно допилить и известные os cms и их использовать, но надо большие ресурсы и провести хороший рефакторинг кода.

              Например допилиленный Drupal используют в органах власти США (например яркий пример whitehouse.gov)

              Но я думаю там от друпала осталась только задумка архитектуры :)

              А обычные студии, используют os cms и в особенности их дополнения без каких либо проверок кода. Поэтому таким студиям лучше использовать cs

              Кстати по логам я заметил, что drupal на взлом ищут меньше всего.

              И кстати баги и дырки — разные вещи, не всегда можно воспользоваться багом как дыркой в обороне.
              • –2
                ваших говносайтов урлы в студию
            • 0
              Это не миф, на то есть объективные причины:

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

              2. Поиск багов в коде все-же гораздо проще поиска их с помощью проверок «черного ящика». Есть, конечно, стандартные косяки, но их пропускают только неопытные разработчики, чтобы найти то, что пропустит опытный, очень желательно иметь перед глазами сырцы. С ними будет существенно проще.
              • 0
                То есть вы вот просто пришли, и сказали что Security through Obscurity рулит?
                А мужики-то не знают.

                Сообщество Drupal, состоит не только из кодеров, там есть и QA-энтузиасты.
                А половина шарашек со своими наколенным CMS, либо не представляют себе необходимость полноценного QA, либо просто не могут его себе позволить.

                Закрытый код никогда не будет безопаснее открытого за счёт закрытости.
                Но это и не значит, что открытый — априори безопасней.

                PS Drupal не юзаю.
                • 0
                  Код может и будет, это логично. Не априори, но в целом, что больше ломают, то лучше и латают, как минимум, известные дырки проще латать.

                  Но вот конкретный проект не масштабов вконтакте, будет взломан с гораздо меньшей вероятностью, если он сделан толковыми специалистами без использования стороннего кода. В итоге, из идеологических соображений, проект на основе опенсорсного фреймворка/цмс будет безопаснее, а из практических — безопаснее свой код.
                  • 0
                    Где эта грань, когда вы «неуловимый джо» с закрытым кодом?

                    Любой проект хочет расти. И проекты с StO — просто оттягивают свои проблемы на более поздний срок.
                    Вот мы сейчас с вами возьмем, и just for lulz поломаем maxic его сайты.
                    Или это сделают его конкуренты. А может и не поломаем, ибо лень.

                    Нужна методика оценки рисков, в том числе будущих, чтобы быть уверенным в своей ненужности безопасности.
                    • +1
                      По сравнению с аудиторией всех сайтов на том-же Друпале и количеством людей, что хотят их сломать, имея перед глазами сырцы фреймворка, почти все проекты являются такими Джо. Вопрос в другом. Вероятность перейти дорогу кому-то на столько, чтобы для взлома привлекались высококлассные специалисты, очень небольшая. А вот прозевать апдейт и нарваться на школьника, что скачал свежий экплоит, гораздо реальнее.

                      Взломы крупных проектов чаще идут через открытый софт. Например, сервера украинского партнера icq взломали через phpbb, в котором не накатили какой-то небольшой апдейт и перебор экплоитов привел к обнаружению уязвимости. Тогда как через самописный код в Украине я не слышал, чтобы что-то крупное ломали.
                      • 0
                        Вероятность перейти дорогу кому-то на столько, чтобы для взлома привлекались высококлассные специалисты, очень небольшая. А вот прозевать апдейт и нарваться на школьника, что скачал свежий экплоит, гораздо реальнее.

                        Теперь мне ваша мысль понятна, спасибо )
    • +30
      Уж лучше Друпал. Джумла для меня — страшный сон. Конечно, может быть всё в корне поменялось в Джумле со времён 1 версии, но «неприятный осадок остался».
      • –34
        Конечно, поменялось. Я друпалом не пользовался, и ничего не имею против него, но, судя по описанному выше, это ужас какой-то. В жумле ничего подобного нет.
        • +15
          Может вы просто не ныряли достаточно глубоко?
          • –21
            Да нет, я достаточно плотно жумлой пользуюсь уже года 2.5. Даже простенькие какие-то модули пописал.
            • +25
              «достаточно плотно жумлой пользуюсь» != «Даже простенькие какие-то модули пописал»
              • –20
                Зависит от степени задротства. Для меня это плотно, для того, кто разобрал всю жумлу по кусочкам — нет.
        • +15
          «я не знаю как надо — но у вас точно не так...»
          • –27
            Комментарий — говно.
        • +9
          Ничего, что Drupal — это CMF и дает гораздо большие возможности? Joomla как бы даже не на одной полке с Drupal.
          • –7
            en.wikipedia.org/wiki/Content_Management_Framework

            А составители таблицы и не знали про «гораздо большие возможности». Пичальки-то какие :-(
            • +4
              Туда даже WordPress впихнули, так что составители таблицы местами перегнули палку.
              • 0
                И чем это WordPress не CMF? Вполне себе.
                • 0
                  А чем микроскоп не молоток? Вполне себе можно гвозди вбивать.

                  Не знаю как там в друпале, но в WP если нужно сделать что-то большее чем блог или сайт визитку, например магазин, то нужно нехило все поковырять.
                  • 0
                    Framework он на то и framework чтобы давать инструменты для «ковыряния». Инструментов в WordPress хватает.
                    • 0
                      Магазин можно и на асемблере написать, это не делает его фреймворком. В вордпресе тоже можно плыть против идеи разработчиков, и делать что угодно. Мне нравится вордпресс как блоговый движок и я написал под него несколько плагинов, но делать на нем что-то другое я бы не стал и другим не советовал.
                      • 0
                        Плыть против идеи как раз не нужно… Ну да ладно, видимо, каждому свое :)
            • +3
              Составители таблицы написали «это список систем, утверждающих, что они CMF», хотя на официальном сайте Joomla они честно пишут

              en.wikipedia.org/wiki/Drupal
              Type: Content management framework and Content management system

              en.wikipedia.org/wiki/Joomla
              Type: Content management system
          • –3
            Давайте реально без фанатства и joomla и drupal — это cms прошлого века.
            Они давно не отвечают реалиям. Монстрообразны и неповоротливы.
            Нужно действительно отбросить баласт и переходить на новую архитектуру.
            • +1
              На какую?
            • –1
              Боже, не когда не было такого желания минуснуть…
              • 0
                Вы разработчик? Тогда не надо громких заявлений.
                Посмотрите код, архитектуру и всё поймете.

                Неужели вы думаете, что я просто так написал коммент.
                Я за друпал слежу с самого его рождения, и еще тогда говорил, что некоторые «изыски» архитектуры приведут к не контроллируемым последствиям

                Вообще на хабре в последнее время развелось много демагогов, а не действительно IT-шников и разработчиков.
                • 0
                  Да я разработчик, и я хорошо подумал, я уже давно сказал что joomla — это папка с файлами, не более того. Все остальное я не критиковал.
        • +11
          Пастернака не читал, но осуждаю. (с)
          • –19
            Читать научись, клоун. Написано же «судя по описанному выше».
            • +9
              Про читать к вам это относится больше, хотя бы глянув на то, что у меня ник не мужской.
              • –7
                Профессия клоуна не имеет половой принадлежности, как токарь, слесарь, пекарь и иже с ними. Так что, снова мимо.
        • 0
          joomla — папка с файлами, не более того.
          • +2
            Раскрою секрет: Друпал — тоже.
      • +2
        Ну в корне или нет, но поменялось. Joomla, на мой взгляд, особых восторгов не вызывает, но инструмент вполне себе рабочий. И порог вхождения невысокий.

        Разрабатывая модули для Joomla все время ловил себя на мысли, что все то же самое можно было бы и более изящно спроектировать. А с другой стороны понятно, что CMS уже в возрасте и в угоду совместимости со старыми расширениями радикально менять архитектуру никто не будет.
    • –5
      Лучше бы отечественную разработку поддержали, cogear.ru
  • –3
    В последнее время наметились довольно очевидные признаки того, что можно назвать критическим этапом в развитии Drupal.

    Эти самые признаки были явно видны ещё года 3 назад.
    Основными на мой взгляд минусами ещё тогда были: архисложный код и весьма непонятный шаблонизатор. (про дыры и баги молчу)

    p.s. Да и проектов, базирующихся да на данной CMS по сей день, могу припомнить лишь 1 (cwer.ру).
    • +3
      А как же флибуста\либрусек?
      • +1
        Тормозит дичайшим образом…
    • +10
      а как же whitehouse.gov?
      • –14
        Я о том, что проектов ооочень мало на данной cms.
        • +7
          Почти полмиллиона сайтов это мало?
          • +19
            Если быть более точным, то ~1% сайтов работает под этой CMS.
            По популярности его превосходит только WP (с ~8% сайтов).

            У топик стартера как то каша в переводе и подаче материала, в стиле Валерии Ильиничны — «мы все умрем» ;)
            Баги — багам рознь. Есть проблемы. В основном, проблемы роста и выбора путей дальнейшего развития. На DrupalCon London об этом был разговор.

            — впечатление о DrupalCon London, от участника: drupaler.ru/2011/08/vstrecha_v_chitalkafe
            london2011.drupal.org оф.сайт конференции

            так что не нужно тут разводить на пустом месте…

            • +8
              Ник автора топика заметили?
              • +4
                А что с ним(с ником)?

                /me грешным делом подумал, что что-то пропустил и тут самого Buytaert-а перевели :)
            • 0
              Я рискую нарваться на минуса, но у Joomla 2.7%
              • +1
                Это ваше личное мнение или есть подтверждающие ссылки?
                • 0
                  Ну товарищи пишут на своем сайте и на других сайтах, прямого пруфа не нашел, но видимо основываются на данных по скачиваниям (27 миллионов) и собирают данные по мета-тегам, аналогично по друпалу и вордпресу — прям отдельной статьи с описанием методов подсчета так и не увидел, но будем надеяться что все они нам не врут.
    • +3
      какую подобную по мощности CMS можете посоветовать?
      • +31
        BolgenCMS
      • –2
        • +6
          Это сравнение автомобиля универсала с автомобилем для гонок.

          WP очень хорош для своего круга задач, так же как есть более узко-специализированные CMS/CMF Drupal, по отдельным параметрам.
          Из универсальных — Drupal пока один из лучших.
          Ну или изобретение своего велика (оно всегда лучше) и быстрее, и надёжнее, и…

          My CMS Can Kick Your CMS's Ass © :)
          • 0
            Я либо чего-то не понимаю, либо написанное вами вообще никак не вписывается в контекст

            — Если друпал так плох, на что перейти?
            — Попробуйте WordPress
            — (ваш коммент)
            • +1
              Плохи все CMS в разной степени. Все имеют недостатки и ограничения. Drupal же, наименее плох из всех.
              Вам нужен расширенный блог — ставьте WP, останетесь довольны.
              Что-то большее — Drupal.
              Возможно для себя вы найдете что-то и лучше, тогда поделитесь со всеми, буду рад ссылкам.
              • 0
                делюсь — cotonti.com :)
              • +3
                image
      • 0
        Symphony (не путать с фреймворком Symphony)
        • +7
          Symfony же!
        • 0
          В этой прекрасной cms «входной порог» выше. И это тоже по-своему прекрасно.
          • 0
            Можно поинтересоваться с чем возникают основные сложности? (заинтриговали)
            • 0
              Лично у меня сложностей нет. Они могут возникнуть у «веб-мастера», который привык разрабатывать сайт не вылезая за пределы админки CMS.
              C Symphony так не получится. Там почти нет готовых решений, но взамен дается почти неограниченная свобода и гибкость. Ну и для того, чтобы хоть как-то начать работать с Symphony, нужно хоть немного знать XSLT :)
              • +1
                Окей, спрошу по другому: шаблонизатор там сложнее чем в Мадженто?
                • 0
                  Я не знаю какой шаблонизатор в Мадженто. Тут система отдает данные в XML, а вы в XSLT шаблонах делаете с ними что хотите. То есть XSLT и есть шаблонизатор. Это сложнее чем в Мадженто?
                  • 0
                    Ну в Мадженто что-то похожее, тоже на XML базируется, мне кажется у них там какое-то адаптированное решение используется, я не стал разбираться.

                    Мне там дико нравится шаблонизатор, хотя организован он в ранних версия (<1.4) был довольно запутанно, много логики было захардкожено, но интеграция со своим дизайном была всё-равно крайне не сложной.

                • +1
                  XML/XSLT там шаблонизатор, в Magento вроде native PHP и XML для логической разметки. Что сложнее, имхо, сложно сказать — первое чисто декларативное, второе гибридное. Наверное от предыдущего опыта зависит.
      • +10
        MODx
      • 0
        А Movable Type нельзя ли поставить рядом с Drupal по мощности?
        movable-type.ru/

        movabletype.org/
        • 0
        • 0
          это бесплатная платформа для блогинга,… дальше закрыл
      • 0
        Я думаю, MODx или TYPO3. Как и Drupal, следуют философии «CMF с CMS надстройкой».
    • 0
      Возможно удивитесь — www.whitehouse.gov, я лично удивлен был.
    • +1
      Вот вам, и это некоторые русско-язычные www.drupal.ru/node/66640
    • +1
      а как же dev.twitter.com?
  • +17
    А зачем распыляться и начинать делать drupal 8, если 7 ещё не готов?
    • +3
      А это, видимо, стало модным — объявлять о мажорном релизе после латания дыр и прочих багфиксов. Яркий пример — Chrome и Firefox
      • 0
        Может конечно ошибаюсь, но по-моему с Вистой тот же косяк был: она вышла настолько отвратной, что поспешили сделать Win7.
        • 0
          не совсем так, просто дедлайн подходил и нужно было что-то релизить, вот и выпустили промежуточный вариант
  • +15
    Это грустно. Мне очень нравится Drupal.
  • +4
    RIP?
    • +4
      Fork
      • +12
        а смысл говнокод форкать?
        • +3
          шестая версия мне нравилась и даже очень
          • +1
            Не всегда то, что красиво обладает достаточной гибкостью и изящностью внутри. Имхо, это бич многих коммюнити-проектов. В погоне за новыми плюшками и свистелками проект трещит по швам и громко плачет о рефакторинге, а мышки продолжают есть кактус.
            • +2
              ну здесь полностью поддерживаю. Друпал — монстр. Я всегда говорил, что Из Drupal CMS, как дистрибутив из LFS
          • +1
            До сих пор пользуюсь для своего сайта — пробовал семерку — не то…
  • +3
    А на что сваливать то?
    • –9
      WordPress совсем неплох. И, вопреки пропаганде, не так уж прожорлив. И баги в нем находят не часто.
      • –8
        Поддерживаю Wordpress, За всю его историю он так не печалил, как та же Joomla. Думал изучить Drupal но теперь понимаю, что лучше дальше работать с WP и не разбегаться. А на счет прожорливости, может так оно и есть в стоковом состоянии, но тут уже вопрос оптимизации, лучше потратить время и усилия на оптимизацию WP чем латать дыры в других системах.
      • –6
        Развитие Joomla радует в последнее время
      • +12
        Вордпресс не сравнится с Друпалом по функциональности, да и сравнивать их не корректно.
        Вордпресс — это ветка на дереве.
        Друпал — это дерево со множеством веток.
        • 0
          Хм… возможно. Но не могли бы вы для наглядности привести пример того, что можно сделать на Drupal и чего нельзя сделать на WordPress? Подсказка — форум, галерею и интернет-магазин сделать можно.
          • +14
            Пример:
            1. Личные профили пользователей с возможность указания различной информации о себе (ник, аськи и тд). Все это без доступа к админке. Личные сообщения.
            2. Разграничение доступа пользователей к различным функциями, разделам, страницам.
            3. Возможность создания своих типов материалов со своими полями.
            4. Визуальное составление запросов к бд (модуль Views).
            5. Автоматизация всего что можно. Начиная от автоматической переименовании файлов (для изображений — генерация alt, title и т.д.) и заканчивая автоматическим обновлением переводов.
            6. Нет никаких ограничений (категорий — какая угодна вложенность, урл страницы — какой угодно и меняться очень просто и т.д.)

            Я два года работал с ВП и ушел с него из-за низкой функциональности. С Друпалом я ни в чем не ограничен.
            • –12
              Интересно. Ок, я готов допустить, что пункт 1 может где-то пригодиться. Но вот польза от 2-5 весьма и весьма сомнительна, а на счет 6 вы вовсе заблуждаетесь. Если бы это действительно было кому-то нужно, уже были готовые плагины. Или уже есть.

              Мне кажется, большинству пользователей мало интересно, умеет движок визуально составлять запросы или не умеет. Их куда сильнее интересует легкость установки и обновления, выбора тем и плагинов, стабильность и безопасность движка. Вот почему на WordPress работают 8.5% всех сайтов в интернете, а на Drupal — лишь 1%.

              Мне кажется (судя по вашим требованиям к гибкости движка), у вас отношение к Drupal, как к веб-фреймфорку, а не как к CMS. Но ведь есть много прекрасных веб-фреймворков. Например, Zend, Mojolicious, Catalyst, Django.
              • 0
                Ок, подскажите, как в WP разделить контент на части? Допустим я делаю сайт про автомобили, в котором есть общая лента новостей, из которой надо делать выборки по какой-либо марке.

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

                Управляться все это должно из админки ворпдресса. Для меня это пока загадка, т.к. гуй управления меню не позволяет добавлять пересечения, а только все новости. А если добавлять в него типа как произвольную ссылку а-ля /category/subcategory, то он ее не подсвечивает как активную.
                • –1
                  Не уверен, что до конца понял ваш вопрос, но по-моему с этой задачей с легкостью справятся рубрики и метки. Не подсвечивает не WordPress, а используемый вами шаблон. По шаблонам есть прекрасная документация, так что добавить подсветку любому более-менее опытному PHP программисту не должно составлять труда.
                  • +3
                    WordPress, блогодвижок, смысла затыкать им другие дырки?
                    Drupal CMS\CMF более широкого профиля.
                    У 2 движков, 2 разные цели.
                  • 0
                    Нене, вы не поняли. В меню Ворпдресса из админки нельзя добавить пересечение, например рубрики и тега. Если вставлять его как ссылку, то эта ссылка не будет подсвечиваться в меню, ей просто не назначаются нужные css классы. Поэтому приходится городить костыли.

                    Хочется простого, в редакторе меню вставить что-то вроде «все новости по рубрике А». Если подскажете, как это делать без костылей — буду благодарен.
              • +4
                Обычный пользователь, возможно, и не сможет самостоятельно воспользоваться всеми средствами для создания относительно сложного сайта на Drupal. Но всё что перечислено, реально используется разработчиками.

                Я сделал не один десяток сайтов на drupal, еще начиная с drupal 4.x, и всё перечисленное реально используется, и многое другое, разумеется, и свои модули дописываются, чтобы достичь желаемого результата.
                • 0
                  А на какой версии вы бы посоветовали сейчас делать сайт? Спасибо.
                  P.S. Мне нужно сделать новый сайт (побольше, чем визитка) для одной торгово-производственной компании.
                  • 0
                    Сделай на Joomla 1.7
                  • 0
                    Скорее drupal 7. Хотя сам делаю на 6, т.к. уже много чего сделано для 5 и 6 и городить огород еще и с 7-кой не хочется.
              • +2
                2) Разграничение прав не сомнительно, когда у вас 1(10) обычных блогера на сайте. А когда материал готовит несколько человек и каждый отвечает за свою часть…
                3) Свои типы материалов со своими полями — если вам это смнительно, то возможно вы не видели проектов с функционалом больше блога/форума

                По поводу Token-ов, таксономии, платёжных шлюзов практически ко всему, панелей, cpools, модуля фич, картографических, погодных сервисов, интеграции со сторонними базами и т.д.
                Было бы интересно пообщаться со специалистами в WP попробовать поискать аналоги для WP. Наверняка они есть.

                Drupal можно как CMS и как фреймворк использовать. Многие далеки от PHP кодинга, ставят и прекрасно работают с движком как CMS.
              • 0
                Извините, я вы представляете себе хабр без 1 пункта? Без профилей пользователей?
                Что же вы за сайты такие делаете, где не требуются нормальные профили пользователей? Только блоги? Даже для сайта визитки и то они требуются. Один для админа, другой для секретарши для обновления материалов (с ограничением доступа к системным настройкам).

                Приведу небольшую задачку, скажите пожалуйста как это можно сделать на WP:
                1. Нужны новости, в которых отдельным полем стоит Источник (для ссылки на источник новости, текст для ссылки «Источник», для ссылки автоматом прописывается rel=«nofollow». Адрес страниц для новостей: news/название_новости_транслитом. На главной новости выводится в центре страницы.
                2. Статьи. Адрес для статей: articles/название_страницы_транслитом. На сайте выводится в левом сайдбаре список из 5 последних статей с датами.
                3. Товар. Содержит поля Размер и Цена. Адрес страниц для товара: products/название_товара_транслитом. На сайте выводится в правом сайдбаре список из самых дорогих товаров, отсортированных по убыванию. Название товара — ссылка на страницу с описанием товара.

                Как это сделать на Wordpress?
                • 0
                  Создаем 3 рубрики — Новости, Статьи, Товар. Прописываем им slug — news, articles, products. Настраиваем ЧПУ — %category%/%postname%.

                  Придумываем название «произвольного поля» (вспомнил, что они все-таки есть в WP) для указания источника новости. Пусть будет «Цена». Затем — для товаров. Пусть будет «Размер» и «Цена». Подробности — codex.wordpress.org/Custom_Fields

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

                  Наконец, правим код шаблона, чтобы при просмотре товара выводил размер и цену, а при просмотре новости — источник с rel=nofollow.
                  • 0
                    s/Цена/Источник/ :)
                  • –2
                    Все правки вы предлагаете через код делать…
                    Но большинству пользователей это не интересно да и не умеют они в шаблонах ковырятся, им куда удобней все это делать через админку интуитивно понятным способом.
                    • +7
                      интуитивно понятным способом это не про друпал.
                      • –1
                        ни о чём…
                        Зная 3-4 основных вещи все остальное прозрачно понятно.
                        Большинство далеких от ИТ пользователей после полу-часового рассказа сами начинают фантазировать, что и как можно добавить на сайте.
              • +2
                >Мне кажется (судя по вашим требованиям к гибкости движка), у вас отношение к Drupal, как к веб-фреймфорку, а не как к CMS.

                Так он и позиционируется как, грубо говоря, фреймворк с админкой — множество задач можно сделать из админки, а меньшую часть (либо оптимизацию того, что изначально в админке нарисовали) — кодом. Отчасти, я думаю, низкая (относительно) популярность друпала из-за того, что «из коробки» можно сделать очень много (одна только настройка прав пользователей чего стоит) и неопытного пользователя это отпугивает.
            • 0
              3. Возможность создания своих типов материалов со своими полями. — легко и непринужденно с помощью MagicFields либо специализированных плагинов.
            • 0
              Кое-что из этого можно реализовать при помощи плагина BuddyPress, хотя вроде бы и у него косяки есть.
            • 0
              Господа, wordpress давно перестал быть движком для блогов only)
              Сейчас это такой же конструктор, как и drupal, но с гораздо более удобным интерфейсом. Так же как и в Drupal, все проблемы решаются подключением соответствующих модулей (в вордпрессе — плагинов).
              А поэтому все вышеперечисленные задачи на нем решаются, да, вплоть до составления запросов к БД. Любые типы контента (с любыми типами полей) создаются визуально (см. podscms.com). и тд. и т.п.

              Посему непонятны минусы на каждом комменте с упоминанием слова 'wordpress'
              • 0
                WP поддерживает нормальную реализацию многопользовательности? Без доступа в админку?
                Разве в WP можно создавать свои типы контента?
                • 0
                  1. Многопользовательность есть из коробки, с минимальной функциональностью. Дополнительная функциональность, а именно всякие личные кабинеты, личные сообщения, и прочее решается соответствующими модулями
                  2. Можно, называется Custom Post Types + Custom Taxonomy, гугл в помощь. Помимо этого есть и соотв. плагины, которые позволяют визуально конструировать контент и задавать правила для отображения.
          • +3
            В WordPress есть аналоги cck и views? Если не в теме: cck — модуль для создания новых типов документов с различными полями (например, статья, товар, сотрудник, мероприятие и т. д.), а views — модуль для создания список документов (например, таблица сотрудников с фио, телефоном и должностью, отсортированная по фио и фильтром по отделу).
            • –2
              В WP есть возможность делать разные cck и views. kovshenin.com/archives/custom-post-types-in-wordpress-3-0/ для начала. Второе можно делать через шаблоны страниц. Можно наделать кучу шаблонов и юзать их, привязывая шаблон к посту, списку постов или странице…
              • +1
                Судя по ссылке и небольшому гуглению, «custom post types» и списки на их основе создаются программистами на PHP (http://codex.wordpress.org/Post_Types). Для views есть какой-то аналог wordpress.org/extend/plugins/virtual-pages/, но судя по скринам, на нём не получится сделать даже пример который я привёл (таблица сотрудников).
                • –2
                  Ну да, вы в теме программируете нужные типы постов, с их полями. Для любой страницы, рубрики, тега (и т.д.) вы можете назначить свой собственный шаблон, например сделать шаблон «список сотрудников» и повесить его на страницу /peoples. Это совсем не проблема.

                  Но делается все для конкретной темы и на жуткой смеси из php+html.
                  • 0
                    «жуткая смесь» php выражается в ~10 строчках кода. А HTML в других движках, я полагаю, вы визуально рисуете прямо из админки? :)
            • 0
              Есть аналог, плагин podscms. Визуально можно конструировать любые типы контента и правила для отображения.
              Еще года полтора назад делал с его помошью archtour.ru)
              • 0
                да, плагин не единственный, есть более продвинутые, которые на уровне запросов к базе работают
          • +1
            Банально, сделать разные меню для разных частей сайта. Что бы не фигачить стопицот отдельных шаблонов.
    • –2
      typo3
      • +1
        также как и Drupal имеет высокий порог вхождения. )
        • +1
          Если инструмент дает возможность выполнять стоящие передо мной задачи, то я готов его изучить.
    • 0
      Если вы программист — проанализируйте архитектуры разных, и выбирите по душе ;)
      В первую очередь я бы посоветовал новые простые и универсальные решения, где нет разного плана привязок к выполнению и порядку кода. Где всем заведует контроллер (который сам по себе должен быть простым до безобразия), который не обрабатывает данные и понятия не знает про вывод, где нет тупых шаблонизаторов. Где нет разделения понятия модуля на еще, дополнения, виджеты, плугинсы. Все разделения усложняют архитектуру. Поверьте все это можно сделать одним понятием модуль, если сделать все согласно MVC, но не нативным способом, которым многие грешат.

      В первую очередь смотрите не на админку а на архитектуру.

      Потому что в красивую обвертку могут запаковать не конфетку а г.
  • +7
    Мда. А вот в некоторых соседних топиках почему-то при одном упоминании слова Битрикс люди оставляют комменты в духе «Зачем это говно, если есть Друпал?».
    • +2
      Все познается в сравнении :)
      • +1
        Да, меня вот любое проявление PHP-шной кухни пугает, хотя когда-то много писал на нем.
        • 0
          И на чем же пишете? Чем пхп не устроил?
          • +7
            Python. Еще пробовал Ruby, но у него по субъектиным причинам не понравился синтаксис.

            Большинство современных решений для веба на Python крайне приятны и архитектурно красивы, в их исходниках копаться просто приятно.

            Скорость разработки вскоре после перехода у меня увеличилась в несколько раз (речь идет о django, twisted и tornado), количество возникающих багов существенно снизилось. на основе Django есть 3-4 приличных CMS которых вполне хватит для разработки без кодинга.

            PHP изначально был продвинутым шаблонизатором, и это очень болезненно отразилось на его дальнейшем развитии и архитектуре большинства приложений.
            • +4
              Не, ну безусловно, если на писать на голом пхп и сравнивать с Django-основанными CMS, то да.

              Но я думаю было бы правильнее сравнивать с CMS, написанными на Symfony, Zend, Yii etc.

    • +9
      Вы просто не видели исходников Битрикса, там нечто.
      Друпал по качеству кода много кого превосходит.
      • +8
        Щас в комменты придет Рыжиков и скажет «зато есть маркетплейс и вы должны его использовать»
        • +3
          ага, мол, вы можете написать свой битрикс и выложить в маркетплейс, он будет доступен всего за 4 тыс руб.
  • +3
  • +2
    На мой взгляд, одна из его проблем это то, что он лишь в последних версиях стал использовать ООП. В процедурно-ориентированной программе гораздо больше поводов для дублирования кода.
  • 0
    Не знал, что всё настолько печально…
  • 0
    Умирает основной конкурент MODx-а?
    • +5
      не дождетесь! :)
      • 0
        Да и не хотелось бы)))
        Конкуренция — стимул прогресса
        • +4
          В какой нише конкуренты?
          Или вы хотите меня рассмешить социальной сетью на ModX?
          • –1
            А разве на Друпале только соц. сети делают?
            • +1
              Хорошо.
              Давайте просто: «В какой нише конкуренты?»
              • –1
                1. Обычный сайт обычной компании. Думаю самое распространенное применение CMS. Этого мало?
                2. Информационный портал (статьи, комментарии, регистрация, профиль...).
                3. Блог на Друпале можно сделать? Думаю да.
                4. Интернет-магазин. С этим пока туговато, но есть решения и на Drupal и на MODX.
                Так что я бы не сказал, что Drupal и MODX занимают какую-то нишь.
                • –3
                  Да, забыл самое главное
                  5. CMF.
          • 0
            В нише фреймворков.
            И могу точно сказать, что и социалку можно замутить на нем при желании.
            • +1
              %хумор% А на Друпале и без желания можно!
  • +7
    Ничуть не ставлю под сомнение авторство перевода alizar, но перевод этой статьи я уже видел более двух недель назад от пользователя graker (известен на drupal.ru, да и за кругами оного наверняка тоже). Вот статья на его блоге.
    P.S.: для зелоненавистников, переводы не совпадают дословно…
    • +1
      UPD: перечитал еще раз оба перевода. На мой взгляд, перевод от graker более близок к тексту оригинала.
    • +3
      а вот еще и продолжение
  • +13
    Советую не отвечать на комментарии WP-ников, которые не имеют понятия о том, что такое друпал и для чего его применяют. Половину того сложного, что в Drupal делается легко, в WP либо сделать вообще нельзя, либо нужно быть php-программистом с опытом.
    • +8
      Либо описывать типы контента в шаблонах темы, феерично же
    • +5
      WP хорош, но все равно это блог платформа с архитектурой блог-платформы и функциональностью, в первую очередь, блог-платформы.
  • –2
    Переходим на Битрикс.
    Ха. Ха. Ха.
    • –2
      Не ожидал получить кармическую кару в ответ на такой комментарий в блоге про Drupal =))
  • +2
    пфф… много паники. Использую drupal 7 и ничего страшного не встречал.
    • +5
      54 страницы открытых проблем только для ядра 7-й версии — фигня какая.
      Вам и в «Сапёре» везёт, наверное.
  • –11
    Люди, переходите на фреймворки. Друпал довольно тормознутая вещь.
  • –12
    Для сайтов визиток довольно хорош MODx.
  • +5
    На друпале овердофига народу делают проекты, поэтому и находят там баги, под друпал в основном клепают профи, в отличии от джумлы с их школомонстрами, которые никаких багов не найдут никогда. Друпал — хорошая cms, в ней много модулей, чтобы ни понадобилось, практически всё можно найти в нем. Кататься на велосипедах можно с удовольствием.

    p/s Сам делаю все сайты на cmsmadesimple, новая cms, с хорошей архитектурой, легкой в разработке, удобной в работе. Всем советую. Но модулей маловато, конечно, но в таком случае я их пилю сам за отдельную плату (если речь идет о сайтах на заказ).
    • 0
      А если простую и сразу всё в одном флаконе можно instantcms, но только подождите пока выйдет версия с utf-8 :)
      • 0
        Не троллинга ради — ну UTF8-то считается must have уже фиг знает сколько лет =)
        • 0
          Вы правы
          Ну это не ко мне, я не разработчик instantcms
  • –2
    ну вот я собирался на днях поковырять Drupal. Видать придется отговаривать заказчика)
    посоветуйте CMS для разработки инет.Магазина? кроме Битрекса и hostcms цены у них не подходят.
    • 0
      Сейчас вам насоветую WP и ModX
      • –3
        ну WP не совсем подходит для инет.Магазина, а с ModX я не работал. вот нашел www.phpshop.ru/ кто что может сказать про эту систему?
        • +4
          Ставь Drupal 6.0 она наиболее стабилен сейчас, и не парься.
          • 0
            Наверное имеется в виду 6.22 или просто 6, но не 6.0 (который вышел в 2008 году).
    • –1
      Для интернет магазина я бы точно выбрал Magento
  • +2
    Drupal большой!
    • –2
      тут как бы идет обсуждения не о массивности Друпала, а о его недостатках.
      • +1
        а массивность и есть недостаток. Если ядро очень массивное, над ним теряется контроль, что и произошло в конкретном случае :\
        имхо надо полностью переходить на новую архитектуру с нуля, очень сильно запутана архитектура ядра, смешались мухи и котлеты.
  • НЛО прилетело и опубликовало эту надпись здесь
  • –2
    Drupal must be going ahead
  • 0
    Как мило, любой кто тут заикается о другой CMS попадает сразу в минуса. Видимо сильно тут сообщество друпальщиков )
    Я вот скажем сейчас немного удалился от CMS в сторону фреймворков, работаю в последнее время с Yii, все конечно просто. удобно и замечательно, но тут уже и проекты другие (сайт визитку за 10 000 под ключ на фрилансе делать не будешь) и порог вхождения не такой как у CMS при работе в админке.
    • +9
      Представьте, что это статья о проблемах на телескопе Хаббла, и под ней куча комментариев типа «пацаны, а я каждый вечер смотрю на звезды в мамин театральный бинокль — такая красотища, просто дух захватывает!». :)
  • +2
    Статистические даннный в статье приведены верно, но на практике при работе с друпалом №7 проблем нету

    Аргументы:
    На семерку наша команда (20 программистов) перешли с марта
    Проекты — от тысячи часов (отнюдь не клепание визиток)
    Разработка идет довольно линейно, нерешаемых проблем нет, на баги ядра натыкаемся редко (от чего немного скучно, так как коммитов на друпал-орг ой как хочется наколлекционировать)

    Вывод:
    Друпал рулит!

    P.S. Всех с наступающим Днем Программиста! :)
  • +5
    Топик-перепись «веб-дизайнеров», делающих сайты за 3000 рублей. Поиск по ключевым словам «Wordpress», «Joomla».
    • –4
      За три тысяч рублей и пару дней как раз на Друпал можно сделать. На Джумле или Вордпрессе день максимум :)
      • +1
        Без обид, но я сочувствую вашим клиентам.
        • –2
          Клиенты довольны, всё что им нужно на сайте есть, в «их» админке нет ничего лишнего, оперируют в ней терминами своей предметной области (собственно больше всего времени и занимает создание материалов, соответствующих предметной области, плюс создание таксономии, плюс создание темы из вёрстки — темизация в друпале не самая удачная, имхо), а не страницами (страницы обычно тоже остаются) или, тем более, нодами.
        • +4
          Да уж, но самое интересное, что после этих парудней писателей сайтов, клиенты возвращаются к нам обратно и платят больше и шире сотрудничество становится. И по рекомендациям этих клиентов приходят гораздо больше новых клиентов :)

          Спасибо за ваши кривосайты за 3000 товарищи парудней писатели :)
  • –2
    С версии Joomla 1.7 имеет свою платформу, отдельную от движка.
    Описание: docs.joomla.org/Platform/11.1
    Joomla Platform on Github: github.com/joomla/joomla-platform

    С версии 1.0 до версии 1.7 очень много сделано.

    Версия 1.5 написана с нуля, как и версия 1.6.

    Обновление промежуточных версий теперь проходит каждые 6 месяцев с простім обновлением в один клик через Менеджер обновлений в административной части сайта. Эти версии называются «короткострочными» и дают возможность посмотреть какой будет функционал в «долгострочных» версиях.

    «Долгострочные» версии обновляются каждые 18 месяцев.

    С версии 1.6 переход на будущие «короткострочные» или «долгострочные» версии проходит без проблем, через обновление системы.

    С версии 1.6 убита поддержка старой версии 1.0 в режиме совместимости, которая была в 1.6, что ускорило систему в разы.

    Вообще если сравнивать сами версии (1.0, 1.5, 1.6/1.7), то ощущения того, что работаешь на разных движках — это хорошая позиция следить за развитием сегодняшнего веба и давать возможности использовать нововведения уже сейчас в самом движке.

    С версии 1.7 Joomla плотно работает с поддержкой html5.

    После «долгострочной» версии версии 1.5, следующая версия 1.8 (возможно, что версия будет изменена на 2.5 или 3.5 — об этом можно почитать здесь community.joomla.org/blogs/leadership/1479-the-version-votes-are-in.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+JoomlaCommunityCoreTeamBlog+%28Joomla!+Core+Team+Blog%29 и в других статьях) выйдет в начале 2012 года.

    В середине 2012 года поддержка версии 1.5 прекращается, что дает системе новый виток в новом развитии. Как самой системе так и разработчикам расширений.
    • +1
      Как у человека, который «в теме», хочу спросить — как там с рубриками и категориями? Будет ли поддержка пользовательских типов контента?
      • 0
        В 1.7 есть распределение прав пользователей ACL.

        На счет категорий нет понятий как раздел и категория (версия 1.0 и 1.5), присутствует вложенность категорий.

        Все компоненты, плагины, модули имеют персональные настройки ACL, которые наследуют права из общей конфигурации системы.

        Очень просто реализовано построение шаблонов через MVC.

        От себя: Недостаток, как по мне — использование Mootools, хотя мне по душе JQuery, который и использую в разработке интерфейса сайта (я не сторонник взять готовый шаблон и переделать его, полностью сам делаю дизайн, верстку, коддинг и не только под Joomla).
        • 0
          Спасибо. Обнадеживает. Joomla (я смотрел 1.5) была в свое время для меня огромным разочарованием. После Wordpress-а какое-то время было ощущение безграничных возможностей, пока не разобрался, что к чему. :)
    • 0
      В предложении:

      «С версии 1.6 убита поддержка старой версии 1.0 в режиме совместимости, которая была в 1.6, что ускорило систему в разы.»

      Я сделал ошибку — не которая была в 1.6, а которая была в 1.5
    • 0
      > С версии 1.7 Joomla плотно работает с поддержкой html5

      Без обид joomla сообществу, я видел все версии, действительно сильно изменился код, но…

      Вы извините, какая хрен разница ядру с чем работает модуль вывода (он и знать не должен об этом). Зачем переписывать ядро, если за вывод должен отвечать модуль, а?

      Ну выпустите модуль вывода работающий с html5, да хоть с html100.
      Это и есть основная ошибка многих cms — как я её называю «нативная поддержка MVC», а просто если сказать — нет там никакого mvc. Поэтому и переписывается ядро с нуля от подверсии к подверсии. Потому что понимают что в королевстве что-то не то, а что до сих пор понять не могуи, потому что, по честному, архитектурщики joomla очень слабые. Писать красивый код, еще не значит разрабатывать красивую архитектуру.
  • +1
    Знаете, почитал комментарии… Здесь каждый тянет одеяло в сторону того, к чему привык, с чем знаком и что приятнее (по каким-то личным соображениям). На самом деле же, со статистикой, приведенной в топике, спорить глупо. Откройте друпал.орг и убедитесь. Друпал становится все страшнее и страшнее. Я лично в этом убеждаюсь каждый раз, когда приступаю к новому проекту, обновляя систему. Но что делать, если времени нет на написание собственного универсального движка? Куда уйти, куда податься? Да некуда, потому, как подобного в свободном доступе нет. Сам отюзал и джумлу (с дико корявым интерфейсом админки), и вордпресс (с жутко ограниченным функционалом), и кучу других «готовых универсальных решений», но вынужден был остановиться на друпал. Пользуюсь 6.22. Удовлетворен. Мне, как дизайнеру, маловажен код. Мне главное то, что я вижу. Джумла предлагает множество готовых «тем», которые симпатичны и уже предварительно протестированы, в вордпресс также многое уже «подключ», на друпале же я начинаю верстать все с нуля, что дает мне больше возможностей для фантазии. Для меня — это в приоритете, для кого-то — другое. Здесь нет «универсальной» пилюли. Каждому своё — простая, банальная истина.
    • +1
      Чтобы сделать дизайн не нужно привязываться к движку!

      Для дизайнера — это глупо и такое писать должно быть стыдно.

      В дизайне нужно руководиться композицией, колористикой, типографикой, понимать сегодняшнии тенденции, знать что было в других стилистиках, периодах, течениях…

      Дизайнер понимает, что такое дизайн и чем нужно руководиться в создании своего детища и воплощения всевозможных фантазий.
      • 0
        Веб-дизайн уже давно перестал быть только цветовой гаммой, набором графических элементов и т.д. Веб-дизайн сейчас — это идея, концепция подачи информации. А тут уж как не крути, функционал и строение системы очень важны.
        • 0
          Веб-дизайн сейчас — это идея, концепция подачи информации.

          Ты описал, что такое дизайн, но где тут движок?

          Идея и концепция — это одно и тоже.

          Подача информации, если в визуальном представлении — это больше типографика + дизайн. Есть еще такое понятие как шрифтовой дизайн.

          То что ты написал можно отнести к веб-дизайну, полиграфическому дизайну, книжному дизайну (очень ярко тут выражено), к ландшафтному и экстерьерному дизайну, дизайну интерьера, архитектуре…

          Я бы отметил в вебе следующие направления:

          1. Веб-дизайнер работает с внешним видом и может задавать концепцию — это его прямая задача в работе с маркетологами. Креативщик — это дизайнер.

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

          3. Программист пишет код и для него безразлично какой будет дизайн и как дизайн должен быть сверстан. Задача программиста создать платформу, программу (думаю на Хабре нет смысла описывать задачу программиста словами дизайнер :) )

          Вот самая простая схема. Я не вдаюсь в подробности о менеджменте и финансах и о копирайтерах или журналистах.

          У меня складывается впечатление, что понятие слова веб-дизайн утратило свою суть в наших реалиях.

          На самом деле веб-дизанер — это дизайнер который «рисует веб». Понимает какие должны быть идеальные пропорции и композиции для веб.

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

          Веб-дизайнер не должен мыслить функционалом движка — о должен креативить. Как реализовать идею дизайнера должны думать верстальщик и программист.
  • 0
    Дело в том что на определенном этапе нужно было переходить полностью на новую архитектуру (все же архитектура друпал довольна стара по современным меркам) и новую политику юзабилити (чем друпал всегда страдал).
    Это относится ко многим проектам.
    Да будет большая проблема. Все модули и темы для новой версии не подойдут. Но есть и выход — написать «конвертеры» и т.п.

    С каждым обновлением версии cms становилась всё монстрообразней и тянула за собой ошибки архитектуры старых версий, чем повлекла за собой рождение новых багов.

    Просто побоялись — и вот итог.
    • 0
      чем она стара? укажите конкретнее…
  • 0
    На Lullabot пообсуждали, да и топ разработчики типа Sun высказались

    Работа с друпалом идет. Радует, что мои инициативы/патчи в ядре )

    7ка работает. Производительность возросла. Багов не встречал, но вот модули некоторые совсем сырые. Активно приходиться писать багрепорты/патчи. И замедлился выход новых релизов и модулей факт! Но я связываю это с переходом с CVS на git

    8ка вообще радует инициативами — повыкидывать все лишнее.
  • 0
    p.s. Да и проектов, базирующихся да на данной CMS по сей день, могу припомнить лишь 1 (cwer.ру).


    www.whydrupal.ru/drupal-sites

    drupalogy.ru/gallery/top100
  • +1
    Существует устойчивое мнение, что движок Друпала более тормозной, чем Джумловский.

    Я лично с этим не согласен, но не проводил ли кто тесты?

    Хотя тоже вопрос, какие версии сравнивать и так далее.
  • 0
    Не вижу смысла в друпале, ибо:

    1) хочешь сделать веб-приложение => используй нормальный фреймворк
    2) хочешь сделать сайт => используй CMS (тот же wordpress подходит для 99.9% задач)

    drupal — ни туда, ни сюда.

    imho
  • 0
    Ещё один разработчик ядра Друпала попросил отставку.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.