Пожалуй, нет ни одного другого модуля под 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, которое позволяет легко выводить что угодно и как угодно при довольно простом коде. Более того, подобные задачи - одни из самых любимых на собеседовании у многих работодателей, поэтому овладеть этим кун-фу будет в любом случае полезно 
Когда не нужно использовать Panels
1. Когда у вас на сайте всего три одинаковые страницы и полтора блока.
2. Когда вы не поняли ничего из того, что было написано выше
Примечания
1. Чтобы не сломать головной мозг, при использовании панелей лично я рекомендую использовать в теме всего один регион, в котором будет всего один блок. В крайнем случае можно вывести ещё хэдер и футер, но в этом далеко не всегда есть необходимость.
2. Всё вышесказанное относится к Drupal 7, в восьмой версии функционал панелей сильно урезан, а функционал блоков наоборот - расширен.
И традиционная спам-ссылка на оригинал статьи в моём говноблоге: http://wellsolutions.by/article/panels-ispolzovat-ili-net
Комментарии
На главной.
Есть:
Да, это модули делающие Друпал - Друпалом. Но нужно понимать что их задача - UI.
Часто платой за это является снижение производительности. И при кейсах с оптимизацией - часто, они первые идут в расход.
дс, кстати, так и ниасилил))
Те же панели, только для нод (вьюмодов).
По сути, гуя для перетаскивания в "регионы" полей, аля как на странице блоков.
Ну и множество манящих вкусностей, типа:
По сути - все круто, я использовал долго. Но когда есть возможность это дело программно пилить - конечно же будет производительнее.
А при необходимости, можно достичь многого используя просто Field Group.
хз, я как-то влез в дс и мне там не понравилось, что в препроцессе уже отрендеренный хтмл, не стал копаться дальше, снёс его и был таков. А по филд груп недостаток в том, что он не поддерживает кастомные шаблоны. Ну и с панелями не интегрирован. Хотя я написал свой цтулс плагин для отображения филдгруп в панелях и теперь не парюсь по этому поводу)
Любой "шаблон" - это верстка со стилями.
Оборачивай все что нужно в группы, назначай им классы (если не хватит созданных), пиши им стили. Вот и панель, только самописная ))) Да, не из гуи, но в чем то есть и прелести такого подхода (во всяком случае, для маньяков вроде меня, пытающихся держать все максимально под контролем)) ).
Плюс ко всему - Panels взаимодействуют с ctools plugins: главные из которых content type и contexts. и незаменимы для адаптации контента под разные условия запросов: например, для мобильных устройсnв можно выводить контент с облегченным наполнением в одних панелях, а для десктопов - в других, задавая правила в настройках.
https://www.drupal.org/project/context_breakpoint - регулярно
им свожу с ума заказчиковиспользую на различного рода проектах. Без помощи всяких панелей."4. Работа с фасетами"
Например вот сайтик с фасетами http://watches77.ru/casio (сайт просьба не судить он в вечной разработке).
Для чего тут могут понадобиться панели?
В панелях тупо удобнее таскать фасеты мышкой, чем на странице блоков. На сайте с часами вряд ли будет ощутимо. Если делать магазин какого-нибудь строительного инструмента, то фасетов может быть больше сотни и тогда таскать их по странице блоков будет самой адской мукой.
Если не использовать поля во вьюве, а Содержимое (что рекомендуется) - быстродействие будет аналогичным
https://www.drupal.org/project/multiblock
https://www.drupal.org/project/block_visibility_vocabulary
Еще есть https://www.drupal.org/project/context
Это да, буржуи любят панели.
Речь идёт о выводе как раз одного единственного поля ноды. Читайте внимательнее.
Итого, вы предлагаете поставить несколько модулей, чтобы только не юзать панели?)))
Если одно поле, разницы особой не будет. В общем случае, видимо панели будут побыстрее. Интересно бы посмотреть в цифрах.
Да, поставить несколько мелких модулей вместо больших панелей. Если посмотреть на это дело с другой стороны - вы предлагаете поставить панели из-за того, что не увидели возможности отфильтровать блок по словарям таксономии, например.
Я против панелей ничего не имею, просто написал, что задачу можно решить разными способами. Чем и хорош Друпал.
Понимаю аргумент. Надо будет взять заказ на магазин инструмента и попробую
Хотя если проблема в том, чтобы не было муки с перестановкой фасетов - их блоки можно сводить в группы. Например этим https://www.drupal.org/project/blockgroup (хотя тоже не особо удобное решение)
https://www.drupal.org/project/block_visibility_groups - может еще это под 8-ку подойдет.
таки да. У панелях реально как-то монстроузный и неинтуитивный интерфейс. Мне реально легче прописать div-ы в tpl.php шаблонах темы (хотя я добровольно так никогда не делаю), чем юзать панели. Ну или я не умею их готовить.
Ну и минусы панелей
1. Отсутствие сквозных блоков. Если задан кастомный заголовок например, то придётся пройтись по всем панелям и поменять вывод.
2. У блоков - не подхватываются классы из модуля block class, например. Да и вообще настройки блока в принципе.
3. Гибкие панели - только для прототипов. Каждая гибкая панель - это отдельный, генерируемый css файл. Ну и конская вложенность. (где-то в глубине 20-ти дивов спряталось маленькое содержимое поля.
Главный для меня плюс панелей - страницы таксономии и кастомные страницы. И юзаю как правило тупой лэйаут без обёрток, с одним регионом.
Второй плюс: мини-панели. Я ими блоки разные в три колонки вывожу, например.
На вкус и цвет фломастеры разные.
Юзать панели для того, чтобы раскинуть контент по регионам - это действительно всё равно, что палить из пушки по воробьям. У панелей фишка в другом - надо тебе затащить дескрипшн термина вниз - взял и затащил мышью. Хочешь картинку из ноды в шапке выводить - взял и вывел. И не надо никаких вьюсов и кодинга - сокращается время на разработку. Если ничего такого не нужно, то и панели не нужны.
Согласен - это минус
В панелях можно задавать классы любым фрагментам, т.е. при использовании панелей block class вообще не нужен.
Гибкие панели не юзал. Лишние обёртки при необходимости убираю в шаблонах.
>> В панелях можно задавать классы любым фрагментам, т.е. при использовании панелей block class вообще не нужен.
Конечно можно. Каждому фрагменту. Какой хочешь. Но это скорее следствие пункта 1 - невозможность сквозных блоков. У меня есть сайт на поддержке, около 40-ка панелей, на 30-ти есть блок, которому надо было класс прописать. Я огорчился.
Ну дескрипшн термина в блок, картинка ноды в шапке - еще блок. Один блок вверх другой вниз. Стили одинаково для этих элемнтов прописывать. Что они в панелях, что нет.
"И не надо никаких вьюсов" - на вьюсах между прочим очень удобно хлебные крошки делать
/*Добавлено*/
Конечно - вьюсом. Им же и хлебные крошки более кастомизированней чем всеми модулями крошек.
Чем ты засунешь дескрипшн термина в блок, если не вьюсом?
Для крошек есть path breadcrumbs
Использование панелей в подавляющим большинстве случаев, это плата производительностью и потреблением памяти за возможность "Накликать" шаблон.
В статье перечислено немало заблуждений.
1. Тут сложно что-то сказать, зависит от того что где и зачем...
2.Для этого есть context, копии блоков, программное получение блока и вывод его куда угодно.
3.Это прекрасно делается с без панелей. Если речь о шаблоне, можно делать даже простой темизацией.
5.Нужно просто уметь правильно делать тему, использовать фреймворки, и правильно переиспользовать код.
6. Это лучше делать своим модулем.
Я оптимизировал довольно немало сайтов. И избавление от панелей, зачастую, даёт ускорение в пару раз и уменьшает использование памяти до 10 раз! Без шуток. Так что подумайте 10-20-30 раз, стоит-ли в вашем случае скорость разработки значительного падения производительности. Например, для магазина время отклика может быть очень критичным, а именно в них я чаще всего эти проклятые панели и встречаю.
Пройдитесь профайлером по сайту с панелями, и сайту с использованием слоя темизации/кастомных модулей. Вполне возможно, вас очень сильно удивит результат, и вы не будете писать о "простом и лёгком" коде панелей.
1. Сложно сказать, потому что панели выводят отдельные поля значительно быстрее вьюсов.
2. Контекст не менее монструозен, чем панели. Программное получение блоков хорошо для шапки и подвала, а программный вывод блоков в контентную часть ведёт к необходимости пожизненного технического сопровождения сайта.
3, 5. Простая темизация - это просто отлично, всегда при возможности обхожусь только ей, но когда шаблон имеет вид:
х6 х6
х5 х7
х4 х4 х4
х12
а другие страницы имеют другие не менее замысловатые конфигурации, то без панелей будет туговато. Более того, лично мне кажется куда более удобным зайти в шаблон сущности и настроить его вид от и до, чем вылавливать каждый блок по одному и выставлять ему правила видимости.
Что касатеся того, стоит ли скорость разработки падения производительности - однозначно стоит. Не всегда, но на небольших проектах точно.
Что касается магазинов, то там алгоритм ускорения совсем другой:
0. Перенастроить вьюсы с полей на отрендеренные сущности
1. Использовать поисковой индекс
2. Если Search API DB недостаточно - ставить solr
3. Переделать вывод меню каталога в статику. Очень интересный пункт, особенно в случае всяких мегаменю. Дело в том, что меню не кэшируется, т.к. на каждой странице нужно высчитывать актив трэйл по новой. Наверное, об этом будет мой следующий пост))
ЗЫ: создаётся впечатление, что все думают, что я пытаюсь навязать всем использование панелей. А я всего лишь хотел показать, что в панелях есть множество других полезных функций, кроме растаскивания блоков по регионам.
«0. Перенастроить вьюсы с полей на отрендеренные сущности»
Ну главное не на ноды...
Это, кстати, далеко не всегда оптимальное решение, и при его принятии стоит тестировать производительность, и убедиться перед этим, что сервер БД нормально настроен.
1,2 При чём тут поиск вообще?,
3. Интересно будет почитать об этих граблях.
Ээээ, правда не знаешь, зачем поисковый индекс в магазине?
Я не понимаю, зачем он всплыл в контексте обсуждения панелей.
Затем, что от индексации ускорение больше, чем якобы тормоза от панелей)))
Индексации чего?
У вас есть страница с панелями, есть та же без них. Один из вариантов работает эффективнее.
Каким боком тут индексация, если это не страница результатов поиска?
Или вы каталог весь предлагаете используя поиск вместо простой выборки про категории показывать, например?
Или у вас в магазине будет только форма поиска и страница с результатами?
Или я вообще не понимаю ход вашей мысли. Брр.
search_api
На базе поискового индекса можно делать свои выборки,
простой пользователь сразу и не скажет, что это поиск, для него это каталог с фильтрами и сортировкой.
Работает в разы быстрее привычных выборок (а в случае с solr еще есть плюшки).
Панели тут не причем.
Мультпикс дело говорит. Поисковый индекс не только для поиска, на него можно вьюс натравить, и выборка будет идти быстрее из-за почти полного отсутствия джоинов. Хотя действительно, мы ушли от панелей в сторону оптимизации.
ЗЫ: на самом деле ресурсы жрут не панели, а php и mysql , но вы отказ от них почему-то привели в последнюю очередь)))
Не php и mysql, а излишние абстракции, и кривые запросы.
По поводу поискового индекса - если это внешний solr, если существует много фильтров и.т.п., да, это может быть оптимизацией. Но это не самый частый кейс.
При схеме категории-товары, без 100500 важных для фильтрации полей в товаре, реализация на таксономии и views тоже будет быстрой. Если не испортить её парой тройкой слоёв лишних абстракций, конечно...
И таких магазинов, на самом деле, куда больше. Мало того, сложные фильтры часто просто не уместны, и больше пользователей отвлекают от покупок, чем помогают что-то купить.
Кстати, join, и даже несколько сами по себе не так страшны, если есть нужные индексы.
Не люблю панели, но по производительно, много раз замечал, что панели намного быстрее из за кеша.
также переделывал с панелей на views и не всегда это было правильно.
Сейчас придется собирать на панелях сайт, из-за дизайна мобильного.
Панели не заменяют views, и наоборот.
Панели заменяют отчасти темизацию отчасти context. А темизация на шаблонах в разы быстрее, что и не удивительно - создать структуру по заданной программе куда накладнее, чем вставить значения в готовую структуру.
По поводу кеширования - без панелей оно тоже есть, причем масса разных уровней кеширования от views до кеша страниц, и даже boost, на любой вкус. Почему бы им не пользоваться? Тот же буст будет куда эффективнее, если вы можете позволить себе кеширование.
Ну и всегда надо помнить о том, что кеш надо перестраивать, о чём многие забывают, а это очень важно...
Кроме того, кеш не всегда применим в принципе.
Ещё раз советую всем тем, кто возражает по поводу быстродействия произвести эксперимент с профайлером и одинаковым функционалом с панелями и без. Это быстро поставит всё на свои места. Devel + xhprof вполне просто ставятся и неплохо работают. Даже с xdeug не придётся разбираться.
На почти голом друпале стандартные 15 блоков вывел традиционным способом и через Panels. У панелей оверхед 136%, что весьма не приятно. Хотел использовать в качестве п.5, теперь сижу думаю.
Поздравляю. Хоть один здравомыслящий человек решил-таки проверить.
Это, кстати, ещё ничего - не такой и большой оверхед. Обычно всё ещё намного хуже, особенно, если начинают везде этими панелями заменять темизацию...
Там бывает и на порядок получается разница.
На мой взгляд Panels один из наиболее бесполезных модулей. Для лендингов гораздо удобнее параграфы, а больше панели ни на что не годятся.
Специально же расписал, что к чему, а вам всё лэндинги))
Постараюсь ещё раз резюмировать в двух словах: панели - это не только таскалка квадратиков в админке, но во многих местах хорошая замена вьюсам, а также хорошее их дополнение + инструмент с мощным АПИ.
А для лэндингов лучше параграфы.
Выше справедливо отметили про громоздкость и тормоза панелей, честно не вижу никаких преимуществ. Согласен и с комментарием о неудобстве администрирования, очень сложный и непонятный интуитивно интерфейс.
спасибо попробую https://www.drupal.org/project/paragraphs,
а у панелей действительно весомое преимущество, в том что они нужны многим заказчикам.
В чём плюс панелей, отчаявшиеся контент-менеджеры шлют деньги на сбер, безо всякого уведомления, им важно нас не потерять. Буду пилить доки со скринами, чо уж.
Человек как хочет, нажал - изменил, а в случае панелей, она часто показывает вьюху, которая показывает тип материала, в доме который построил Джек. Снос крыши обеспечен.
Прямо ходят и просят? я бы сказал - вспоминают с содроганием.
По моему опыту - использование панелей повышает скорость сайта, если они не криво сделаны.
реально во многих объявлениях о работе вижу пункт panels
Что, часто,говорит о том, что заказчикам не стоит выбирать инструменты, с помощью которых будет сделан их сайт.
Ну и следующий, после такого заказа с панелями, у заказчика другой заказ - сделайте что-нибудь, чтобы сайт хотя бы на выделенном сервере не тормозил.
Вот тут то панелям и хана.
Объявления в основном составляют хрюшки, понахватавшись умных слов у тл-ов.
В объявлениях панели требуют знать только от тех, кого ищут на постоянку в нормальную контору. К слову, наблюдается интересная корелляция - больше всего панели не любят фрилансеры.
ага хотел в одну нормальную контору устроится, так меня прям порога спросили:
"Скажи мне брат, любишь ли ты панели как люблю их я, а не наплодишь ли ты регионов в теме оформления"
Не знаю, за два года в работы в одной из таких нормальных контор с панелями пришлось работать лишь однажды, причем в восьмерке и то с panelizer. Как-то больше не возникала необходимость в их использовании.
gun_dose, можешь в теме голосование поставить? Пункты на твое усмотрение, как вариант эти.
Panels это...
1) инструмент разработки универсальных решений (использую везде)
2) инструмент разработки кастомных решений (использую редко)
3) инструмент выбивания денег из забугорых заказчиков (использую потому что платят)
4) неудобный инструмент (не использую вообще)
Опросы глючат. Виснет страница при голосовании.
Забыл ещё вариант:
5) Приходится вырезать на каждом втором оптимизируемом сайте.
Ты так говоришь со знанием дела и опытом. В связи с этим интересно, какого масштаба сайты приходилось оптимизировать?
Т.е. технические доводы кончились и начались вопросы в стиле "а ты ещё кто тут такой"?
Вопрос изначально провакационный и не корректный - хотя бы потому, что в нем не конкретизировано понятие масштаба сайта.
2мегахита в день масштабный сайт?
Сеть сайтов раздающий видео в потоке 40Гбит масштабный проект?
Или вам интересен какой-нибудь ресурс, который у всех на слуху? Не, вот таких как-то не было, увы.