Drupal → Что вкусного будет в Drupal 8

Drupal 7 и ниже, заточен на вывод только HTML контента. Drupal 8 же сможет отдавать контент в XML, JSON и других не-HTML форматах

На заметку: MODx ещё в ветке Evo умел это делать. Но у него косяков поболее будет чем у D.

Ура!
В качестве дополнения приведу цитату из старой, но удачной статьи sun'а http://www.unleashedmind.com/en/blog/sun/drupal-8-the-path-forward
---------
** Предполагаемая архитектура Drupal 8 **

Каждый "кусок" контента имеет свой URL
- GET /system/block/user/whos-online вернёт HTML для блока "Кто онлайн".
- Страница содержит несколько таких "кусков", которые запрашиваются как подзапросы родительского (главного) HTTP-запроса страницы.
- Ответ на любой URL-запрос может кэшироваться (Забудьте о кешировании Drupal-блоков.)

HTTP at the core: Контекст запроса и универсальный контейнер ответа (Response container)
- Объект Request служит контейнером для HTTP-запроса и содержит всю связанную с запросом информацию:
- загруженные "menu router"-аргументы
- $_GET, $_POST, $_SERVER и т.д.
- Связанные с запросом параметры друпала (current_path(), request_path(), URL alias)
- Другие контекстные данные ($user, $language, $language_content и т.д.)

- Объект Response отвечает за то, чтобы каждый ответ содержал такие стандартные элементы как:
- HTTP-заголовки
- Тело ответа

RESTful router
- Встроенное определение типа контента на основе заголовка HTTP Accept или формата файла
- Встроенная поддержка для типов данных, отличных от HTML (JSON, XML и т.д.)
- Более тонкая поддержка разных HTTP-методов (GET, POST, PUT, DELETE)

Синхронизированная подсистема конфигурации
- Конфиги хранятся и в базе, и в файлах
- Настройки по умолчанию для модулей и инсталляционных профилей хранятся в файлах, которые автоматически импортируются в базу при установке
- Все таблицы, содержащие настройки (настройки типов материалов, настройки словарей таксономии и т.д.) будут преобразованы в Config-объекты
- Файлы конфигурации будут легко контролироваться системами контроля версий и переноситься (предполагается, что Features больше не будут нужны)

"Content blocks" и "layout blocks" — плагины
- Все "куски" контента (включая page callbacks) будут преобразованы в "Content block"-плагины, которые можно сравнить с CTools content plugins. (block не от слова Block из admin/structure/block, это вообще не связанные вещи)
- A content block plugin on its own is a PHP class only. It merely defines the type of content. A block plugin does not represent or "show" a particular piece of content - if a block plugin can render a specific thing such as a certain entity, then that is configuration. (thus, block plugins are not to be confused with Block module's custom blocks)
- "Content block"-плагин — это просто PHP-класс, который определяет тип содержимого. "Content block"-плагин не темизирует и не выводит какой-то конкретный контент.
- Одному плагину может соответствовать один или много "Content block"-экземпляров. Каждый экземпляр имеет свою конфигурацию.
- Помимо "Content blocks"-плагинов будут существовать также "layout blocks"-плагины (можно сравнить с CTools layout plugins).
- Есть лэйауты различных уровней: Layout, Region, Block. Каждая страница использует определенный Layout, каждый регион в нем может содержать "Content blocks"-плгины или "layout blocks"-плагины, которые снова могут содержать регионы, которые снова могут содержать.. ну вы поняли.
- A block instance may be placed/configured for a certain layout. The configuration of the block instance is always the same though.
- Экземпляр плагина "Content blocks" может быть выведен/сконфигурирован для конкретного лэйаута.
- Простые куски контента (лого, имя сайта и т.д.) будут сконвертированы в "Content blocks".
- Each plugin always gets the Request container and configuration passed into it, so it has full context.
- Каждый плагин получает полный контекст в виде объекта Request и конфигурации.
Все это можно сравнить с Ctools, но сделано это будет по-другому.

Плагины и заменяемые подсистемы
- Предлагаемая система плагинов будет использована не только для "Content blocks" и "layout blocks", но также заменит множество специфических систем в ядре, таких как drupal_mail_system().
- Будет использваться PSR-0 namespaces стандарт для PHP. Это значит, что многое можно будет подключать "по запросу" (lazy-load).
- Теоритически, ценые подсистемы смогут заменяться contrib-решениями с помощью Dependency Injection container ("Service container").

Всё :)

@kalabro спасибо большое! :)

@xandeadx, отформатируешь? а то твой спам-фильтр меня не взлюбил :)

Twig кстати еще под вопросом. Менять шило на мыло (phptemplate на twig) я не считаю особо нужным.
Ну и слиняение с симфони очень интересно. Как они там api перемешают...

Мои 5 копеек по теме новых фич ядра http://emzzy.com/blog/drupal/drupal-8-iniciativy-yadra

так когда оно выйдет говорится?

вандам http://xandeadx.ru/blog/drupal/533

Обещания немного пугающие — столько всего нового и чудесатого!

Никто не считает что впиливание в ядро друпала Symfony 2 порождает две проблемы:

- Dependency injection;
- К моменту релиза, само ядро симфони притерпит некоторые изменения?

З.Ы. Я не специалист по симфони, поэтому среднюю скорость минорных (а уж тем более мажорных) релизов не знаю.

@holdmann, ну вообще крутые ребята говорят, что DI это то что доктор прописал

по ходу Symfony в PHP, это как jQuery в js.

@kalabro: Я понимаю, что симфони дает более гибкие апи для построения системы изнутри, если мы говорим об ORM к примеру (ведь вправду зачем изобретать велосипед, если есть доктрина?).

Я пытаюсь понять зачем использовать куски симфони не опираясь на базовые концепты ООП и MVC, на которых она сама построена :)

js кстати отлично может существовать без jQuery, вспомним к примеру Mootools.
ну и на самом деле Zend в php - то что доктор прописал.

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

@holdmann,
https://speakerdeck.com/u/fabpot/p/symfony2-meets-drupal-8 29-й слайд — какие "куски" (на самом деле хорошо оттестированные компоненты) предлагаются для D8 (выдрала ссылку на слайд).
С 24 по 26 слайд на всякий случай показано, как подобные "куски" успешно используются в других проектах, в том числе в Silex.

js кстати отлично может существовать без jQuery, вспомним к примеру Mootools.

я же не сказала что Symfony незаменима, я сказала, что она по ходу как jQuery ;)

по Zend к сожалению не прокомментирую, но вы кажется прыгаете с паттерна DI, на фреймворк, который этот паттерн также реализует.

А будет ли "Аналог Features" включать что-нибудь для многоуровневых и воспроизводимых миграций базы данных (а-ля Ruby On Rails). Мы вот без этого страдаем особенно люто, каждый раз накатывать на продакшн обновления, связанные с правками структуры БД, вручную и с опаской.

В принципе и сейчас можно по-людски деплоить: features & strongarm & uuid

В принципе и сейчас можно по-людски деплоить: features & strongarm & uuid

Не подскажите, где можно ознакомиться на русском с описанием всего процесса?

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

на русском

Это я, пожалуй, загнул :-) Можно и на понятном английском.

Cуть не в базе, весь подход основан от абстрагировании от базы.

features - экранирует сущности в код
strongarm - экранирует переменные в код
uiid - создает глобал уникью ид для всех сущностей (уникальные вне зависимости от типа последней)

Ну и соответственно, система контроля версий отслеживает изменения кода.

Тогда процесс деплоя выглядит следующим образом - Берется нулевая инсталяция друпала, выбирается нужный ревизион и делается апдейт.

Я только в текущий момент не могу понять как обойтись без тыкания кнопок в админке (импорт сущностей и материалов). =(

З.Ы. ссылок как вы понимаете нет, все урывается кусками где попало)

А будет ли "Аналог Features" включать что-нибудь для многоуровневых и воспроизводимых миграций базы данны

я плохо представляю как это можно автоматизировать

я плохо представляю как это можно автоматизировать

Например, как в RoR: http://rusrails.ru/rails-database-migrations или http://rubydev.ru/2012/02/ruby-on-rails-tutorial-rails-3-migrations/

Всё равно же с каждой мажорной версией и в Drupal растёт уровень абстракции БД.

Ну так логично все.

Если мы, допустим, имеем бд, на основании который генерируются модели (в представлении мвц), то миграции нужны и необходимы.

В данном случае, бд генерируется из массива (see hook_scheme()), поэтому и процедуру деплоя следует завязывать на этой генерации.

Drupal Conf 2012 презентация про CI

Я только в текущий момент не могу понять как обойтись без тыкания кнопок в админке

Фичи имеют очень хорошую интеграцию с Drush

Хм... буду свой обзор переделывать ;)

WYSIWYG редактор Aloha Editor.

Aloha променяли на CKE4
http://buytaert.net/from-aloha-to-ckeditor

И мои 5 копеек.. о том что нас будет ждать в восьмерке
Что нового в Drupal 8

Достойно нового поста про восьмёрку: https://groups.drupal.org/node/313408

у меня сегодня с утра была именная такая мысль)

Главное будет file-based configuration storage.