25 ноября 2015, 13:52

Drupal 8.0.0 — новая версия популярного движка для сайтов с открытым кодом на PHP

Интерфейс Drupal 8
Иллюстрация с сайта Drupal.Org

На прошлой неделе был представлен новый крупный релиз одной из популярнейших CMS/CMF-систем с открытым кодом, написанных на языке PHP, — Drupal 8.0.0.

Разработчики называют релиз Drupal 8 крупнейшим обновлением в истории проекта. Система получила полную совместимость с новой версией языка PHP 7, системами управления базами данных PostgreSQL и SQLite, а также сотни других улучшений. Наиболее значимые изменения в Drupal 8:

внутриконтекстное редактирование данных и предпросмотр (в стиле WYSIWYG);
моделирование контента «из коробки» (entities, fields, views);
кастомизация страниц содержимого, форм, административных страниц через интерфейс управления;
полная переводимость и локализуемость интерфейса из коробки;
надежное управление конфигурациями для переноса изменения среди окружений;
вывод контента в HTML5 с ориентацией на отзывчивость и мобильные устройства;
родные веб-сервисы с REST;
расширенная доступность (accessibility) и соответствие спецификации W3C WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications);
современные лучшие практики из PHP с интеграцией таких популярных библиотек, как Composer, Symfony2, Guzzle и Twig;
значительное улучшение производительности фронтенда;
продвинутое кэширование и улучшения в интеграции с CDN-сетями и обратными proxy-серверами.

Подробности о релизе Drupal 8 доступны на специальной странице www.drupal.org/8.

Постоянная ссылка к новости: http://www.nixp.ru/news/13658.html. Дмитрий Шурупов по материалам Drupal.Org.

CMS, Drupal, PHP, Web, релизы

Комментировать (5)

Илья Смирнов 19:42, 29 ноября 2015

Недавно я провёл тесты производительности при помощи утилиты ab на чистых инсталляциях Drupal с одинаковыми наборами модулей и 10 нодами на главной странице, а также вызовом админки, 100 раз по 100 конкурентных запросов.

Тесты, повторённые несколько раз, показали такие стабильные результаты: Drupal 8 в 3 раза медленнее, чем Drupal 7, и в 5,5 раз медленнее, чем Drupal 6. Результаты для главной страницы и для админки примерно одинаковые.

Ответить Цитировать

B.X 02:02, 12 декабря 2015

Иногда приходится жертвовать производительностью ради функциональности. Вы никогда не считали насколько медленнее любая нагруженная CMS, чем статичные html страницы? Но функциональность-то как раз у CMS настолько же лучше, что все предпочитают именно их.

В ядро Друпала 8 добавили много нужных (критически необходимых для любой современной CMS) модулей, что не могло не сказаться на быстродействии. И Друпал 7 с этими модулями будет проигрывать Друпалу 8, потому что они у него уже в ядре. В этом всё дело…

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

Ответить Цитировать

Илья Смирнов 03:19, 12 декабря 2015

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

Я читал интервью с Дрисом Бёйтартом, где он, отвечая на вопрос о производительности Drupal 8, говорил, что благодаря кэшированию у Drupal 8 хорошая производительность. Потом я прочёл статью с результатами тестов, где говорилось, что производительность Drupal 8 существенно ниже, чем у Drupal 7. Я не поверил на слово и решил провести собственные тесты, поскольку субъективно при просмотре через браузер бета-версии Drupal 8 в админке работали очень быстро, быстрее, чем Drupal 7.

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

Я считаю, что, переход Drupal на фреймворк Symfony 2 — правильный выбор. Сообщество Drupal пополнится симфонистами. Также мне понятно, почему был выбран именно Symfony, а не какой-нибудь другой фреймворк — помимо большого сообщества разработчиков и мощного функционала, есть техническая причина: компоненты Symfony слабо связаны благодаря Dependency Injection, что позволяет легко использовать их независимо от самого Symfony.

Для выделенных серверов с кэширующим Nginx перед Apache — действительно, несущественно, что Drupal 8 медленнее, чем предыдущие версии. К тому же благодаря PHP 7.0, производительность которого по тестам в 2 раза превосходит производительность PHP 5.6, разница в производительности Drupal будет не так заметна.

Однако, я сомневаюсь в целесообразности использования Drupal 8 на shared-хостингах именно из-за производительности.

Drupal — самая мощная и хорошо продуманная из всех свободных CMS, которые я видел. Однако, как и любое другое решение, это компромисс.

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

Ответить Цитировать

B.X 06:11, 30 декабря 2015

Вы тестировали чистый Друпал 8 и 7? Но это же неправильно. Нужно тестировать чистый Друпал 8 и Друпал 7 с модулями, которые есть в ядре Друпала 8 по умолчанию. Потому что Друпал 7 без всех этих модулей совершенно неполноценная система.

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

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

Закономерно, что с выходом Друпал 8 — это ещё более вероятно. То есть, понятно, что при всей своей функциональности он обязательно будет требовать отдельно настроенного хостинга. Это разумно и логично.

Ответить Цитировать

Илья Смирнов 21:47, 30 декабря 2015

Вот полный список включённых модулей Drupal 7 (31 модуль):

Block, Book, Color, Comment, Contact, Content translation, Contextual links, Dashboard, Field, Field SQL storage, Field UI, File, Filter, Help, Image, List, Locale, Menu, Node, Number, Options, Overlay, Path, RDF, Search, Shortcut, System, Taxonomy, Text, Toolbar, User.

И список включённых модулей Drupal 8 (44 модуля):

Automated Cron, Block, Book, Breakpoint, CKEditor, Color, Comment, Configuration Manager, Contact, Contextual Links, Custom Block, Custom Menu Links, Database Logging, Field, Field UI, Filter, Help, History, Internal Dynamic Page Cache, Internal Page Cache, Menu UI, Node, Path, Quick Edit, RDF, Search, Shortcut, System, Taxonomy, Text Editor, Toolbar, Tour, User, Views, Views UI, Content Translation, Interface Translation, Language, Datetime, File, Image, Link, Options, Text.

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

Однако я не стал бы утверждать, что Drupal 8 с набором модулей из коробки — это самодостаточная система, полностью готовая для сайта любой сложности.

По-прежнему в стандартной поставке отсутствует field_collection, без которого просто невозможно обойтись на большинстве задач, которые мне приходится решать. Также отсутствуют необходимые taxonomy_access, content_access, comment_perm, ctools, panels, а также очень нужный views_php, который позволяет задавать свой код в нужных полях и фильтрах views.

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