Comments 70
А картинки?) Революционные же изменения, а скриншотов нет
UFO just landed and posted this here
Лучше бы они не изобретали велосипеды с тулбарами и взяли bootstrap!
Лично мне в Drupal 7 не хватает двух вещей:
Все приличные фреймворки позволяют создать проект (сайт) в произвольном месте файловой системы и указать для него произвольные зависимости.
В Drupal же в 2013 году приходится делать так, как это делалось десять лет назад: создавать сайт в подпапке внутри папки движка. Если же у вас два сайта требуют разных версий одного модуля, приходится создавать два экземпляра движка.
Управлять этим зоопарком при большом количестве сайтов настолько трудно и неудобно, что изобретаются костыли вроде Drush Make и Aegir (кстати, скоро выйдет вторая версия). По удобству пользования этим костылям до, например, bundle install как до луны.
Судя по этому посту, ситуация не изменится. :(
- полноценного менеджера пакетов;
- отделения кода движка от кода сайта.
Все приличные фреймворки позволяют создать проект (сайт) в произвольном месте файловой системы и указать для него произвольные зависимости.
В Drupal же в 2013 году приходится делать так, как это делалось десять лет назад: создавать сайт в подпапке внутри папки движка. Если же у вас два сайта требуют разных версий одного модуля, приходится создавать два экземпляра движка.
Управлять этим зоопарком при большом количестве сайтов настолько трудно и неудобно, что изобретаются костыли вроде Drush Make и Aegir (кстати, скоро выйдет вторая версия). По удобству пользования этим костылям до, например, bundle install как до луны.
Судя по этому посту, ситуация не изменится. :(
— «Если же у вас два сайта требуют разных версий одного модуля, приходится создавать два экземпляра движка»
Можно же сделать так: sites/site-1/module-v1, sites/site-1/module-v2
Можно же сделать так: sites/site-1/module-v1, sites/site-1/module-v2
К сожалению, Aegir поддерживает размещение модулей, тем и библиотек только в
sites/all.
Наверное, это проблема не друпала, а Aegir, что оно не поддерживает весь функционал друпала.
У меня несколько сайтов под octpus, это «Aegir + Platforms installer». Я не проникся на 100% идеей 1 сайт = 1 платформа (зря, возможно), поэтому у меня много модулей лежит непосредственно в папках сайтов.
Добавляю так: $ drush @mysite.ru dl modulename --use-site-dir
Добавляю так: $ drush @mysite.ru dl modulename --use-site-dir
А также можно сделать profiles/profile-1/modules/module-v1 и profiles/profile-2/modules/module-v2, что позволит использовать нужный набор модулей разным сайтам внутри одного инсталла.
Кстати, ничего революционного в списке не вижу. Хорошая такая работа над ошибками и детскими болезнями.
Хранение конфигурации не в базе, а в файлах — как камень с плеч. Остальное — приятные мелочи, которые в совокупности являются значительным шагом вперед, но никак не революцией.
Хранение конфигурации не в базе, а в файлах — как камень с плеч. Остальное — приятные мелочи, которые в совокупности являются значительным шагом вперед, но никак не революцией.
Революция — в смене ядра с самописного процедурного, которому уже больше 10 лет, на ООП Симфони. По коду — это практически полностью новая система. Хранение конфигурации в файлах — просто как следствие этого. Для частичной совместимости с предыдущими версиями оставлены прослойки в виде хуков и т. п., поэтому по общему функционалу кажется, что вроде как ничего особо не изменилось. Но главные изменения — под капотом.
Новая версия позволит отбросить многие рудименты и развиваться вперед. А если делать сразу и новое ядро, и революционный функционал — то это уж очень трудозатратно, и мы бы новой версии никогда б не дождались, либо дождались бы новой цмс :)
Новая версия позволит отбросить многие рудименты и развиваться вперед. А если делать сразу и новое ядро, и революционный функционал — то это уж очень трудозатратно, и мы бы новой версии никогда б не дождались, либо дождались бы новой цмс :)
Добавление изображений
Появилась возможность, без установки дополнительных модулей, вставлять изображение в нужное место в тексте. Возможна также одновременная загрузка нескольких изображений.
Приятно что добавили в 8-ой версии, когда в Вордпрессе такое было уже давно давно. Кстати когда я писал на 7-м Друпале меня просто убило что нет из коробки ни менеджера изображений, ни даже WYSIWYG едитора. И не говорите мне что можно прикрутить один из множества модулей. Не спорю, можно, но зачем? Это базовые функции и лучше чтобы они разрабатывались теми же людьми что и сама ЦМС, а не кем-то еще. В итоге для 7-го Друпала была куча едиторов и менеджеров рисунков и ни одного нормального.
Если вам надо всё готовенькое из коробки, то Drupal — не ваш выбор. Используйте те же Wordpress и Joomla.
Так и делаю. Но как видите авторы друпала сами уже осознали свою ошыбку и теперь добавляют больше всего в ядро
Это не ошибка, а стратегия развития.
Всем CMS, которые следуют пути «всё готовенькое из коробки», до функциональности и гибкости Drupal — как до луны.
И если вам лень установить модуль вставки ссылок на картинки в текст, набрав в консоли
Всем CMS, которые следуют пути «всё готовенькое из коробки», до функциональности и гибкости Drupal — как до луны.
И если вам лень установить модуль вставки ссылок на картинки в текст, набрав в консоли
drush dl insert && drush pm-enable insert, это не значит, что авторы Drupal совершили ошибку.
ага, только в вордпрессе от этого начинаются проблемы при переезде…
Как известно, люди противятся любым изменениям — даже хорошим, так как это выбивает их из накатанной колии и заставляет покинуть зону комфорта
Чушь
Любой смысл заниматься Друпал потерялся после 7-ки. До 7-ки включительно это был довольно самобытный гибрит фреймворка и цмс написанный простым процедурным кодом, 8-ка — непонятная мешанина из процедур и ооп. Каким там боком Symfony вообще, которая сама по себе фреймворк? :) Полнейший отсос по производительности. ТОННЫ кода. Те же вещи, что и в 7-ке делаются в 8-ке вдвое большим количеством кода.
Друпал 8 — это непонятный продукт, сделанный непонятно для кого. Чем тратить время на изучение этого недоразумения, лучше освоить нормальный фреймворк / язык.
Ренди Фей, один из топовых разработчиков ядра и модулей Друпал: I wore myself out on Drupal 7 and swore off Drupal 8
Вовсе не чушь. Вы сами только что продемонстрировали справедливость процитированного вами утверждения. :)
А вот по части претензий к Drupal я с вами полностью согласен. И тоже сбегаю с него.
А вот по части претензий к Drupal я с вами полностью согласен. И тоже сбегаю с него.
Так уже сбежали или все-таки еще сбегаете? И куда, если не секрет? :)
Я уже не беру новые заказы на Drupal, но от поддержки существующих сайтов никуда не денешься. Недавно вот попросили сделать мультиязычность, и я нарвался на то, что модуль Field Collection, который на сайте используется в большинстве content types, мультиязычность не поддерживает. :/
Вот завтра встречаюсь с тиммейтами (черт побери, в русском языке нет такого слова!), будем щупать DerbyJS. На наш взгляд, это самое перспективное направление, на несколько шагов впереди всех остальных. К сожалению, на данный момент обучающих материалов по этому фреймворку.
Вот завтра встречаюсь с тиммейтами (черт побери, в русском языке нет такого слова!), будем щупать DerbyJS. На наш взгляд, это самое перспективное направление, на несколько шагов впереди всех остальных. К сожалению, на данный момент обучающих материалов по этому фреймворку.
Тоже постоянно смотрю в сторону фреймворков, и постоянно останавливает мысль, что придется писать свой друпал на этом фреймворке :) Недостатков у 7 много, поэтому я с нетерпением смотрю в сторону 8.
Друпал подкупает свой возможностью решать сложные кастомные задачи на уровне кликов мышью, оставаясь при этом невероятно гибким для разработки, чего нет у других цмс. Но очень сложно делать деплой и поддерживать большое количество сайтов.
Отвечаю сразу на этот и предыдущий комментарии.
Да, возможности Drupal по конфигурированию мышкой — непревзойденные. Но если вам нужно что-то за пределами предоставляемого функционала, вы оказываетесь в глубокой жопе. Программирование модулей Drupal — это ужасно. Система обратных вызовов хоть и эффективна, но чрезвычайно запутана и неважно документирована. У вас могут уйти дни на то, чтобы сделать какое-то тривиальное изменение (и потом вы, немаловероятно, плюнете на это). Сюда добавляется тысяча и одни грабли PHP.
Когда у вас появится опыт работы с полноценным кодовым фрэймворком, вы почувствуете, будто на кончиках ваших пальцев сосредоточена суперсила. Вы можете просто объяснить фреймворку, что вам нужно простым, внятным кодом — и он тут же это делает. На разработку сайта «с чистого листа» у вас будет уходить меньше времени, чем на сборку такого же сайта на Drupal. При этом вы получаете непревзойденную гибкость и удобнейшие средства деплоя.
Да, возможности Drupal по конфигурированию мышкой — непревзойденные. Но если вам нужно что-то за пределами предоставляемого функционала, вы оказываетесь в глубокой жопе. Программирование модулей Drupal — это ужасно. Система обратных вызовов хоть и эффективна, но чрезвычайно запутана и неважно документирована. У вас могут уйти дни на то, чтобы сделать какое-то тривиальное изменение (и потом вы, немаловероятно, плюнете на это). Сюда добавляется тысяча и одни грабли PHP.
Когда у вас появится опыт работы с полноценным кодовым фрэймворком, вы почувствуете, будто на кончиках ваших пальцев сосредоточена суперсила. Вы можете просто объяснить фреймворку, что вам нужно простым, внятным кодом — и он тут же это делает. На разработку сайта «с чистого листа» у вас будет уходить меньше времени, чем на сборку такого же сайта на Drupal. При этом вы получаете непревзойденную гибкость и удобнейшие средства деплоя.
Программирование модулей Drupal — это ужасно.Часто приходится программировать модули и тут двоякая ситуация:
1. API самого друпала довольно неплохо документировано (я про официальную документацию на английском, как с русским переводом обстоят дела — не в курсе), у меня с ним проблем не возникало, модули пишутся на ура.
2. Если необходимо написать модуль к чему-нибудь за пределами базового API (например к Views) — то это, соглашусь, жопа: код весьма абстрактный, а документации к нему нет никакой.
Когда у вас появится опыт работы с полноценным кодовым фрэймворком, вы почувствуете, будто на кончиках ваших пальцев сосредоточена суперсилаВот, например, при работе с RoR, постоянно ловил себя на мысли, что все время приходится велосипедить то, что в друпале уже давно сделано и конфигурится мышкой :) Сейчас у меня есть готовые настроенные установочные профили с нужным набором модулей. Любой фреймворк до такого состояния пилить и пилить.
Вы считаете, что тонны кода — это хуже, чем одна лапша на 10к строк?
Да, да — друпал уже не тот. Слышал это поле 5ки и после 6ки…
Дополню: следующая альфа ожидается послезавтра, а опробовать проще всего на simplytest.me — просто вводите Drupal (или название любого дистрибутива, модуля или темы), выбираете версию, и оно разворачивает для вас песочницу на 30 минут.
Над ядром работает около 1600+ разработчиков.
Мне страшно.
Логотип 8-ки — слетевший с катушек друпликон. Хаха!
Главная проблема всех этих новых версий — невозможность гладко обновиться с предыдущих.
Я полные сутки пытался перевести свой форум с D6 на D7, потом плюнул и откатил. Я был готов отказаться от пачки самопальных изменений, но оно глобально все шло не так. Плюс все-таки наблюдалось отсутствие нормальной связки «проголосовал за ноду — очки пошли в карму пользователю» — часть нужных модулей еще и под D7 не вышло. А тут уже D9 планируется.
Стремно. Я хочу идти в ногу со временем, но что делать, если имеется любимый отлаженный сайт на Друпале, который не хочет апгрейдится.
Я полные сутки пытался перевести свой форум с D6 на D7, потом плюнул и откатил. Я был готов отказаться от пачки самопальных изменений, но оно глобально все шло не так. Плюс все-таки наблюдалось отсутствие нормальной связки «проголосовал за ноду — очки пошли в карму пользователю» — часть нужных модулей еще и под D7 не вышло. А тут уже D9 планируется.
Стремно. Я хочу идти в ногу со временем, но что делать, если имеется любимый отлаженный сайт на Друпале, который не хочет апгрейдится.
В opencart — это уже почти все давно присутствует, плюс куча других плюшек. Разве что «слушателя» нет, но его можно тоже легко реализовать, ядро позволяет.
Отошел я уже пару лет от друпал в пользу opencart, и не жалею, не идеальная система конечно, но на порядок лучше и надежнее.
Отошел я уже пару лет от друпал в пользу opencart, и не жалею, не идеальная система конечно, но на порядок лучше и надежнее.
Буквально пару дней назад решил найти замену Drupal Commerce (конкретно магазин), поставил OpenCart. Посидел, почитал инфу, посмотрел модули/плагины и понял, что гибкости, как у Drupal, нет. Так что, Drupal Commerce для меня более чем — с импортом товаров, гибким каталогом (как надо мне/заказчику) со всем тем, что нужно мне, не изобретая велосипед.
Просто вы мельком «посмотрели», поработайте по дольше.
Я тоже сидел на Drupal, перешел на opencart, сейчас даже «новостные» сайты делаю на opencart.
Я тоже сидел на Drupal, перешел на opencart, сейчас даже «новостные» сайты делаю на opencart.
Честно. Не вижу смысла. Как я выше написал, нет такой гибкости.
Ещё момент, кучу делать руками (да-да, я про дополнительные модули, часть которых стоит немалых денег). А после Drupal — это вообще для меня изобретение велосипедов с огромной переплатой.
Аналогов Feeds + Commerce Feeds, как я понял, не существует. А это хорошее решение для импорта товаров на сайт. Равно как и аналога модуля Features. Да и подобия SearchAPI + фасетных фильтров нет в помине.
Максимум, который я дописываю — 1 большой модуль + шаблон, в котором находится вся темизация каталогов, отдельных нод, представлений и всего того, что видит конечный пользователь.
P.S. Если не секрет, сколько вы берёте за разработку магазина на OpenCart (от ХХХ руб.) и сколько разработка занимает времени?
Ещё момент, кучу делать руками (да-да, я про дополнительные модули, часть которых стоит немалых денег). А после Drupal — это вообще для меня изобретение велосипедов с огромной переплатой.
Аналогов Feeds + Commerce Feeds, как я понял, не существует. А это хорошее решение для импорта товаров на сайт. Равно как и аналога модуля Features. Да и подобия SearchAPI + фасетных фильтров нет в помине.
Максимум, который я дописываю — 1 большой модуль + шаблон, в котором находится вся темизация каталогов, отдельных нод, представлений и всего того, что видит конечный пользователь.
сейчас даже «новостные» сайты делаю на opencartХм, новостные сайты на движке E-Commerce? Интересный подход.
P.S. Если не секрет, сколько вы берёте за разработку магазина на OpenCart (от ХХХ руб.) и сколько разработка занимает времени?
Как раз opencart очень гибкий и простой для разработчиков, у него современная архитектура, не без изъянов конечно, но очень гибкая.
Всё для opencart есть и import/export хоть куда, хоть связь с 1C, фильтров вообще валом и на любой вкус, тем шаблонов валом — очень много модулей, расширений, отличное русскоязычное комьюнити.
И opencart — это такая же cms, framework как и любая другая, просто уклон у неё в сторону e-commerce
И не только я делаю «новостные», недавно наблюдал большой серьезный новостной английский портал на opencart.
Насчет разработки — я делал под ключ интернет-магазин с индивидуальным дизайном и наполнением за 24 часа.
Просто вы очень бегло ознакомились с opencart
Всё для opencart есть и import/export хоть куда, хоть связь с 1C, фильтров вообще валом и на любой вкус, тем шаблонов валом — очень много модулей, расширений, отличное русскоязычное комьюнити.
И opencart — это такая же cms, framework как и любая другая, просто уклон у неё в сторону e-commerce
И не только я делаю «новостные», недавно наблюдал большой серьезный новостной английский портал на opencart.
Насчет разработки — я делал под ключ интернет-магазин с индивидуальным дизайном и наполнением за 24 часа.
Просто вы очень бегло ознакомились с opencart
Мне было достаточно одного обсуждения ЧПУ, где все предлагавшие улучшения были тупо забанены, чтобы понять, что Даниэль неадекватен, и никогда больше даже не смотреть в сторону OpenCart. Случай далеко не единичный. Желаю проекту развития и вообще, но с таким подходом к разработке нам не по пути. Это даже не затрагивая несравнимость этих систем.
Да, Даниель чувак не адекватный, что есть, то есть и у меня большие сомнения в его квалификации, особенно по части архитектуры ПО. Но… чем хорош opencart, это его сообществом, которому по большому счету и сам Даниель не нужен.
Насчет ЧПУ — есть SeoPRO, без дублей и т.п. сделана нашим сообществом, есть и сборки, к примеру ocStore. Opencart это фактически framework скорее.
Кстати в opencart 2.0 добавили неплохой функционал расширения.
Насчет ЧПУ — есть SeoPRO, без дублей и т.п. сделана нашим сообществом, есть и сборки, к примеру ocStore. Opencart это фактически framework скорее.
Кстати в opencart 2.0 добавили неплохой функционал расширения.
Так ведь это длится не один год и проекту очень мешает. Нужно делать открытый форк с внятной моделью разработки и перетаскивать сообщество на него. Это может сделать, по-моему, только какая-то заинтересованная часть сообщества, готовая первое время самостоятельно реализовывать новый функционал и поддерживать совместимость с основной веткой. Подавать как OpenCart с плюшками и открытый по-настоящему. Если получится перетащить значительную часть сообщества, то развиваться форк начнёт гораздо быстрее и успешнее, чем оригинал, я думаю. Со временем отпадёт и нужда в совместимости.
ocStore по такому пути идет, там и с дублями ЧПУ разобрались и с еще кучей недостатков, при полной совместимости с opencart, без особой фрагментации, но… нужна поддержка не только рунета
Вообще я в разработках (demo) больше использую opencart, как framework, по ходу избавляя от недостатков сам opencart.
Вообще я в разработках (demo) больше использую opencart, как framework, по ходу избавляя от недостатков сам opencart.
И извиняюсь за некропост — пост появился у меня в трекере из-за ваших новых комментов и я решил, что это недавний пост о выходе бета-версии Drupal 8 :)
С каждым выходом новой версии, все ноют, но продолжают пользоваться :)
Напишу о наболевшем. Это ckeditor. По стечению обстоятельств приходиться им пользоваться — это ад. Всплывает столько багов и непредсказуемого поведения, что дрожь берёт, когда понимаю, что скоро придётся в нём что-то набирать.
А в остальном желаю удачи проекту.
А в остальном желаю удачи проекту.
Исходя из моего опыта, ckeditor (по крайней мере, 3-я версия) — наиболее стабильный, функциональный, производительный и предсказуемый из всех открытых wysiwyg-редакторов. Я прощупал их очень большое количество, долго сидел на tinymce и постоянно плевался, а альтернатив не было (тот же предшественник fck был жутко крив), пока не вышел ckeditor. После минимальной доводки, он работает прекрасно, редактора довольны предсказуемым поведением, мне как разработчику нравится, что можно спокойно добавлять любые стили и классы, и они никуда не пропадут из режима html source, ну и сам он не добавляет никакой отсебятины. Опять же повторюсь — в сравнении с остальными.
Ну а какой редактор на ваш взгляд лучше?
Ну а какой редактор на ваш взгляд лучше?
Работаю с 4й версией.
Стили из «источника» убиваются по собственному желанию редактора. Настроить стили для таблицы так, чтобы редактор их не трогал, после 3х часов так и не получилось. Самовольный варпинг тегами, который просто нельзя отменить (по словам самих разработчиков) также добавляет веселья.
Меня и как разработчика, и как редактора статей уничтожает работа с этим инструментом. Ну и в добавок разработчики на запросы отвечают долго (от недели).
Увы, приходится либо велосипедить, либо титанически менять поведение или ckeditor или tinymce. По глючности они примерно равны.
Стили из «источника» убиваются по собственному желанию редактора. Настроить стили для таблицы так, чтобы редактор их не трогал, после 3х часов так и не получилось. Самовольный варпинг тегами, который просто нельзя отменить (по словам самих разработчиков) также добавляет веселья.
Меня и как разработчика, и как редактора статей уничтожает работа с этим инструментом. Ну и в добавок разработчики на запросы отвечают долго (от недели).
Ну а какой редактор на ваш взгляд лучше?
Увы, приходится либо велосипедить, либо титанически менять поведение или ckeditor или tinymce. По глючности они примерно равны.
Странное повествование…
Скажу честно с 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 сервер — не очень понял, что значит «может обслуживать множество устройств»?
Сторонние компоненты по понятным причинам не рассматриваю.
Что в сухом остатке?
Да, очередная версия. Да, мажорный релиз, т.к. перелопатили много. но революцией это можно назвать только в рамках количества
внутренних изменений о которых придется думать разработчикам, сидящим на предыдущих версиях.
В общем, той революции (в технологиях, методах или функционале) которую хотел ожидал открыть для себя — я не нашел.
Скажу честно с 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 сервер — не очень понял, что значит «может обслуживать множество устройств»?
Сторонние компоненты по понятным причинам не рассматриваю.
Что в сухом остатке?
Да, очередная версия. Да, мажорный релиз, т.к. перелопатили много. но революцией это можно назвать только в рамках количества
внутренних изменений о которых придется думать разработчикам, сидящим на предыдущих версиях.
В общем, той революции (в технологиях, методах или функционале) которую хотел ожидал открыть для себя — я не нашел.
Извиняюсь, за оффтопик.
Чисто субъективно, конфиги в json/yaml более наглядны, чем в БД (не беру монго). Кроме этого, с точки зрения стабильности, упавший сервер с БД — и всё, ваша система не «соберётся». В случае файлов, упавший сервер БД меньше влияет на работу системы. Кроме того, настройки подключения к БД не представляю как хранить в БД, а это ж тоже конфигурация.
Подводя итог, да, вы правы, вопрос действительно спорный (помнится мне, была на хабре статья про сравнение производительности системы в зависимости от способа хранения конфигов, если кратко — БД там проигрывала) и не революционный.
Система управления конфигурированием — перенос конфигов в файлы
Чисто субъективно, конфиги в json/yaml более наглядны, чем в БД (не беру монго). Кроме этого, с точки зрения стабильности, упавший сервер с БД — и всё, ваша система не «соберётся». В случае файлов, упавший сервер БД меньше влияет на работу системы. Кроме того, настройки подключения к БД не представляю как хранить в БД, а это ж тоже конфигурация.
Подводя итог, да, вы правы, вопрос действительно спорный (помнится мне, была на хабре статья про сравнение производительности системы в зависимости от способа хранения конфигов, если кратко — БД там проигрывала) и не революционный.
Сама 8 версия является революционной по сравнению с 7 и более ранними, см. мой комментарий habrahabr.ru/post/197670/#comment_6860188
Ну а автор просто перечислил те изменения, которые нас ожидают в 8 версии по сравнению с 7, большинство из них не являются революционными ни для друпала (часть была реализована сторонними модулями), ни для некоторых других цмс, где возможно некоторый функционал уже реализован.
Что касается некоторых базовых функций, которые присутствуют в других цмс из коробки, а в друпале реализуются сторонними модулями. Это связано с особенностью разработки самого друпала, с его позиционированием и текущими тенденциями и требованиями к цмс.
Друпал изначально позиционировался как инструмент для гибкой разработки, когда каждый может взять готовое ядро, навесить на него необходимых модулей и настроить все окружение как душе угодно. Это в частности и отталкивает тех, кто привык сразу получать из коробки готовое решение, пусть и намного менее гибкое в плане дальнейшего наращивания функционала.
Каждая версия ядра выходила с некоторым набором стандартных модулей, которые реализовывали некий базовый функционал. Расширение функционала происходит за счет сторонних модулей, причем зачастую существует несколько решений одной задачи. Для следующей версии ядра из этих решений выбирается одно наиболее удачное и включается в ядро. Таким образом, сначала какой-то функционал реализуется сторонними разработчиками, а затем уже обкатанное и наиболее удачное решение допиливается основной командой.
Таким образом, в 8-й версии мы просто видим продолжение этого процесса, когда сторонние для 7 версии модули включаются в ядро. Требования к цмс с каждым разом все более повышаются, систему постепенно превращают из «цмс для разработчиков» в «комбайн для простых пользователей», постоянно наращивая базовый функционал.
Если в 7-й версии, например, речь о включении того же wysiwyg в ядро не шла (каждый разработчик сам выбирал, что ему больше по душе), то проанализировав ситуацию и определив, что подавляющее большинство устанавливает ckeditor, то было решено включить его в ядро.
Ну а автор просто перечислил те изменения, которые нас ожидают в 8 версии по сравнению с 7, большинство из них не являются революционными ни для друпала (часть была реализована сторонними модулями), ни для некоторых других цмс, где возможно некоторый функционал уже реализован.
Что касается некоторых базовых функций, которые присутствуют в других цмс из коробки, а в друпале реализуются сторонними модулями. Это связано с особенностью разработки самого друпала, с его позиционированием и текущими тенденциями и требованиями к цмс.
Друпал изначально позиционировался как инструмент для гибкой разработки, когда каждый может взять готовое ядро, навесить на него необходимых модулей и настроить все окружение как душе угодно. Это в частности и отталкивает тех, кто привык сразу получать из коробки готовое решение, пусть и намного менее гибкое в плане дальнейшего наращивания функционала.
Каждая версия ядра выходила с некоторым набором стандартных модулей, которые реализовывали некий базовый функционал. Расширение функционала происходит за счет сторонних модулей, причем зачастую существует несколько решений одной задачи. Для следующей версии ядра из этих решений выбирается одно наиболее удачное и включается в ядро. Таким образом, сначала какой-то функционал реализуется сторонними разработчиками, а затем уже обкатанное и наиболее удачное решение допиливается основной командой.
Таким образом, в 8-й версии мы просто видим продолжение этого процесса, когда сторонние для 7 версии модули включаются в ядро. Требования к цмс с каждым разом все более повышаются, систему постепенно превращают из «цмс для разработчиков» в «комбайн для простых пользователей», постоянно наращивая базовый функционал.
Если в 7-й версии, например, речь о включении того же wysiwyg в ядро не шла (каждый разработчик сам выбирал, что ему больше по душе), то проанализировав ситуацию и определив, что подавляющее большинство устанавливает ckeditor, то было решено включить его в ядро.
Да. Эту тенденцию я уловил. И, в общем-то, теперь понятно, что речь больше о внутренних изменениях.
Что касается ядра, включенных и дополнительных модулей, то я, как разработчик за вариант «цмс для разработчиков» (если это не в ущерб функционалу и удобству, это я про отсутствие WYSIWYG). Или за CMS, которые поставляются в двух вариантах — для «разработчиков» и «комбайн для пользователей». И за обязательную возможность простого расширения, т.е. написание модулей без заморочек.
С этой точки зрения мне импонирует CMS Cotonti (ее частенько использую и пишу под нее).
[Напишу тут пару слов для популяризации. Возможно вам, как человеку глубоко разбирающемуся в Друпале, это будет не столь интересно,
но тем, кто не определился или страшится ООП 8-й версии… ]
С одной стороны (буду честен) использую Cotonti, в том числе и потому, что знаком с этой системой уже лет 8.
Но с другой стороны (пытаясь взглянуть не предвзято) это эдакий «комбайн для разработчика».
Во-первых, основной функционал необходимый простому «пользователю» доступен «из коробки» (блог/страницы, форум, внутр.почта, WYSIWYG или BBcode на выбор, обратная связь, примитивный файл менеджер).
Во-вторых, присутствует функционал, который скрыт от глаз простого пользователя, но который просто обязан присутствовать в современной CMS — 3-х уровневый кеш (mem/db/fs), механизм i18n, быстрый шаблонизатор, html-purifier.
И в-третьих, простота и доступность для среднего (и даже начинающего разработчика): простота создания своих тем оформления (шаблоны расширяемые спец.тегами, базовая логика, вызов определенных функций, переопределение системных шаблонов), простой механизм расширений, плюс гибкость в вызове доп.кода (хуки, через определение спец.тегов, прямой вызов функций расширения из шаблона),
по большей части процедурный код.
Единственный минус на текущий момент — это отсутствие достаточного количества разработчиков/контрибутеров (коих на два порядка меньше чем у Друпала).
Что касается ядра, включенных и дополнительных модулей, то я, как разработчик за вариант «цмс для разработчиков» (если это не в ущерб функционалу и удобству, это я про отсутствие WYSIWYG). Или за CMS, которые поставляются в двух вариантах — для «разработчиков» и «комбайн для пользователей». И за обязательную возможность простого расширения, т.е. написание модулей без заморочек.
С этой точки зрения мне импонирует CMS Cotonti (ее частенько использую и пишу под нее).
[Напишу тут пару слов для популяризации. Возможно вам, как человеку глубоко разбирающемуся в Друпале, это будет не столь интересно,
но тем, кто не определился или страшится ООП 8-й версии… ]
С одной стороны (буду честен) использую Cotonti, в том числе и потому, что знаком с этой системой уже лет 8.
Но с другой стороны (пытаясь взглянуть не предвзято) это эдакий «комбайн для разработчика».
Во-первых, основной функционал необходимый простому «пользователю» доступен «из коробки» (блог/страницы, форум, внутр.почта, WYSIWYG или BBcode на выбор, обратная связь, примитивный файл менеджер).
Во-вторых, присутствует функционал, который скрыт от глаз простого пользователя, но который просто обязан присутствовать в современной CMS — 3-х уровневый кеш (mem/db/fs), механизм i18n, быстрый шаблонизатор, html-purifier.
И в-третьих, простота и доступность для среднего (и даже начинающего разработчика): простота создания своих тем оформления (шаблоны расширяемые спец.тегами, базовая логика, вызов определенных функций, переопределение системных шаблонов), простой механизм расширений, плюс гибкость в вызове доп.кода (хуки, через определение спец.тегов, прямой вызов функций расширения из шаблона),
по большей части процедурный код.
Единственный минус на текущий момент — это отсутствие достаточного количества разработчиков/контрибутеров (коих на два порядка меньше чем у Друпала).
в общем, теперь еще тяжелее и еще медленнее…
может быть сторонникам друпала написать статью о том, почему стоит использовать этого монстра? а то я (как и многие другие, судя по комментариям) не вполне это понимают.
может быть сторонникам друпала написать статью о том, почему стоит использовать этого монстра? а то я (как и многие другие, судя по комментариям) не вполне это понимают.
Потому что в ограниченное время и с ограниченным человеческим ресурсом можно поднимать достаточно сложные по структуре и практически неограниченные по функионалу сайты. Ресурсы железа, правда, желательно чтобы тоже были неограниченные :) Но тут еще и от кривизны рук зависит.
Ну а можно за день-два клепать визитки по готовой схеме с неограниченным потенциалом для их дальнейшего развития. Ну и еще есть множество других кейсов.
Также следует отметить, что все это возможно только при условии обладания достаточными знаниями.
Ну а можно за день-два клепать визитки по готовой схеме с неограниченным потенциалом для их дальнейшего развития. Ну и еще есть множество других кейсов.
Также следует отметить, что все это возможно только при условии обладания достаточными знаниями.
UFO just landed and posted this here
Я с Друпал знаком мало (как и писал выше). Расскажите подробнее про механизм Views. Или может ссылочку на почитать. Только хотелось бы не документацию читать, а в «двух словах» описание работы механизма.
UFO just landed and posted this here
Расскажите подробнее про механизм Views.Визуальная система обращения к базе данных и вывод структурированных данных как нужно вам (так называемые представления). Вам не надо писать запросы к базе вручную, за вас это сделает Views, Укажите через интерфейс, что вам показать и он это сделает. Даже с условиями (аргументами). Даже из нескольких таблиц (с зависимостями). С вариантами показа (блоки, таблицы, списки), с выбором пейджера и количества показываемых страниц. Я не перечислю всего того, что можно делать с помощью Views.
В общем, довольная необходимая штука даже на небольшом новостном сайте, галерее, сайте-портфолио и прочих небольших проектах.
Вместо тысячи слов: drupal.org/project/usage/drupal — почти миллион учтённых активных, живых установок.
6 октября 45 загрузок восьмерки, семерку же загрузили 733,432
Это информация не о загрузках, а об использовании https://drupal.org/project/usage/drupal
8-ка же, пока только альфа и используется только в тестовых целях.
8-ка же, пока только альфа и используется только в тестовых целях.
Sign up to leave a comment.
Drupal 8 — революционные изменения