Drupal 8 — революционные изменения

    image В быстро меняющемся мире IT, да и не только, выигрывают те, кто постоянно развиваются: остановился — значит проиграл. Это справедливо в частности и для CMS. Стараясь идти в ногу со временем, не за горами выход новой версии CMS Drupal 8.

    На данный момент, доступна 3 альфа версия Drupal 8. Было создано несколько инициативных групп, работающих над основными направлениями: Управление конфигурациями, Дизайн, Мобильные устройства, Многоязычность и Вебсервисы. Ядро сейчас имеет 1600+ контрибутеров (это примерно в два раза больше чем было у Drupal 7). В новой версии сделано более 500 нововведений и изменений. Ниже я упомяну, по моему мнению, наиболее значимые из них. Изменения описываются по отношению к Drupal 7, т.е. предполагается что читатель знаком с Drupal 7.


    Изменения доступные через интерфейс


    Сделано много улучшений в интерфейсе по умолчанию — что упростит использование CMS не профессиональными пользователями. Так как наиболее востребованная функциональность добавлена в ядро, практически есть все необходимое из коробки, для построения “среднего” веб-сайта без использования сторонних модулей. Что позволит использовать 8-ку сразу после релиза, не дожидаться выхода основных модулей, как это было для предыдущих версий и обычно занимало около 6 месяцев. И так, изменения:

    Inline редактирование
    Редактирование контента становится очень простым и удобным: кликнув по значку карандаша, возле нужного контента — он становится доступным для редактирования, конечно если у вас есть соответствующие права.

    Модуль Views в ядре
    Views — это самый популярный модуль. Как показывает его использование в предыдущих версиях Drupal, использование новой версии Drupal значительно возрастает после выхода именно этого модуля.

    Встроенная мультиязычность
    Для полного использования мультиязычности в предыдущей версии Drupal нужно было дополнительно установить около 5 дополнительных модулей, сейчас мультиязычность поддерживается в ядре в полном объеме. В 8-ке можно, заменить язык по умолчанию — английский на другой.

    Встроенный CKEditor редактор
    Удобный текстовый редактор теперь доступен из коробки.

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

    Адаптивный дизайн для встроенных тем
    Встроенные темы теперь являются адаптивными и готовы для использования на мобильных устройствах.

    Новый тулбар
    Тулбар полностью переделан и теперь стал адаптивным, более удобным и интуитивным.

    Возможность изменения отображения формы ноды
    Изменять отображение формы ноды, теперь можно без написания кода.

    Новые типы полей
    В ядро встроены дополнительные часто используемые типы полей: Entity Reference (позволяет устанавливать связь между контентами), Date (для событий ), Link, Telephone, Email, Picture.

    Система управления конфигурированием
    Полностью переделана система конфигурирования и теперь данные о настройках храняться не в базе, как это было раньше, а в файлах. Что позволяет легко экспортировать/импортировать настройки, использовать разные настройки для разработки и релиза а также, хранить данные в системе управления версиями.

    Часть модулей удалена из ядра
    Это модули: Dashboard, Poll, Blog, Profile, Open ID, PHP filter, Trigger. В большинстве, эти модули сейчас доступны отдельно.

    Апгрейт с предыдущих версий
    Для обновления с предыдущих основных версий, в ядро интегрирован модуль Migrate, который позволит напрямую обновляться с 6, 7 до 8.

    Изменения для разработчиков


    Наибольшие изменения касаются разработчиков, так как делается отход от привычной для Drupal технологии разработки в сторону ООП и использования компонентов Symfony2.

    Всем известна крутая кривая изучения Drupal. Использование ООП — должно сделать изучение более простым и доступным. Ядро Drupal, еще никогда не было так хорошо документировано, благодаря отличной документации компонентов Symfony2.

    Использование ООП
    Хотя ООП частично использовалось и раньше, в 8-ке официально принято использование ООП. Начат постепенный отход от процедурного программирования и использования хуков, которые применялись в времена когда ООП еще небыло доступно в нужном объеме в PHP. В связи с этим появляется много новых, для Drupal, концепций и понятий. Для пространств имен принято следовать стандарту PSR-0 (чуть позже, возможно PSR-4). В 8-ке не будет сделан полный переход к ООП и частичное наследие в виде процедурного кода еще останется, но это будет осуществлено в Drupal 9.

    Использование компонентов Symfony2
    Одним из главных нововведений в 8-ке, является использование компонентов Symfony2:

    • HttpFoundation и HttpKernel — одни из основных компонентов, с которых началась интеграция Symfony2 в Drupal. Преобразовывает все что связано с HTTP при запросе и ответе — в объекты;
    • Routing — преобразовывает HTTP запрос в вызов определенной функции, подобно hook_menu;
    • ClassLoader — используется для загрузки классов по мере необходимости;
    • DependencyInjection или Service Container — позволяет сделать классы независимыми, и тем самым делает их доступными для повторного использования и юнит-тестирования;
    • EventDispatcher — реализует паттерн Наблюдатель (Observer). Делает тоже самое что и система хуков, но на данный момент, не заменяет их полностью;
    • Yaml — позволяет работать с форматом yaml;
    • Twig — новый удобный, мощный движок шаблонов;
    • Serializer — преобразование объектов в определенный формат и обратно;
    • Translation — система переводов;
    • Process — используется для выполнения в субпроцессе, команд из консоли;
    • Validator — компонент, для проверки значений;

    Composer
    Менеджер зависимостей, который используется для скачивания и поддержки в актуальном состоянии используемых библиотек, компонент проекта.

    Движок шаблонов Twig
    Предыдущий движок шаблонов Phptemplate, часто критиковался за неудобства работы с ним, использовании PHP вставок, плохую защищенность. Twig не только лишен этих недостатков, но так же имеет и много преимуществ: прост в изучении, гибок, шаблоны легко читаемы, cловом сплошное удовольствие для темизатора.

    Система конфигурирования
    Как упоминалось выше, система конфигурирования полностью переработана и сейчас данные хранятся в текстовых файлах, в весьма удобном формате yaml.

    PHPUnit
    Добавляет возможность юнит-тестирования, которое современем заменит Simpetest.

    Новая концепция блоков
    В 8-ке, блок — это сущность (Entity), с присущей ей свойствами: создания дополнительных полей, типов блоков, версий.

    RESTful сервер
    Из коробки, Drupal 8 может работать как REST сервер и обслуживать множество устройств.

    Другие сторонние компоненты

    • Doctrine — используется не в полном объеме, а лишь небольшая часть — Annotations. Которая добавляет возможность использования аннотаций, например для конфигурирования плагинов;
    • EasyRDF — компонент используемый для добавления RDF и тем самым приближая семантический веб;
    • Assetic — фреймворк, который используется при скачивании страницы или другого контента, для сжатия и/или преобразования данных;
    • Guzzle — http клиент;
    • PSR/Log — система логирования;

    Плагины
    Плагин — это класc который предназначен для дополнения работы ядра или модулей, и по сути является заменой хуков info. Плагин не является отдельным компонентом и входит в состав модуля, в котором может быть много плагинов.

    Изменения нужны не всем


    Как известно, люди противятся любым изменениям — даже хорошим, так как это выбивает их из накатанной колии и заставляет покинуть зону комфорта. А в данном случае заставляет заняться изучением — что само по себе является весьма полезным, тем более в свете недавней статьи.

    Упомянутые нововведения, предположительно связывают с тем, что Drupal 8 движется к корпоративному рынку, где будут больше востребованы профессиональные разработчики. Часть разработчиков, которым не хочется сложно освоить новую архитектуру и технологию разработки, такой ситуацией не довольны. Поэтому, был сделан форк с Drupal 7, который назвали BackDrop CMS. Это не есть чем-то новым для Drupal, форки делались и раньше, но ни один из них так и не стал популярным. Создатели BackDrop планируют развивать его более “спокойным” способом, но также планируют постепенно использовать ООП, подключить движок шаблонов Twig или написать подобный. Думаю, самым сложным, будет поддерживать BackDrop после окончания официальной поддержки Drupal 7 (а это будет после выхода D9).

    Вместо заключения


    Приведенный список изменений является далеко не полным, ознакомиться подробней можно здесь. Работа над Drupal 8 пока не завершена, предположительный выход — первая половина следующего года. Желающие опробовать последнюю версию уже сейчас могут получить пререлиз отсюда или с репозитория.
    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 70
    • +5
      А картинки?) Революционные же изменения, а скриншотов нет
      • +14
        Вот наиболее подходящая

        • 0
          Ну как же без этой картинки)) — это касается предыдущих версий.
          8-ка должна уменьшить порог вхождения, сделать процесс обучения более легким и стандартным.
          • 0
            Ага, в левом верхнем углу как раз те, кто работал с друпалом 7 и не работал с симфони.
            • 0
              Я начал знакомство с Друпалом как раз с восьмёрки. В общем-то, одного рабочего дня ковыряния мне хватило для овладения админкой и всякими настройками.
          • +2
            Ну, если следовать тенденции, то они просто сделали все плоским и убрали градиенты )
          • 0
            Как я понимаю, в версии 8 как и в версии 7 будут интегрированы модули которые были сторонними. С одной стороны удобно, с другой стороны, это все больше напоминает CMS, а не CMF.
            • +2
              Никто не заставляет их включать.
              Вопрос тут в другом, после релиза модули ядра будут заморожены в развитии до следующей версии Drupal. Поэтому включаемые в ядро модули должны быть настолько прекрасны, чтобы в них уже ничего не хотелось менять, но можно было расширять через API.
              Плюс концепция Drupal garden, когда несколько сайтов крутятся на одном ядре с разными базами. Всем нужен views, так пусть он будет уже в ядре.
              Ну и в конце концов более строгий контроль кода. Третьего дня я плевался, глядя на код Panel. Прекрасный по концепции модуль, но реализация застряла на уровне Drupal 6.
            • –7
              Лучше бы они не изобретали велосипеды с тулбарами и взяли bootstrap!
              • +1
                блин, я писал на симфони… тут пацаны правильный велосипед взяли за основу
              • 0
                Лично мне в Drupal 7 не хватает двух вещей:
                • полноценного менеджера пакетов;
                • отделения кода движка от кода сайта.

                Все приличные фреймворки позволяют создать проект (сайт) в произвольном месте файловой системы и указать для него произвольные зависимости.

                В Drupal же в 2013 году приходится делать так, как это делалось десять лет назад: создавать сайт в подпапке внутри папки движка. Если же у вас два сайта требуют разных версий одного модуля, приходится создавать два экземпляра движка.

                Управлять этим зоопарком при большом количестве сайтов настолько трудно и неудобно, что изобретаются костыли вроде Drush Make и Aegir (кстати, скоро выйдет вторая версия). По удобству пользования этим костылям до, например, bundle install как до луны.

                Судя по этому посту, ситуация не изменится. :(
                • +2
                  — «Если же у вас два сайта требуют разных версий одного модуля, приходится создавать два экземпляра движка»

                  Можно же сделать так: sites/site-1/module-v1, sites/site-1/module-v2
                  • 0
                    К сожалению, Aegir поддерживает размещение модулей, тем и библиотек только в sites/all.
                    • +2
                      Наверное, это проблема не друпала, а Aegir, что оно не поддерживает весь функционал друпала.
                      • 0
                        Разумеется.

                        Но без Aegir управление множеством сайтов, сделанных на Drupal, превращается в адский ад, так что вариантов просто нет.
                      • 0
                        У меня несколько сайтов под octpus, это «Aegir + Platforms installer». Я не проникся на 100% идеей 1 сайт = 1 платформа (зря, возможно), поэтому у меня много модулей лежит непосредственно в папках сайтов.

                        Добавляю так: $ drush @mysite.ru dl modulename --use-site-dir
                      • +1
                        А также можно сделать profiles/profile-1/modules/module-v1 и profiles/profile-2/modules/module-v2, что позволит использовать нужный набор модулей разным сайтам внутри одного инсталла.
                        • –2
                          Наверное, Installation Profiles — это выход, хоть и не очень удобный. Я сбежал с Drupal раньше, чем освоил их.
                    • +1
                      Кстати, ничего революционного в списке не вижу. Хорошая такая работа над ошибками и детскими болезнями.

                      Хранение конфигурации не в базе, а в файлах — как камень с плеч. Остальное — приятные мелочи, которые в совокупности являются значительным шагом вперед, но никак не революцией.
                      • +3
                        Революция — в смене ядра с самописного процедурного, которому уже больше 10 лет, на ООП Симфони. По коду — это практически полностью новая система. Хранение конфигурации в файлах — просто как следствие этого. Для частичной совместимости с предыдущими версиями оставлены прослойки в виде хуков и т. п., поэтому по общему функционалу кажется, что вроде как ничего особо не изменилось. Но главные изменения — под капотом.

                        Новая версия позволит отбросить многие рудименты и развиваться вперед. А если делать сразу и новое ядро, и революционный функционал — то это уж очень трудозатратно, и мы бы новой версии никогда б не дождались, либо дождались бы новой цмс :)
                      • –2
                        Добавление изображений
                        Появилась возможность, без установки дополнительных модулей, вставлять изображение в нужное место в тексте. Возможна также одновременная загрузка нескольких изображений.


                        Приятно что добавили в 8-ой версии, когда в Вордпрессе такое было уже давно давно. Кстати когда я писал на 7-м Друпале меня просто убило что нет из коробки ни менеджера изображений, ни даже WYSIWYG едитора. И не говорите мне что можно прикрутить один из множества модулей. Не спорю, можно, но зачем? Это базовые функции и лучше чтобы они разрабатывались теми же людьми что и сама ЦМС, а не кем-то еще. В итоге для 7-го Друпала была куча едиторов и менеджеров рисунков и ни одного нормального.
                        • 0
                          Если вам надо всё готовенькое из коробки, то Drupal — не ваш выбор. Используйте те же Wordpress и Joomla.
                          • +1
                            Так и делаю. Но как видите авторы друпала сами уже осознали свою ошыбку и теперь добавляют больше всего в ядро
                            • +3
                              Это не ошибка, а стратегия развития.

                              Всем CMS, которые следуют пути «всё готовенькое из коробки», до функциональности и гибкости Drupal — как до луны.

                              И если вам лень установить модуль вставки ссылок на картинки в текст, набрав в консоли drush dl insert && drush pm-enable insert, это не значит, что авторы Drupal совершили ошибку.
                          • 0
                            ага, только в вордпрессе от этого начинаются проблемы при переезде…
                          • +1
                            Как известно, люди противятся любым изменениям — даже хорошим, так как это выбивает их из накатанной колии и заставляет покинуть зону комфорта


                            Чушь

                            Любой смысл заниматься Друпал потерялся после 7-ки. До 7-ки включительно это был довольно самобытный гибрит фреймворка и цмс написанный простым процедурным кодом, 8-ка — непонятная мешанина из процедур и ооп. Каким там боком Symfony вообще, которая сама по себе фреймворк? :) Полнейший отсос по производительности. ТОННЫ кода. Те же вещи, что и в 7-ке делаются в 8-ке вдвое большим количеством кода.
                            Друпал 8 — это непонятный продукт, сделанный непонятно для кого. Чем тратить время на изучение этого недоразумения, лучше освоить нормальный фреймворк / язык.
                            Ренди Фей, один из топовых разработчиков ядра и модулей Друпал: I wore myself out on Drupal 7 and swore off Drupal 8
                            • –1
                              Вовсе не чушь. Вы сами только что продемонстрировали справедливость процитированного вами утверждения. :)

                              А вот по части претензий к Drupal я с вами полностью согласен. И тоже сбегаю с него.
                              • 0
                                Так уже сбежали или все-таки еще сбегаете? И куда, если не секрет? :)
                                • 0
                                  Я уже не беру новые заказы на Drupal, но от поддержки существующих сайтов никуда не денешься. Недавно вот попросили сделать мультиязычность, и я нарвался на то, что модуль Field Collection, который на сайте используется в большинстве content types, мультиязычность не поддерживает. :/

                                  Вот завтра встречаюсь с тиммейтами (черт побери, в русском языке нет такого слова!), будем щупать DerbyJS. На наш взгляд, это самое перспективное направление, на несколько шагов впереди всех остальных. К сожалению, на данный момент обучающих материалов по этому фреймворку.
                                  • 0
                                    Тоже постоянно смотрю в сторону фреймворков, и постоянно останавливает мысль, что придется писать свой друпал на этом фреймворке :) Недостатков у 7 много, поэтому я с нетерпением смотрю в сторону 8.
                                    • 0
                                      Друпал подкупает свой возможностью решать сложные кастомные задачи на уровне кликов мышью, оставаясь при этом невероятно гибким для разработки, чего нет у других цмс. Но очень сложно делать деплой и поддерживать большое количество сайтов.
                                      • –1
                                        Отвечаю сразу на этот и предыдущий комментарии.

                                        Да, возможности Drupal по конфигурированию мышкой — непревзойденные. Но если вам нужно что-то за пределами предоставляемого функционала, вы оказываетесь в глубокой жопе. Программирование модулей Drupal — это ужасно. Система обратных вызовов хоть и эффективна, но чрезвычайно запутана и неважно документирована. У вас могут уйти дни на то, чтобы сделать какое-то тривиальное изменение (и потом вы, немаловероятно, плюнете на это). Сюда добавляется тысяча и одни грабли PHP.

                                        Когда у вас появится опыт работы с полноценным кодовым фрэймворком, вы почувствуете, будто на кончиках ваших пальцев сосредоточена суперсила. Вы можете просто объяснить фреймворку, что вам нужно простым, внятным кодом — и он тут же это делает. На разработку сайта «с чистого листа» у вас будет уходить меньше времени, чем на сборку такого же сайта на Drupal. При этом вы получаете непревзойденную гибкость и удобнейшие средства деплоя.
                                        • +2
                                          Программирование модулей Drupal — это ужасно.
                                          Часто приходится программировать модули и тут двоякая ситуация:
                                          1. API самого друпала довольно неплохо документировано (я про официальную документацию на английском, как с русским переводом обстоят дела — не в курсе), у меня с ним проблем не возникало, модули пишутся на ура.
                                          2. Если необходимо написать модуль к чему-нибудь за пределами базового API (например к Views) — то это, соглашусь, жопа: код весьма абстрактный, а документации к нему нет никакой.

                                          Когда у вас появится опыт работы с полноценным кодовым фрэймворком, вы почувствуете, будто на кончиках ваших пальцев сосредоточена суперсила
                                          Вот, например, при работе с RoR, постоянно ловил себя на мысли, что все время приходится велосипедить то, что в друпале уже давно сделано и конфигурится мышкой :) Сейчас у меня есть готовые настроенные установочные профили с нужным набором модулей. Любой фреймворк до такого состояния пилить и пилить.
                                • +1
                                  Вы считаете, что тонны кода — это хуже, чем одна лапша на 10к строк?
                                  • +1
                                    Да, да — друпал уже не тот. Слышал это поле 5ки и после 6ки…
                                  • +2
                                    Дополню: следующая альфа ожидается послезавтра, а опробовать проще всего на simplytest.me — просто вводите Drupal (или название любого дистрибутива, модуля или темы), выбираете версию, и оно разворачивает для вас песочницу на 30 минут.
                                    • +4
                                      Над ядром работает около 1600+ разработчиков.

                                      Мне страшно.
                                      • 0
                                        Точнее будет — контрибутеров). Исправил, спасибо!
                                      • 0
                                        Логотип 8-ки — слетевший с катушек друпликон. Хаха!
                                        • 0
                                          Главная проблема всех этих новых версий — невозможность гладко обновиться с предыдущих.
                                          Я полные сутки пытался перевести свой форум с D6 на D7, потом плюнул и откатил. Я был готов отказаться от пачки самопальных изменений, но оно глобально все шло не так. Плюс все-таки наблюдалось отсутствие нормальной связки «проголосовал за ноду — очки пошли в карму пользователю» — часть нужных модулей еще и под D7 не вышло. А тут уже D9 планируется.
                                          Стремно. Я хочу идти в ногу со временем, но что делать, если имеется любимый отлаженный сайт на Друпале, который не хочет апгрейдится.
                                          • –2
                                            В opencart — это уже почти все давно присутствует, плюс куча других плюшек. Разве что «слушателя» нет, но его можно тоже легко реализовать, ядро позволяет.
                                            Отошел я уже пару лет от друпал в пользу opencart, и не жалею, не идеальная система конечно, но на порядок лучше и надежнее.
                                            • +2
                                              Буквально пару дней назад решил найти замену Drupal Commerce (конкретно магазин), поставил OpenCart. Посидел, почитал инфу, посмотрел модули/плагины и понял, что гибкости, как у Drupal, нет. Так что, Drupal Commerce для меня более чем — с импортом товаров, гибким каталогом (как надо мне/заказчику) со всем тем, что нужно мне, не изобретая велосипед.
                                              • 0
                                                Просто вы мельком «посмотрели», поработайте по дольше.
                                                Я тоже сидел на Drupal, перешел на opencart, сейчас даже «новостные» сайты делаю на opencart.
                                                • 0
                                                  Честно. Не вижу смысла. Как я выше написал, нет такой гибкости.

                                                  Ещё момент, кучу делать руками (да-да, я про дополнительные модули, часть которых стоит немалых денег). А после Drupal — это вообще для меня изобретение велосипедов с огромной переплатой.

                                                  Аналогов Feeds + Commerce Feeds, как я понял, не существует. А это хорошее решение для импорта товаров на сайт. Равно как и аналога модуля Features. Да и подобия SearchAPI + фасетных фильтров нет в помине.

                                                  Максимум, который я дописываю — 1 большой модуль + шаблон, в котором находится вся темизация каталогов, отдельных нод, представлений и всего того, что видит конечный пользователь.

                                                  сейчас даже «новостные» сайты делаю на opencart
                                                  Хм, новостные сайты на движке E-Commerce? Интересный подход.

                                                  P.S. Если не секрет, сколько вы берёте за разработку магазина на OpenCart (от ХХХ руб.) и сколько разработка занимает времени?
                                                  • 0
                                                    Как раз opencart очень гибкий и простой для разработчиков, у него современная архитектура, не без изъянов конечно, но очень гибкая.
                                                    Всё для opencart есть и import/export хоть куда, хоть связь с 1C, фильтров вообще валом и на любой вкус, тем шаблонов валом — очень много модулей, расширений, отличное русскоязычное комьюнити.
                                                    И opencart — это такая же cms, framework как и любая другая, просто уклон у неё в сторону e-commerce
                                                    И не только я делаю «новостные», недавно наблюдал большой серьезный новостной английский портал на opencart.
                                                    Насчет разработки — я делал под ключ интернет-магазин с индивидуальным дизайном и наполнением за 24 часа.

                                                    Просто вы очень бегло ознакомились с opencart
                                              • 0
                                                Мне было достаточно одного обсуждения ЧПУ, где все предлагавшие улучшения были тупо забанены, чтобы понять, что Даниэль неадекватен, и никогда больше даже не смотреть в сторону OpenCart. Случай далеко не единичный. Желаю проекту развития и вообще, но с таким подходом к разработке нам не по пути. Это даже не затрагивая несравнимость этих систем.
                                                • 0
                                                  Да, Даниель чувак не адекватный, что есть, то есть и у меня большие сомнения в его квалификации, особенно по части архитектуры ПО. Но… чем хорош opencart, это его сообществом, которому по большому счету и сам Даниель не нужен.
                                                  Насчет ЧПУ — есть SeoPRO, без дублей и т.п. сделана нашим сообществом, есть и сборки, к примеру ocStore. Opencart это фактически framework скорее.
                                                  Кстати в opencart 2.0 добавили неплохой функционал расширения.
                                                  • 0
                                                    Так ведь это длится не один год и проекту очень мешает. Нужно делать открытый форк с внятной моделью разработки и перетаскивать сообщество на него. Это может сделать, по-моему, только какая-то заинтересованная часть сообщества, готовая первое время самостоятельно реализовывать новый функционал и поддерживать совместимость с основной веткой. Подавать как OpenCart с плюшками и открытый по-настоящему. Если получится перетащить значительную часть сообщества, то развиваться форк начнёт гораздо быстрее и успешнее, чем оригинал, я думаю. Со временем отпадёт и нужда в совместимости.
                                                    • 0
                                                      ocStore по такому пути идет, там и с дублями ЧПУ разобрались и с еще кучей недостатков, при полной совместимости с opencart, без особой фрагментации, но… нужна поддержка не только рунета
                                                      Вообще я в разработках (demo) больше использую opencart, как framework, по ходу избавляя от недостатков сам opencart.
                                                • 0
                                                  И извиняюсь за некропост — пост появился у меня в трекере из-за ваших новых комментов и я решил, что это недавний пост о выходе бета-версии Drupal 8 :)
                                                • +2
                                                  С каждым выходом новой версии, все ноют, но продолжают пользоваться :)
                                                  • 0
                                                    Напишу о наболевшем. Это ckeditor. По стечению обстоятельств приходиться им пользоваться — это ад. Всплывает столько багов и непредсказуемого поведения, что дрожь берёт, когда понимаю, что скоро придётся в нём что-то набирать.

                                                    А в остальном желаю удачи проекту.
                                                    • 0
                                                      Исходя из моего опыта, ckeditor (по крайней мере, 3-я версия) — наиболее стабильный, функциональный, производительный и предсказуемый из всех открытых wysiwyg-редакторов. Я прощупал их очень большое количество, долго сидел на tinymce и постоянно плевался, а альтернатив не было (тот же предшественник fck был жутко крив), пока не вышел ckeditor. После минимальной доводки, он работает прекрасно, редактора довольны предсказуемым поведением, мне как разработчику нравится, что можно спокойно добавлять любые стили и классы, и они никуда не пропадут из режима html source, ну и сам он не добавляет никакой отсебятины. Опять же повторюсь — в сравнении с остальными.

                                                      Ну а какой редактор на ваш взгляд лучше?
                                                      • 0
                                                        Работаю с 4й версией.
                                                        Стили из «источника» убиваются по собственному желанию редактора. Настроить стили для таблицы так, чтобы редактор их не трогал, после 3х часов так и не получилось. Самовольный варпинг тегами, который просто нельзя отменить (по словам самих разработчиков) также добавляет веселья.

                                                        Меня и как разработчика, и как редактора статей уничтожает работа с этим инструментом. Ну и в добавок разработчики на запросы отвечают долго (от недели).

                                                        Ну а какой редактор на ваш взгляд лучше?

                                                        Увы, приходится либо велосипедить, либо титанически менять поведение или ckeditor или tinymce. По глючности они примерно равны.
                                                        • 0
                                                          4-ю еще не пробовал, не могу ничего сказать. Советую тогда пощупать 3-ю версию в работе, если есть возможность.
                                                  • +2
                                                    Странное повествование…

                                                    Скажу честно с Drupal я знаком очень поверхностно (устанавливал всего 2 или 3 раза и то больше «на посмотреть»).
                                                    Однако многообещающий заголовок «революционные изменения» привлек мое внимание, и я решил изучить «тенденции»
                                                    развития современных CMS, т.с. bleeding-edge технологии.

                                                    [Пишу не в качестве наезда на автора статьи или сам Drupal, а в попытках разобраться, что же на сегодняшний день
                                                    должна представлять собой система управления сайтом, и какие требования предъявляют к ней пользователи.]

                                                    Итак, пробегусь по пунктам:

                                                    Inline редактирование — штука полезная, но никак не новая. Во многих движках уже давно встроена из коробки,
                                                    в других подключается через плагины.

                                                    Модуль Views в ядре — тут мне комментировать сложно, т.к. не использовал в работе этот движок.

                                                    Встроенная мультиязычность — тут хотелось бы уточнить, что входит в понятие мультиязычности. Переключение языка интерфейса,
                                                    или полноценная мультиязычность с возможностью из коробки создавать контент на нескольких языках, с переключением?
                                                    Как бы тут ни было, тенденция избавиться от 5-ти модулей радует, но не более…

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

                                                    Добавление изображений — это пункт у меня тоже вызывает недоумение. А как раньше-то жили на Drupal'е?
                                                    Это же… в общем смотри предыдущий пункт.

                                                    Адаптивный дизайн для встроенных тем — это полезное нововведение. Хотя в разрезе использования той или иной CMS,
                                                    не очень понятно. Я привык к подходу: нужна адаптивная тема — возьми подходящую и поставь.

                                                    Новый тулбар — да, удобно. Но это должно быть «must have». И не стоит отдельного «революционного» пункта.

                                                    Новые типы полей — тут мне судить трудно, не знаю движок так глубоко.
                                                    Хотя по опыту работы с некоторыми CMS — дополнительные поля должны создаваться по необходимости администратором из панели управления CMS.

                                                    Система управления конфигурированием — перенос конфигов в файлы вопрос спорный, как с точки зрения удобства, так и с
                                                    точки зрения безопасности, т.к. часть файловой системы при этом должна быть доступна для записи.
                                                    Отвлекаясь от Друпала: легкий импорт/экспорт настроек вопрос спорный, мне проще одну условную таблицу настроек выгрузить из БД.
                                                    Для разных конфигов для разработки и продакшена, тоже не вопрос использовать разные таблицы БД (при условии что в БД не помойка и данные структурированы). Единственный плюс хранение настроек в CVS.

                                                    Часть модулей удалена из ядра — тут комментировать не буду. К революции отношения не имеет.

                                                    Апгрейт с предыдущих версий — хорошая штука. Но предполагал, что это является само собой разумеющимся для любой CMS (по крайней мере всемирно известной).

                                                    Использование ООП — переход к ООП неизбежен в том или ином объеме. Вопрос в том, чтобы система не превратилась в объектного монстра.

                                                    Использование компонентов Symfony2 — хороший ход, но судя по всему уже не новый.

                                                    Composer — тоже «must have» для большого проекта с кучей модулей. Не все еще используют прозрачную систему контроля зависимостей.

                                                    Движок шаблонов Twig — не использовал ни этот не предыдущий. Но соглашусь, что вставок PHP кода в файлах шаблона быть не должно, для этого есть другие методы.

                                                    Система конфигурирования в yaml — удобно? В некоторых случаях да. Полезно для Друпала? Возможно. Революционно? Нет.

                                                    PHPUnit — вот это пожалуй значимая вещь. хотя не знаю в каком объеме ее можно использовать в Друпал.

                                                    RESTful сервер — не очень понял, что значит «может обслуживать множество устройств»?

                                                    Сторонние компоненты по понятным причинам не рассматриваю.

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

                                                    В общем, той революции (в технологиях, методах или функционале) которую хотел ожидал открыть для себя — я не нашел.
                                                    • 0
                                                      Извиняюсь, за оффтопик.

                                                      Система управления конфигурированием — перенос конфигов в файлы

                                                      Чисто субъективно, конфиги в json/yaml более наглядны, чем в БД (не беру монго). Кроме этого, с точки зрения стабильности, упавший сервер с БД — и всё, ваша система не «соберётся». В случае файлов, упавший сервер БД меньше влияет на работу системы. Кроме того, настройки подключения к БД не представляю как хранить в БД, а это ж тоже конфигурация.

                                                      Подводя итог, да, вы правы, вопрос действительно спорный (помнится мне, была на хабре статья про сравнение производительности системы в зависимости от способа хранения конфигов, если кратко — БД там проигрывала) и не революционный.
                                                      • +1
                                                        Сама 8 версия является революционной по сравнению с 7 и более ранними, см. мой комментарий habrahabr.ru/post/197670/#comment_6860188

                                                        Ну а автор просто перечислил те изменения, которые нас ожидают в 8 версии по сравнению с 7, большинство из них не являются революционными ни для друпала (часть была реализована сторонними модулями), ни для некоторых других цмс, где возможно некоторый функционал уже реализован.

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

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

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

                                                        Таким образом, в 8-й версии мы просто видим продолжение этого процесса, когда сторонние для 7 версии модули включаются в ядро. Требования к цмс с каждым разом все более повышаются, систему постепенно превращают из «цмс для разработчиков» в «комбайн для простых пользователей», постоянно наращивая базовый функционал.

                                                        Если в 7-й версии, например, речь о включении того же wysiwyg в ядро не шла (каждый разработчик сам выбирал, что ему больше по душе), то проанализировав ситуацию и определив, что подавляющее большинство устанавливает ckeditor, то было решено включить его в ядро.
                                                        • 0
                                                          Да. Эту тенденцию я уловил. И, в общем-то, теперь понятно, что речь больше о внутренних изменениях.

                                                          Что касается ядра, включенных и дополнительных модулей, то я, как разработчик за вариант «цмс для разработчиков» (если это не в ущерб функционалу и удобству, это я про отсутствие WYSIWYG). Или за CMS, которые поставляются в двух вариантах — для «разработчиков» и «комбайн для пользователей». И за обязательную возможность простого расширения, т.е. написание модулей без заморочек.

                                                          С этой точки зрения мне импонирует CMS Cotonti (ее частенько использую и пишу под нее).
                                                          [Напишу тут пару слов для популяризации. Возможно вам, как человеку глубоко разбирающемуся в Друпале, это будет не столь интересно,
                                                          но тем, кто не определился или страшится ООП 8-й версии… ]

                                                          С одной стороны (буду честен) использую Cotonti, в том числе и потому, что знаком с этой системой уже лет 8.
                                                          Но с другой стороны (пытаясь взглянуть не предвзято) это эдакий «комбайн для разработчика».
                                                          Во-первых, основной функционал необходимый простому «пользователю» доступен «из коробки» (блог/страницы, форум, внутр.почта, WYSIWYG или BBcode на выбор, обратная связь, примитивный файл менеджер).
                                                          Во-вторых, присутствует функционал, который скрыт от глаз простого пользователя, но который просто обязан присутствовать в современной CMS — 3-х уровневый кеш (mem/db/fs), механизм i18n, быстрый шаблонизатор, html-purifier.
                                                          И в-третьих, простота и доступность для среднего (и даже начинающего разработчика): простота создания своих тем оформления (шаблоны расширяемые спец.тегами, базовая логика, вызов определенных функций, переопределение системных шаблонов), простой механизм расширений, плюс гибкость в вызове доп.кода (хуки, через определение спец.тегов, прямой вызов функций расширения из шаблона),
                                                          по большей части процедурный код.

                                                          Единственный минус на текущий момент — это отсутствие достаточного количества разработчиков/контрибутеров (коих на два порядка меньше чем у Друпала).

                                                      • +2
                                                        в общем, теперь еще тяжелее и еще медленнее…

                                                        может быть сторонникам друпала написать статью о том, почему стоит использовать этого монстра? а то я (как и многие другие, судя по комментариям) не вполне это понимают.
                                                        • +1
                                                          Потому что в ограниченное время и с ограниченным человеческим ресурсом можно поднимать достаточно сложные по структуре и практически неограниченные по функионалу сайты. Ресурсы железа, правда, желательно чтобы тоже были неограниченные :) Но тут еще и от кривизны рук зависит.

                                                          Ну а можно за день-два клепать визитки по готовой схеме с неограниченным потенциалом для их дальнейшего развития. Ну и еще есть множество других кейсов.

                                                          Также следует отметить, что все это возможно только при условии обладания достаточными знаниями.
                                                          • +1
                                                            Не кто не говорит переходить вам сейчас на 8 ку. На 7 версии отлично все работает. На 6 ой версии до сих пор очень много сайтов.
                                                            Из плюсов могу упомянуть следующее:
                                                            1. Таксономия — очень удобный, универсальный механизм структурирования информации.
                                                            2. Огромное количество действительно работающих модулей.
                                                            3. Одно из самых больших сообществ разработчиков.
                                                            4. Views — вывод почти любой информации и удобное конфигурирование.
                                                            5. Безопасность.
                                                            • 0
                                                              Я с Друпал знаком мало (как и писал выше). Расскажите подробнее про механизм Views. Или может ссылочку на почитать. Только хотелось бы не документацию читать, а в «двух словах» описание работы механизма.
                                                              • 0
                                                                Views — это конструктор с широчайшими возможностями. Например у вас есть материал Новость ( нода с типом Новость ). С помошью Views, вы практически без какого либо написнаия кода на PHP можете вывести новости на отдельную страницу или блок в алфавитном порядке ( для примера), лишь несколькими кликами мыши. А вообще, если вы незнаете хорошо друпал, советую ознакомиться с видео www.youtube.com/playlist?list=PL590210551ABE3609. В этом видео наглядно показано как создавать тему доступным языком. Только не забудь включить субтитры.
                                                                • +2
                                                                  Расскажите подробнее про механизм Views.
                                                                  Визуальная система обращения к базе данных и вывод структурированных данных как нужно вам (так называемые представления). Вам не надо писать запросы к базе вручную, за вас это сделает Views, Укажите через интерфейс, что вам показать и он это сделает. Даже с условиями (аргументами). Даже из нескольких таблиц (с зависимостями). С вариантами показа (блоки, таблицы, списки), с выбором пейджера и количества показываемых страниц. Я не перечислю всего того, что можно делать с помощью Views.

                                                                  В общем, довольная необходимая штука даже на небольшом новостном сайте, галерее, сайте-портфолио и прочих небольших проектах.
                                                            • 0
                                                              Вместо тысячи слов: drupal.org/project/usage/drupal — почти миллион учтённых активных, живых установок.
                                                              • –2
                                                                6 октября 45 загрузок восьмерки, семерку же загрузили 733,432
                                                                • +1
                                                                  Это информация не о загрузках, а об использовании https://drupal.org/project/usage/drupal
                                                                  8-ка же, пока только альфа и используется только в тестовых целях.

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