Panels - использовать или нет?

Главные вкладки

gun_dose 18 декабря 2016 в 17:52
3

Пожалуй, нет ни одного другого модуля под drupal, о котором мнения разработчиков будут так же диаметрально различаться, как о Panels. То, что модуль гибок и функционален, не вызывает сомнений ни у кого, но вот целесообразность его использования многие ставят под вопрос. Я долгое время избегал использования панелей, чтобы не перегружать сайт лишними (как мне казалось) модулями. Старался обходиться блоками, но со временем стал замечать всё больше и больше недостатков и ограничений блочной системы Drupal. Поэтому однажды я решил поглубже разобраться в панелях и понял, что они порой дают неоспоримые преимущества перед любыми другими решениями. Итак, поехали.

Когда нужно использовать Panels

1. Если нужно выводить поле контента в другом регионе, либо вставить блок между полями.

Это можно сделать и без панелей, через views + блоки, но ведь вьюху ещё нужно создать и настроить, а в панелях прямо из коробки доступны панели со всеми отдельными полями контента. Более того, тут будет прирост по быстродействию, т.к. панели используют уже загруженный объект ноды из контекста, а вьюс возьмёт nid из url страницы и полезет за полем в базу.

2. Вывести один блок одновременно в два региона.

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

3. Сделать разный шаблон для разных словарей таксономии.

Если вам нужно выводить блок на страницах терминов одного словаря, а на страницах другого не нужно, то кроме панелей, это ничем не решить. Можно, конечно, сделать костыль - включить пхп-фильтр и задать в конкретных блоках пхп-условие видимости, но php-фильтр лучше не использовать никогда. И вообще, панели работают с таксономией значительно лучше, чем тот же Taxonomy Display. В частности, при использовании Taxonomy Display не работают Ajax Facets.

4. Работа с фасетами

Во-первых, при использовании панелей не нужно создавать тот странный невидимый блок для фасетов. Во-вторых, в интерфейсе фасеты идут отдельной категорией, не смешиваясь с остальными блоками. Тот, кто делал магазин хотя бы на 20-30 фасетов, должен оценить это преимущество.

5. При наличии в дизайне сайта большого количества разных шаблонов со сложной структурой колонок.

Во-первых, панели позволяют использовать гибкие лэйауты либо легко создавать свои. Есть также модуль Radix Layouts, который сожержит около 30 разных лэйаутов, совместимых с bootstrap. Во-вторых, как было сказано выше, вы можете выводить один блок в разных лэйаутах в разные регионы, что не позволяет делать блочная система. В третьих, при использовании CSS-фреймворков с сетками, вы можете легко задавать панелям нужные классы и id, чтобы выстроить их по сетке.

6. Если нужно выводить на страницу что-то дико кастомное.

Панели используют Ctools API, которое позволяет легко выводить что угодно и как угодно при довольно простом коде. Более того, подобные задачи - одни из самых любимых на собеседовании у многих работодателей, поэтому овладеть этим кун-фу будет в любом случае полезно Smile

Когда не нужно использовать Panels

1. Когда у вас на сайте всего три одинаковые страницы и полтора блока.

2. Когда вы не поняли ничего из того, что было написано выше Smile

Примечания

1. Чтобы не сломать головной мозг, при использовании панелей лично я рекомендую использовать в теме всего один регион, в котором будет всего один блок. В крайнем случае можно вывести ещё хэдер и футер, но в этом далеко не всегда есть необходимость.

2. Всё вышесказанное относится к Drupal 7, в восьмой версии функционал панелей сильно урезан, а функционал блоков наоборот - расширен.

И традиционная спам-ссылка на оригинал статьи в моём говноблоге: http://wellsolutions.by/article/panels-ispolzovat-ili-net

Автор

Комментарии

Аватар пользователя gun_dose gun_dose 28 декабря 2016 в 15:59

2 мегахита норм) Но там уже немного другие требования и способы оптимизации будут, нежели к магазинам с посещалкой в лучшем случае в тысячу в сутки. Если с миллиона посещений сократить время отклика сервера даже на 1мс, то будет сэкономлено две тысячи секунд процессорного времени. Если же этим заниматься на сайте с тысячной посещаемостью, то это попахивает идиотизмом.

Аватар пользователя sergeybelya sergeybelya 27 декабря 2016 в 14:48

gun_dose wrote:

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

Так уж и ничем.
https://www.drupal.org/project/context_block_visibility
https://www.drupal.org/project/block_visibility_vocabulary
Можно средствами ядра, задав маску по урлам (если используется pathauto)

Аватар пользователя Studio VIZA Studio VIZA 27 декабря 2016 в 14:50

VasyOK wrote:

можешь в теме голосование поставить

С Опросами Мбаев траблу решает вроде, щас они вызывают кризис среднего возраста у Хрома.

Аватар пользователя fairrandir fairrandir 28 декабря 2016 в 18:03

Бюджет, батенька. И дедлайны.
Панели это плохо. Зато быстро и недорого.
Сайты с большой посещалкой - скорее редкость, чем правило. И как правило они такие не с нуля, а с историей, и парой переездов с платформы на платформу.

Аватар пользователя bsyomov bsyomov 28 декабря 2016 в 20:18
1

Вот, блин, Фома-то неверующий. Хоть и с потолка были цифры взяты, но бывает и больше 3 раз, хотя, конечно, это далеко не всегда так. А вот 1,5 например бывает часто, и это тоже очень много.
Я уже говорил - devel + xhprof, настроить 2 минуты. Хоть ради интереса убедись, что всё действительно довольно плохо с ними.

Аватар пользователя gun_dose gun_dose 28 декабря 2016 в 20:51
1

Для чистоты эксперимента надо брать сложный сайт и перенастраивать его так, чтобы панели не использовались и чтобы при этом в дизайне ничего не изменилось. Это может занять несколько дней работы. Поэтому мне действительно проще открыть таймлайн в хроме и увидеть, что сайт с панелями с обычного шаред-хостинга без какого-либо тюнинга производительности грузится за 0.6-0.8с и радоваться, что я не тратил лишние часы и дни разработки, чтобы угодить какому-то Борису с друпал.ру))))

Аватар пользователя bsyomov bsyomov 29 декабря 2016 в 0:56
1

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

Переделать, кстати, достаточно буквально одну страницу и её и замерять. Это не такая сложная работа, чтобы её, даже просто из любопытства не проделать.

Да - 0,8с, кстати, это не слишком-то хороший результат, особенно, если это всего лишь TTFB. А если при этом Load 1+c, то уже и фейл.
И кстати, а сколько без кеша при этом - небось и не смотрит никто? Кеш-то у панелей не протухает и регенирируется святым духом, ага.

Аватар пользователя gun_dose gun_dose 29 декабря 2016 в 8:03

Мне не надо угождать себе. В первом абзаце первого поста написано русским по белому, что обходиться без панелей я прекрасно умею. И выводы об их быстродействии я делаю по собственному опыту, а не так как некоторые "кококо, одминка сложная! Надо вырубить скорее, а то наверное жрёт как конь"

Вон, кстати, орион ниже расписал про контекст. И вот действительно, занятный пример - надо вытащить картинку из ноды в другой регион. Как это сделать без панелей, но так, чтобы не делать запрос в базу и не грузить сущность по ид?

Аватар пользователя bsyomov bsyomov 29 декабря 2016 в 17:07

Занятный пример непонимания в вашем примере: панель по вашему магически получит информацию из эфира, видимо, не делая запросов? Или загрузка уже загруженной где-то сущности по id из статического кеша создаст запрос?
Или вы думаете, что панель возьмёт информацию из кеша а другой способ потребует запроса? Это не так - слоёв кеширования в друпале может быть немало, кеш панелей не единственный, и не "самый оптимальный на все случаи жизни".

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

Запомните простую истину: Всегда универсальные и настраиваемые решения более ресурсоёмки, чем специализированные, выполняющие одну свою функцию. И чаще всего более ресурсоёмки, даже, чем система таких решений выполняющих сложный набор функций.

И опять: "кококо, одминка сложная! Надо вырубить скорее, а то наверное жрёт как конь" - нечего сказать по существу? Чтож, понимаю. свои ошибки сложно признавать.

Мне не надо делать предположения. Я смотрю на случаи применения панелей регулярно и с профайлером.

Аватар пользователя multpix multpix 29 декабря 2016 в 17:18

Все по существу, да не по адресу))))

Суть в том, что для большинства дру это в первую очередь field_ui, views_ui, ds, panels и им подобные.
Это ниша друпал.

Да можно писать - говорите вы,
да, можно писать - но!
Но тот кто может писать - смотрит на предполагаемый объем необходимой писанины, и пишет не на дру.

@gun_dose, панели это зло, но применять их никто не запрещает)
Удобно? Делай!
suum cuique

Аватар пользователя bsyomov bsyomov 29 декабря 2016 в 17:24

Очень удачно список написан. Smile
Вопрос в том, что на views_ui чаще всего, в этом списке разумно и остановиться, и при этом всё ещё ничего лишнего не писать. А тему оформления-то всё равно делать.

Аватар пользователя gun_dose gun_dose 29 декабря 2016 в 17:20

Панель делает запрос один раз на страницу. И в дальнейшем объект ноды доступен в контексте. Если же выводить вьюсом или программно поле ноды в соседний регион, то объект ноды придётся грузить повторно.

Аватар пользователя bsyomov bsyomov 29 декабря 2016 в 18:00

Это не совсем так, и довольно легко проверяется. Надо сделать два вызова node_load() с одним и тем же nid и посмотреть на лог запросов, или ещё лучше, в профайлер.
Второй раз загрузки ноды из базы не произойдёт, если не не передать параметр reset = ture, причём это будет работать даже без entity_cache например.
Некоторые стандартные сущности статически кешируются, ноды в частности.

Если загружать одно поле где-то отдельно views, да, тут будет запрос. Но он будет, при этом, очень простым, и по индексам. И даже, если забыть о кешировании, этот оверхед может быть меньше, чем оверхед от панелей.

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

Аватар пользователя negociant negociant 29 декабря 2016 в 18:06

gun_dose wrote:

Если же выводить вьюсом или программно поле ноды в соседний регион, то объект ноды придётся грузить повторно.


А если вспомнить, что вся страница у друпала - один рендерный массив, в котором можно переместить что угодно и куда угодно?
Есть же hook_page_alter и hook_page_build http://drupal.stackexchange.com/questions/31488/using-hook-page-alter-to...
Только не надо говорить, что menu_get_object() (node_load) станут делать дополнительные запросы

Аватар пользователя bsyomov bsyomov 28 декабря 2016 в 20:21

Поставлю на то, что можно запустить и на 16, если отказаться от Drupal, и даже не менять окружение(php+mysql). Smile Но мы-то тут его обсуждаем...

Аватар пользователя gun_dose gun_dose 28 декабря 2016 в 18:49
1

Ну вот, один не любит панели, потому что не любит друпал, второй просто не любит панели. Вот и вся аргументация.

Аватар пользователя Orion76 Orion76 28 декабря 2016 в 21:37
3

Про "тормознутость" панелей..
Выводить "статичный" контент НЕ ИЗ кэша, мягко говоря - плохо.
А кэш у панелей работает - дай бог каждому..
Нехватает какой-то "фичи" к кэшу (хитрой логики кэширования и т.п.) - все достаточно несложно расширяется плагинами (ctools) - клаву в зубы и вперед.

Контекст панелей конечно не идеал, но имхо - лучший.
Тыщу раз выручал.

можно конечно функционал панелей реализовать кучкой модулей попроще, но в чем тогда выигрыш?
Плюс в Панелях все в куче:
Контексты
Управление доступом
Темизация (классы, шаблоны)
Разные варианты контента в зависимости от контекста
чего там еще, не припомню-)

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

А если разделов с десяток - хрен через неделю разберешь что и откуда растет..

Короче, если надо быстро, дешего, сердито, стандартно, гибко,расширяемо, поддерживаемо - Панели однозначно.

А "тормознутость" панелей - сказки для самых маленьких.

Аватар пользователя Studio VIZA Studio VIZA 29 декабря 2016 в 3:35

Вы бы хоть логику включили, панель это "фотоснимок", движку легче показать зафиксированную инфу, чем судорожно сгенеренную и с муками вытащенную из недр.

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

Аватар пользователя bsyomov bsyomov 29 декабря 2016 в 17:59

Панель не фотоснимок. Это инструкция, как нарисовать картину. А стандартная темизация, это нарисованная картинка, которую надо раскрасить.
Что проще сделать? Smile

Аватар пользователя Orion76 Orion76 29 декабря 2016 в 21:55
2

Тэкс.. все понятно.. что ничего не понятно-)

Парни и девушки, т.е. коллеги, вы скакой точки зрения смотрите на друпал и сайтостроительство в общем??

Я не устанно пропагандирую, и попробую не очень сумбурно сделать это снова, что не всегда удается-)

Друпал - это не палитра художника и не резец скульптора, с помощью которых можно явить миру гениальнейший шедевр сайтостроительства, который будет работать на сервере с первым пентиумом и 8 Гб Мб оперативы, и зарабатывать для владельца миллиарды.

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

Друпал это всего лишь инструмент для бизнеса .
Который может с небольшими затратами на разработку и достаточно быстро воплотить как минимум РАБОЧИЙ прототип необходимой функциональности.

Большинство из вас на своем опыте знают, что если адаптировать ТЗ заказчика под имеющиеся возможности Друпал и некоторых собственных наработок, большая часть проектов могла бы быть доведена до готовности "первого релиза", когда проект можно выпускать в паблик: за время - на порядки меньшее, а следовательнос на порядки меньшими затратами.

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

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

Вот для такого, когда нужно быстро воплотить бизнес-идею, посмотреть-потрогать ее в работе, а в дальнейшем с оптимальными затратами довести ее до совершенства - Друпал идеален.

А уже после этого, как завещал Кнут, можно заняться необходимой оптимизацией технической части проекта.

И вообще, во времена, когда быстродействие жестких дисков(SSD) опережает по быстродействию и стоимости оперативную память, а стоимость гигагерцев процессоров стремиться к нулю - для серьезных проектов, как минимум на первых этапах разработки-оптимизации бизнес-процессов экономия на этой самой оперативе и процессорах - откровенный саботаж-)..
Т.к стоимость рабочего времени разработчика в сравнении с подобной "экономией" - бесценна-))

И да.. чуть не забыл - помогают нам во всем этов эти самые Панели и прочие вьюсы + тысячи готовых, отлаженных тысячами разработчиков и протестированных миллионами пользователей готовых модулей с drupal.org.. ну и некоторые собственные гениальные наработки-))

Аватар пользователя gun_dose gun_dose 29 декабря 2016 в 22:39

Ты забыл отметить,что при расторжении договора после Бориса останется миллиард строк кастома, а после меня - панели + кастом в лучших традициях ctools, который, вощемта например, образец друпал-вэя.

Аватар пользователя bsyomov bsyomov 29 декабря 2016 в 23:00
3

Откуда?
Будет просто нормальная тема оформления и, возможно, реализовано несколько хуков в одном модуле. Строк так на 50-100. Редко нужно что-то большее, на самом деле. Это если вообще что-то подобное понадобится.
В остальном же это будут те же views, и другие контриб модули. Может там будут и панели, если надо будет дать возможность пользователю изменять раскладку страницы из админки например, вот только это нужно очень не часто на практике, а часто и вредно давать лишние возможности...

И вот это друпал вей, а не "накликай чудовище, которое будет с трудом работать".

Просто всему надо знать меру. И использовать имеющиеся инструменты с умом,а не с криками - "это такая охрененная штука, и я её обязательно засуну и в этот сайт!"

И кстати, написать несколько строк кода, бывает куда быстрее и эффективнее, особенно, если знать как это делается.

Аватар пользователя bumble bumble 30 декабря 2016 в 0:23
4

Если честно, буду куда более счастливым если на поддержку придет сайт с код-ориентированным подходом, чем когда с кучей GUI'ни.

А если будут хорошие doc'и (или, ну, куда в фантазиях не упорхнешь? - с README-описанием проделанной работы)... В таком случае и свечку, за здравие, бывшему проггеру можно не поленится поставить!

ЗЫ - Была практика поиска нужного "момента", в которой на выбор можно было искать во вьюхах, панелях, блоках (с контекст[ами]) и в добавок, среди кучи темплейтов.
Это больно...

Тогда тоже свечку прошлым желал.. но, анальную. (С перцем).

Аватар пользователя bsyomov bsyomov 29 декабря 2016 в 23:51
4

Здесь всё слишком упрощено.
1. Есть время генерации страницы. И оно не должно быть очень большим на любом проекте, а на многих проектах, это довольно-таки критичный параметр. Даже при создании прототипа это должна быть вменяемая величина. Она критична для конверсий, она критична для поиска и.т.п.
PHP не умеет распараллеливать обработку запроса на несколько ядер. Соответственно, апгрейд железа не поможет - всё упрётся в быстродействие одного ядра. Дальше можно ставить ещё процессоров, добавлять памяти, это будет просто без толку. Можно получить только бОльшую устойчивость к нагрузке, но не более отзывчивый сайт.
Можно построить вычислительный кластер, но это будет стоить даже в настройке сопоставимо с разработкой и потребует дорогого обслуживания.
Кеширование только отчасти может решить проблему. Кеш тоже не панацея - он перестраивается, иногда это бывает даже бОльшей проблемой вызывая пики нагрузки. А иногда кеширование и вовсе не применимо.

2. Стоимость и скорость разработки вы считаете определяющей? Стоимость эксплуатации всегда куда выше, если проект не однодневка. А ваш подход в целом, делает проект не только дорогим в эксплуатации, но и часто, ведёт к тому, что в целом в продакшен выпускается очень сырое решение. Да, это сейчас модно, но для бизнеса бывает черевато потерями денег и репутации.

Хотите смотреть с точки зрения бизнеса и считать деньги, так считайте всё, а не только расходы на разработку.

Ну и наконец, я не предлагал переписать все модули которые потенциально можно было бы использовать. Я предлагал думать, а нужно-ли в каждом конкретном случае жертвовать производительностью за, возможно, совершенно лишний функционал.
И панели это весьма показательный пример. Они не "серебрянная пуля", а кусок сложного, слишком универсального и тяжёлого решения, которое уместно отнюдь не везде. И часто, если можно без них обойтись, лучше так и сделать.
Нет такой принципиальной разницы во времени разработки для профессионального разработчика, как вы тут описываете, накликать лайаут панелями или сделать шаблон, особенно используя готовые сетки, или css фреймворки. Если это не так, то что-то, очевидно, не то с этим разработчиком.

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

Ну и наконец - инструмент бизнеса это ворд в котором пишется техническое задание. Smile А Drupal это уже инструмент разработчика его воплощающего.

Аватар пользователя Orion76 Orion76 1 января 2017 в 17:20

bsyomov wrote:
1. Есть время генерации страницы. И оно не должно быть очень большим на любом проекте,

Есть контент,который изменяется (утрирую для примера) 100 раз в день, а показывается пользователю 100 000 раз в день.
Как вы думаете, сколько раз после изменения контента имеет смысл генерировать html для показа пользователю?

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

т.е. если необходимо сэкономить серверные ресурсы - организуйте оптимальное кэширование, и со скоростью отдачи контента проблем не будет, и больше чем уверен, это будет несколько дешевле и в разработке и в эксплуатации чем разрабатывать тот же функционал на чистом ассемблелере, php api drupal.

Много раз видел, как для экономии серверных ресурсов разрабатывали аналог views, но который оказывался на порядки хуже того же views по параметрам, из-за которых и было принято решение разработать этот самый аналог.

bsyomov wrote:
2. Стоимость и скорость разработки вы считаете определяющей? Стоимость эксплуатации всегда куда выше, если проект не однодневка.

Прежде чем чтобы эксплуатировать что-нибудь ненужное, надо разработать что-нибудь ненужное-))

На самом деле, как минимум по моему опыту, еще не разу по первоначальному ТЗ не удавалось разработать сразу приложение, решающее с достаточной эффективностью возложенные на него задачи.
Или после ввода в эксплуатацию его приходилось как минимум дорабатывать, а часто переделывать заново в соответствии с полученными от эксплуатации знаниями.
Это если есть ресурсы на подобную доработку.
А если ресурсов больше нет, то от проекта отказывались.

Т.е. в любом случае этапа "разработки пробного приложения" не избежать(а возможно даже и нескольких).
А если на этом этапе можно сэкономить ресурсы, что Drupal при правильном подходе к реализации ТЗ делает практически идеально - то мягко говоря, не очень умно не воспользоваться этой возможностью Drupal.

ЗЫ.Возможно у некоторых возник вопрос, а какой мой личный интерес в том, что я "внушаю".
Все очень просто - с доработки успешного проекта зарплата разработчика больше, а трата нервов намного меньше-)

Аватар пользователя gun_dose gun_dose 30 декабря 2016 в 11:08

bsyomov wrote:

И кстати, написать несколько строк кода, бывает куда быстрее и эффективнее, особенно, если знать как это делается.

Если дело решается несколькими строками кода, то действительно, панели не нужны. Насчёт "знать, как это делается" - это не ко мне троллинг. Мне очень часто приходится писать свои плагины для панелей. Да-да, именно писать код для панелей, такое тоже бывает Smile

bsyomov wrote:

"накликай чудовище, которое будет с трудом работать"

Я не кликер, я - кодер. Костя свидетель)))

bsyomov wrote:

2. Стоимость и скорость разработки вы считаете определяющей? Стоимость эксплуатации всегда куда выше, если проект не однодневка. А ваш подход в целом, делает проект не только дорогим в эксплуатации, но и часто, ведёт к тому, что в целом в продакшен выпускается очень сырое решение. Да, это сейчас модно, но для бизнеса бывает черевато потерями денег и репутации.

Что входит в стоимость эксплуатации? Если сайт с панелями быстро и без сбоев работает на обычном шаред хостинге - куда дешевле то? Вся эксплуатация потом сводится к периодическому запуску drush up

Не раз видел, когда обходятся минимальным количеством модулей, а потом заходишь на страницу блоков, а их там 200 штук - и у каждого прописана одна страница, где его показывать. И контент-менеджер потом очень рад, что к каждой ноде или термину нужно ещё сходить и создать блок. А всё из-за того, что разраб не знал, как сделать ввод всей инфы в одной форме. Зато сайт работает быстро и дёшево. Ага, конечно.

Аватар пользователя Studio VIZA Studio VIZA 30 декабря 2016 в 12:02
1

gun_dose wrote:

заходишь на страницу блоков, а их там 200 штук

И все они - внезапно ВЫКЛЮЧЕНЫ. Взрыв мозга непосвящённому обеспечен )))

Аватар пользователя Mihail.space Mihail.space 4 января 2017 в 11:29

В backdrop cms нет панелей как таковых и нет страницы блоков.
Всё вместе в нём заменяет модуль layout /всё в нём/, который предоставляет некоторый набор макетов cо своими стилями разметки
layout page

Можно выбрать абсолютно любой макет, взять из папки модуля layout шаблон макета, удалить оттуда всю разметку и прописать свой html , добавить стили и получить желаемый результат по дизайну, выбранный layout в админке будет в конфигурации и backdrop будет в поток выдавать html из него. Но можно этого не делать и реагировать на разметку выбранного макета.

После выбора макета можно перети на страницу настройки вывода данных в макете
setting layout

blocks

s

Аватар пользователя gun_dose gun_dose 4 января 2017 в 11:39

Хаха, прикольная штука. Прямо панели во всей красе. А в этой штуке есть условия выбора, контексты, аргументы и т.д.?

Если нет, то выходит стандартная блочная модель с мордой от панелей.

Аватар пользователя Mihail.space Mihail.space 4 января 2017 в 12:11

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

Аватар пользователя Mihail.space Mihail.space 4 января 2017 в 12:49

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

Аватар пользователя VasyOK VasyOK 4 января 2017 в 22:40

Mihail.space, а в Backdrop можно работать БЕЗ этого всего?
Не специалист по панелям, но интересуюсь, а есть ли в Backdrop, что-то такое, что вырезано у панелей в Drupal 8 ?

Аватар пользователя dgastudio dgastudio 4 января 2017 в 23:43

самое интересное, 60% отписавшихся, про панели знают понаслышке., остальные на основе личного опыта... да и то как я понял кроме gun_dose, матюгаются (как и я в принципе).

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

панели, параграфы, ds, suggestions, hooks, какая разница блин.

покажите мне хоть один проект уровня aquia (100k $ + ), который вы сделали и за который вас вздрючат из за использование одной методики или другой. и где вы будете выискивать милисекунды в производительности.

приведу пример, есть чувак на d.org, охеренный спец из швейцарии, участник большинства топ модулей. у меня возник вопрос, я ему написал, ответ был: 190 евро час.. сколько займет, хз, нужно дебажить.

в итоге решил сам, по своему. возможно, и более чем возможно что не друпал way., но решил.

тут то же самое. решайте САМИ свои проблемы, к огромному сожалению на этом форуме нет премиум котрибъютеров друпала которые знаю систему от а до z, и, от которых было бы возможно получить обоснованный ответ.

не так?

поэтому, не разводите демагогию, все равно толку не будет.

Аватар пользователя gun_dose gun_dose 5 января 2017 в 9:42

Я думаю, что тут единицы могут похвастать проектами хотя бы на 100к России, не говоря уже о долларах)) Увы, я пока тоже не могу. А в целом согласен - на любую задачу есть множество решений, нужно уметь их применять. Единственное, что во всём стоит придерживаться каких-то устоявшихся практик. Хотя бывают нестандартные задачи, которые стандартно не решишь.

Аватар пользователя Studio VIZA Studio VIZA 5 января 2017 в 9:44

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

И поэтому знать... лучше чем не знать.

Как то вот так, знаете ли... .