Анализ подходов для создания лендингов и лонгридов в Drupal

[biziwalker]

Хорошая статья! Кое-что новенькое узнал для себя

ИМХО но не нужно лендинги так скорпулезно связывать с CMS. На сколько известно, частота изменений макета и вообще время жизни лендинга не оправдывает затрачиваемое время на интеграцию с CMS. Рядовые обыватели, для которых вся интеграция и задумывается, обычно не компетентны и чаще стали экономить своё время и пользоваться услугами специалистов. А последним быстрее исправить в текстовом редакторе (или IDE), чем ковыряться в CMS — ведь так ребята? :)

[proshin]

Поддерживаю! Для лендинга вполне достаточно обычного HTML. Различные интерактивные элементы вполне реализуются или вручную на JS, или с использованием сторонних сервисов. Для создания тех же форм есть большое количество онлайн-сервисов, которые на выходе дают подключаемые в HTML скрипты/стили. У данного подхода есть один большой плюс — хостить это можно хоть на пылесосе, лишь бы интернет был.

[k0teg]

С кастомным 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.

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

[proshin]

Как говорится: «Выбирайте средства в соответствии с целями». Если заказчик хочет иногда сам вносить правки — выбор в пользу CMS будет очевиден. Однако, если со стороны заказчика правками будут заниматься компетентные люди, HTML всё еще может быть оптимальным выбором.

[UksusoFF]

Или например — http://textolite.ru

[croupier]

Если уж очень понадобится, то в 90% случаев, для хотелок типа поменять телефон, отлично подходит эта штука textolite.ru (особенно, если не заглядывать под капот). Вроде автор пытался пиарить её здесь.
Главный плюс в том, что её можно поставить за пять минут по первому требованию поверх обычного html-лендинга.

[xcono]

Так точно. C Drag&Drop трудно добиться качества, трудно сделать сложный макет, который выглядел бы прилично. Отличный выход — это использовать предустановленные Layouts через Page Manager, где верстка под контролем.

Но статья полезна для новичков, с тем чтобы разобраться в том, как можно быстро построить и легко переделать.

Page Manager + Paragraphs уже сносно можно использовать в восьмерке. Я думаю, что Paragraphs один из числа тех модулей, которые поддерживали популярность Drupal у «сборщиков» сайтов наряду с CCK, Views, Rules, Panels.

Если говорить о семерке, то можно упомянуть связку Page Manager + Ctool plugins (+ отключение Block), которая тоже себя хорошо зарекомендовала. Ctool плагин для контекста, доступа и контента.

Неплохо было бы упомянуть о Display Suite и Context, которые тоже достаточно популярны.

[xRay]

Paragraphs выглядит довольно привлекательно.
С возможностями можно ознакомится на демке http://paragraphs.site-showcase.com там же описаны дополнительные модули которые расширяют Paragraphs.

На мой взгляд не хватает только дистрибутива Paragraphs который бы разворачивал на локальном компе копию сайта http://paragraphs.site-showcase.com. Что бы на его примере изучить использование этого модуля.

[pr0g]

Тоже задавался вопросом, почему нет дистрибутива с демо Paragraphs. Интересно посмотреть как все настроено изнутри.

[k0teg]

Для восьмерки есть, например, пропиаренный недавно Дрисом Thunder.

[E_STRICT]

модуль Panels — ведёт свою историю аж от Drupal 6.

Drupal 4.7

[k0teg]

Исправил. Спасибо.

[vistar]

Ссылка в «что если вы панелизируйте» кривоватая.

Почему не рассмотрен вариант с ядрёными блоками и dgo.to/nodeblock?

[k0teg]

vistar, cпасибо за исправление.

Ядреные блоки?
(про Nodeblock комменатрий съехал)

[vistar]

Core blocks :)

Панели, это лишняя сущность — пользователю путаница лишняя. А так блоки, ноды — понятнее.

И, спасибо за обзор — есть что попробовать в будущем.

[k0teg]

Вариант nodeblock, честно говоря, попросту пропустил, так как уже очень давно с ним не сталкивался в практике. Хотя bean по смыслу даёт примерно тоже самое. Если нужна именно нода, то её можно в панелях добавить.

[xRay]

В 8-ке https://www.drupal.org/project/bean вошел в ядро. А https://www.drupal.org/project/nodeblock заменен https://www.drupal.org/project/entityblock

[AlexeyHoroshavin]

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

[xRay]

На что перешли Yii, Lavarel, Symfony, Phalcon?

[pvasili]

Была ещё хороша я идея с модулем bricks но очень и очень сырая и не доведённая до конца что в плане UI, что по реализаци. Всё время что-то не работало правильно :(

[k0teg]

Недавно появилась статья — https://www.chapterthree.com/blog/paragraphs-vs-eck-drupal-8, где авторы приходят к похожим выводам.