21 ноября 2019 в 15:18
Доброго времени суток друзья! Прошу вас подсказать как в drupal 8 можно интегрировать свою верстку со своими классами, со своей структурой блоков. Вставляя в шаблон регионы, а в регионы элементы, моя верстка полностью изменяется. Если делать для каждого элемента верстки шаблон, будет ли это снижать скорость загрузки страницы и работы сайта? Подскажите может быть есть какой нибудь лучший способ Спасибо.
Комментарии
Верстать сразу на друпале, а не заказывать сначала на стороне статичную верстку, а потом искать того, кто бы это чудо "интегрировал".
Кстати, такой вариант дешевле выходит плательщику. Да и по времени профит лучше.
https://www.drupal.org/docs/8/theming/twig
Спасибо за ответ. Дело в том, что верстки нет еще. Просто есть определенный подход к созданию сайта и хочется делать верстку не из того, что drupal по умолчанию выдает, а учитывая нужды дизайна.
Посмотрите готовые на темефорестере и монстрах.
Спасибо и вам.
Знаете как сделать верстку без Друпала - хорошо. Очень полезные знания.
Самый правильный ответ в 1-м комменте.
Сделайте сайт без и делайте верстку для того что Друпал выдает.
Чтобы не было всяких .block-15 {...} вешайте классы на блоки, регионы, поля views. Большинство классов можно из админки задать часто вспомогательными модулями. Но и в шаблонах можно классы задавать и менять разметку.
Вот точно не "самый правильный". А скорее, даже, наоборот.
Что не правильно?
Я могу согласится что, может кому-то и легче сначала сделать верстку, а потом внутрь нее элементы программно выводить. А кому-то наоборот удобно panels, bricks и т.п. варианты формирования контейнеров на сайте.
Думаю можем сойтись во мнениях на том, что не нужно заказывать верстку и натяжку у разных незнакомых людей.
Если коротко - верстка "по Друпалу" это колхоз.
Верстка вообще не имеет ничего общего с системой управления содержимым и никоим образом не должна влиять ни на работу дизайнера, ни на работу верстальщика (и, да, это должны быть разные люди).
А то, что Друпал навязывает кучу собственных подходов, отход от которых, часто, может привести к неправильной работе - это скорее недостатки самого Друпала, с частью из которых, все же можно справиться.
Вероятно, если работа с Друпал постоянная - стоит обзавестись собственным верстальщиком, который будет в курсе всех этих Друпал-вейев, без которых "никак", и верстать уже с их учетом.
Но! Ни в коем случае, инструмент (такой как Друпал) не должен влиять на работу других подразделений, или диктовать кого из специалистов нанимать.
Параграфо-панельки - это все инструменты, прежде всего, для контент-манагеров, но никак не для верстальщика. Он должен только взять, и привязать шаблончик к динамике, и для этого у них есть все возможности.
Заказывать нужно то что тебе нужно, конкретно, а не то что тебе диктует один из инструментов. И никак иначе.
Ты очень сильный теоретик. Таких любят на собеседованиях на аутсорс-позиции с почасовкой и импортным заказчиком. Но парадокс в том, что экономика работает по-другому. Вот смотри: чистая вёрстка - это ок, ничего не имею против. Но верстальщик - это одна из наименее квалифицированных специальностей в ИТ. Что мы имеем при чистой вёрстке: низкоквалифицированный работник сидит в своей зоне комфорта и делает чистую вёрстку, в то время, как значительно более высокооплачиваемый работник после верстальщика тратит десятки часов на создание шаблонов, написание препроцессоров и прочих хук-форм-альтеров, попутно проверяя (или не проверяя, потому что сроки и бюджет жмут), чтобы никакие аяксы не послетали в результате таких манипуляций. В результате получаем верстальщика, который не развивается, т.к. от него ничего нового не требуют, бэкендера, который не развивается, потому что все мыслепатроны потрачены на организацию структуры папок с шаблонами и прочую ерунду, и невероятно разросшийся бюджет проекта.
Если же верстать "по друпалу", то в вёрстке будут лишние классы и обёртки. Плохо ли это? А ты подумай, кого это волнует, кроме "теоретиков, которых любят на собеседованиях"? Это не волнует ни заказчика, ни пользователя. Это не влияет на производительность. Это снижает цену и сроки разработки. Так зачем вообще забивать себе этим голову?
Ну, во-первых, я бы не стал так брать и деквалифицировать всех верстальщиков. Они совсем не обязательно умеют только верстать. А порой и вовсе - хорошего версталу найти днем с огнем не получается.
Кроме того, если верстальщик сидит и только верстает - это не просто его "зона комфорта" (что в само по себе ничем не плохо), а прежде всего, его основная сфера деятельности. Никто же не свистит вслед пилоту, который сидит в своей зоне комфорта и то и делает, что самолеты сажает, не развиваясь совсем.
То что есть спецы которые знают весь стек - это нормально, а то даже и круто. Но это не значит что должно быть только так, и никак иначе. И я не говорил, что никто не должен знать ничего, кроме того чем занимается, если что. Но, когда каждый занимается своим делом - можно построить намного более эффективную работу (, а не потому что так "более правильно в теории").
Навскидку, по верстке:
Если уж говорить с т.з. теории:
Смысл в том, что не нужно думать о сайте как о едином целом (в рамках реализации, имею ввиду). Делая верстку - не должно быть мыслей о том как это будет работать в Друпал. Делая Друпал - не должно быть мыслей о том, как отображать все это. Это называется разделением ответственности. Верстка, по-сути, может быть из любого источника. Это может быть другой человек, другая студия, покупной шаблон, сгенерированный макет и даже тот самый разработчик, пишущий и весь остальной сайт. То, чем верстка будет драйвиться - не должно иметь значения. Когда делается верстка, задача - создать отображение, в соответствии с определенными требованиями. Когда делается Друпал, задача - создание хранилища данных, решающее вывод этих данных, в соответствии с требованиями.
Вообще, месседж был о том, что вариант "верстать сразу на Друпал" - не может быть "самым правильным". Это выходит за рамки общей практики (а Друпал - это лишь малая часть общей отрасли, оочень сильно маленькая). Так что ж теперь, говорить всем спецам со смежных технологий что "вам ннада бы подучиться, раз хотите с нами Друпал работать, а все эти ваши стандартные знания забывайте, у нас все свое"? Первая реакция на такое будет - "а может ну его, этот Друпал, раз с ним столько гемора?", и в этом они будут правы. Кому нафиг нужен будет такой Друпал, с таким дерьмовым DX?
Верстать "по Друпалу" - не является смертельным грехом или нарушением закона. Все вполне вправе делать все так, как хотят. (И конечно же, я тоже так делал, и не исключено что буду так делать когда-нибудь еще.) Но, нужно стремиться во всем соответствовать текущими практиками и подходами. Идти в ногу со всеми (сорри за клише!), а не отделяться и закапываться в своих внутренних реализациях. Ящитаю.
В конце-концов, каждый сам выбирает как работать.
ЗЫ - лишние классы - не плохо. Как и изменения конечного макета без потери функциональности, в целом. Это влияет на производительность. Цену - да, может снижает, сроки - совсем не факт. Забивать этим голову - как раз для того, чтоб не оказаться тем самым чуваком, который сидит в своей зоне комфорта и не развивается. Так делают профи ( я слышал ? ).
Вот это всё, что ты описал, очень хорошо работает в decoupled проектах. Возможно, если не отрывать друпалу галаву́, то это норм работает для больших проектов с большой командой. Но для маленьких сайтов, коих в интернете подавляющее большинство, это лишнее усложнение процессов.
Работает в одинаковой степени для всех типо-размеров.
Правки есть и на мелких сайтиках. И боль от таких правок - так же неприятна.
Просто намного проще верится в отговорки на меньших масштабах, но стоит держать в голове мысль о том, что любой мелкий проект может добавить, со временем. И проблемы, заложенные на старте - останутся теми же проблемами, изменится только частота работы с ними.
Но, да, я понимаю о чем ты. Есть такое.
Если я задаю классы блокам, полям во вьюхе - значит я верстаю по классам, а не по Друпалу?
Оооу... По моему личному мнению, а оно наверняка не сойдется с кучей других, возможность задавать верстку с админки - одна из худших фич Друпала.
Это исключительно из эгоистических соображений, если что. Всегда бесило что какой-нибудь бамбл, которого попросили "глянуть быстренько сайтик, подправить немножко", вынужден как идиот мотаться и угадывать все вероятные источники, в которых эти самые классы могут быть определены, переопределены, за-альтеренны и пере-прегреплейснуты перед выводом, кем-то когда-то. А они все, по разным местам и разными способами... Нельзя просто так взять, и Shift-Ctrl-F.
Хорошо, допустим есть задача: вывести список сотрудников. Делаю вьюху. Сегодня сотрудники - это ноды. Завтра выяснится, что это должны быть пользователи или даже товары. И поля будут другие. Завтра выяснится, что нужно переходить на D8, соотв. в нем классы тоже будут иными.
Если я задаю классы, блоку и полям - мне под новые варианты вывода совсем чучуть надо верстку изменять.
Верстку нужно менять, только если верстка меняется. Если нужно лазить в стили на каждый чих - что-то сделано не правильно.
Хм, я думал, только у меня такие проблемы, из-за недостаточной глубины погружения в нюансы верстки для Drupal.
Сам я верстаю редко, только когда нет возможности скинуть верстку, специально обученным, специалистам.
Но когда приходится, это киздец.
10-20% времени на полезную работу, остальное - на войну с шаблонами и селекторами темы оформления и системой темизации Drupal и т.п..
Селекторы могут быть "зашиты в шаблон, в различные препроцесс и тому подобные хуки, добавлены модулями типо block_class, layout_class, menu_class и т.п. *_class.
Так как терпеть такое нет никакой возможности, а поломать голову - любимое развлечение, взялся я темку и вспомогательный модуль писать.
Задача №1 - свести всю работу с css-селекторами в одно место.
Сначала думал все перевести в twig-шаблоны, расширив их функционал доп. классами-объектами.
Но уперся в ограничения twig, оказывается он строго за этим следит, чтобы никто не использовал в шаблонах всякие сторонние классы и их методы.
Побороть, конечно можно, но это имхо больше похоже на костыль.
Сейчас, думаю, все это дело организовать в гуе.
Подзадачи:
1.Организовать системную "классификацию" элементов страниц Drupal, например по технологии BEM.
2. Дать возможность сайт-билдерам управлять дополнительными селекторами html-элементов в GUI:
добавлять новые, отключать ненужные (устанавливаемые ядром и модулями) как для всех типов элементов, так и персонально для отдельных страниц, типов страниц, типов контента, блоков и т.п.
Если есть неравнодушные или хотябы сочувствующие спецы по верстке, было бы интересно и полезно выслушать мысли, идеи, замечания, пожелания, предупреждения, советы и т.п.
Естественно, при наличии интереса, для более конструктивного обсуждения выложу проект на гитхаб с самой свободной лицензией.
Всем спасибо друзья! bumble! Спасибо за ссылку. Буду разбираться.