Вариант nodeblock, честно говоря, попросту пропустил, так как уже очень давно с ним не сталкивался в практике. Хотя bean по смыслу даёт примерно тоже самое. Если нужна именно нода, то её можно в панелях добавить.
С кастомным HTML получается то же самое, что и с полностью декаплд Друпалом.
Dries: In a fully decoupled architecture, our losses from having to rebuild what Drupal gives us for free outweigh the wins from client-side frameworks. With a fully decoupled front end, we lose important aspects of the theme layer (which is tightly intertwined with Drupal APIs) such as theme hook suggestions, Twig templating, and, to varying degrees, the render pipeline. We lose content preview and nuances of creating, curating, and composing content such as layout management tools. We lose all of the advancements in accessibility and user experience that make Drupal 8 websites a great tool for both end users and site builders, like ARIA roles, improved system messages, and, most visibly, the fully integrated Drupal toolbar on non-administrative pages.
Если для проекта лендинг является разово разработанным статичным информационным элементом, то почему бы и нет, можно и сверстать. Но что вы будете делать, если владелец сайта потом захочет самостоятельно исправить текст или его передвинуть?
Я с такой комплексной статьей, к сожалению, не сталкивался. Если кто найдет (или напишет), то будет просто замечательно. Собственно ссылку в след. дайджесте можно будет и дать.
Для меня это очень зависит от сложности содержимого по структуре; от того, кто будет наполнять сайт, и кто ещё в команде будет его разрабатывать. Если ты сам себе девелопер и верстальщик, и т.п., то может быть проще все на панелях склепать или вообще на блоках, и дальше решать проблемы по мере поступления.
С увеличением команды, сложности проекта и ростом нефункциональных требований, пожалуй, буду постепенно сдвигать фокус на уровень шаблонов, так как, в данном случае, имеется больший контроль над рендером и происходит разделение ответственности.
Что касается Beans, Paragraphs, Atoms — это, по мне так, всё для экзотичных (rich) структур содержимого, когда нет строгого макета ноды, то есть решал бы по обстоятельствам, но не в дефолтном режиме типа «всё, теперь делаю все сайты при помощи Beans».
Не получится добавить один новый сабмит, так как в webform_client_form_pages перезаписывается контекст $form_state. Тогда уже надо делать два сабмита: один до и один после, чтобы в первом сохранить оригинальный $form_state, а во втором вычислить необходимую страницу.
> Вы, может быть, и проделали большую работу и сделали полезное дополнение к WebForms, но статья ваша больше вредна, чем полезна. Её прочитают, модули пропатчат, а после обновления будут кричать, что всё сломалось.
В статье оставлен комментарий на этот счёт: «Решим поставленную задачу модификации поведения модуля Webform несколько грубо и нетипично для Drupal, внеся ряд изменения напрямую с целью экономии времени. В будущем их вполне можно будет выделить отдельно и создать отдельный модуль.».
В Quiz несколько смущает отсутствие стабильной версии для 7.x, и там, насколько я знаю, не является родным функционалом вывод нескольких вопросов на страницу.
Я с вами полностью согласен, что модифицировать чужой код — это моветон, но здесь одним небольшим hook_form_alter не обойдёшься, так как вызов немодифицируемой _webform_client_form_rule_check есть уже в функции webform_client_form, а также в webform_client_form_submit, из-за чего придется копипастить 10% кода.
Честно говоря, на момент реализации очень спешил. Чуть позже обязательно оформлю изменения в виде отдельного модуля.
Ядреные блоки?
(про Nodeblock комменатрий съехал)
Если для проекта лендинг является разово разработанным статичным информационным элементом, то почему бы и нет, можно и сверстать. Но что вы будете делать, если владелец сайта потом захочет самостоятельно исправить текст или его передвинуть?
И помогите доделать там уже Drupal 8 :)
С увеличением команды, сложности проекта и ростом нефункциональных требований, пожалуй, буду постепенно сдвигать фокус на уровень шаблонов, так как, в данном случае, имеется больший контроль над рендером и происходит разделение ответственности.
Что касается Beans, Paragraphs, Atoms — это, по мне так, всё для экзотичных (rich) структур содержимого, когда нет строгого макета ноды, то есть решал бы по обстоятельствам, но не в дефолтном режиме типа «всё, теперь делаю все сайты при помощи Beans».
> Вы, может быть, и проделали большую работу и сделали полезное дополнение к WebForms, но статья ваша больше вредна, чем полезна. Её прочитают, модули пропатчат, а после обновления будут кричать, что всё сломалось.
В статье оставлен комментарий на этот счёт: «Решим поставленную задачу модификации поведения модуля Webform несколько грубо и нетипично для Drupal, внеся ряд изменения напрямую с целью экономии времени. В будущем их вполне можно будет выделить отдельно и создать отдельный модуль.».
Честно говоря, на момент реализации очень спешил. Чуть позже обязательно оформлю изменения в виде отдельного модуля.