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

Аватар пользователя gun_dose
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, которое позволяет легко выводить что угодно и как угодно при довольно простом коде. Более того, подобные задачи - одни из самых любимых на собеседовании у многих работодателей, поэтому овладеть этим кун-фу будет в любом случае полезно :)

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

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

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

Примечания

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

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

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

Модули и темы:
Тип материала:
Версия Drupal:

Комментарии

Аватар пользователя bumble
bumble 11 месяцев назад
1

На главной.

Аватар пользователя bumble
bumble 11 месяцев назад
gun_dose написал:
Пожалуй, нет ни одного другого модуля под drupal, о котором мнения разработчиков будут так же диаметрально различаться, как о Panels.

Есть:

  • Views
  • Rules
  • DS (хотя он из той же епархии)
  • все объединяющий Commerce
  • UPD - еще всяческие Context, в т.ч. Contextual links (хоть я и сам их постоянно пользую)
  • ..ещевспомнюнапишу

Да, это модули делающие Друпал - Друпалом. Но нужно понимать что их задача - UI.
Часто платой за это является снижение производительности. И при кейсах с оптимизацией - часто, они первые идут в расход.

Аватар пользователя gun_dose
gun_dose 11 месяцев назад

дс, кстати, так и ниасилил))

Аватар пользователя bumble
bumble 11 месяцев назад

Те же панели, только для нод (вьюмодов).

По сути, гуя для перетаскивания в "регионы" полей, аля как на странице блоков.

Ну и множество манящих вкусностей, типа:

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

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

А при необходимости, можно достичь многого используя просто Field Group.

Аватар пользователя gun_dose
gun_dose 11 месяцев назад

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

Аватар пользователя bumble
bumble 11 месяцев назад

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

Аватар пользователя postgres
postgres 11 месяцев назад

Плюс ко всему - Panels взаимодействуют с ctools plugins: главные из которых content type и contexts. и незаменимы для адаптации контента под разные условия запросов: например, для мобильных устройсnв можно выводить контент с облегченным наполнением в одних панелях, а для десктопов - в других, задавая правила в настройках.

Аватар пользователя VasyOK
VasyOK 11 месяцев назад
postgres написал:
для мобильных устройсnв можно выводить контент с облегченным наполнением в одних панелях, а для десктопов - в других, задавая правила в настройках.

https://www.drupal.org/project/context_breakpoint - регулярно им свожу с ума заказчиков использую на различного рода проектах. Без помощи всяких панелей.

Аватар пользователя VasyOK
VasyOK 11 месяцев назад

"4. Работа с фасетами"
Например вот сайтик с фасетами http://watches77.ru/casio (сайт просьба не судить он в вечной разработке).
Для чего тут могут понадобиться панели?

Аватар пользователя gun_dose
gun_dose 11 месяцев назад

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

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

Если не использовать поля во вьюве, а Содержимое (что рекомендуется) - быстродействие будет аналогичным

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

https://www.drupal.org/project/multiblock

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

https://www.drupal.org/project/block_visibility_vocabulary

Еще есть https://www.drupal.org/project/context

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

Это да, буржуи любят панели.

Аватар пользователя gun_dose
gun_dose 11 месяцев назад
goodboy написал:
Если не использовать поля во вьюве, а Содержимое (что рекомендуется) - быстродействие будет аналогичным

Речь идёт о выводе как раз одного единственного поля ноды. Читайте внимательнее.

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

Аватар пользователя goodboy
goodboy 11 месяцев назад

Если одно поле, разницы особой не будет. В общем случае, видимо панели будут побыстрее. Интересно бы посмотреть в цифрах.

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

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

Аватар пользователя VasyOK
VasyOK 11 месяцев назад
gun_dose написал:
Если делать магазин какого-нибудь строительного инструмента, то фасетов может быть больше сотни и тогда таскать их по странице блоков будет самой адской мукой.

Понимаю аргумент. Надо будет взять заказ на магазин инструмента и попробую :)

Хотя если проблема в том, чтобы не было муки с перестановкой фасетов - их блоки можно сводить в группы. Например этим https://www.drupal.org/project/blockgroup (хотя тоже не особо удобное решение)
https://www.drupal.org/project/block_visibility_groups - может еще это под 8-ку подойдет.

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

таки да. У панелях реально как-то монстроузный и неинтуитивный интерфейс. Мне реально легче прописать div-ы в tpl.php шаблонах темы (хотя я добровольно так никогда не делаю), чем юзать панели. Ну или я не умею их готовить.

Аватар пользователя fairrandir
fairrandir 11 месяцев назад

Ну и минусы панелей
1. Отсутствие сквозных блоков. Если задан кастомный заголовок например, то придётся пройтись по всем панелям и поменять вывод.
2. У блоков - не подхватываются классы из модуля block class, например. Да и вообще настройки блока в принципе.
3. Гибкие панели - только для прототипов. Каждая гибкая панель - это отдельный, генерируемый css файл. Ну и конская вложенность. (где-то в глубине 20-ти дивов спряталось маленькое содержимое поля.
Главный для меня плюс панелей - страницы таксономии и кастомные страницы. И юзаю как правило тупой лэйаут без обёрток, с одним регионом.
Второй плюс: мини-панели. Я ими блоки разные в три колонки вывожу, например.

На вкус и цвет фломастеры разные.

Аватар пользователя gun_dose
gun_dose 11 месяцев назад
VasyOK написал:
таки да. У панелях реально как-то монстроузный и неинтуитивный интерфейс. Мне реально легче прописать div-ы в tpl.php шаблонах темы (хотя я добровольно так никогда не делаю), чем юзать панели. Ну или я не умею их готовить.

Юзать панели для того, чтобы раскинуть контент по регионам - это действительно всё равно, что палить из пушки по воробьям. У панелей фишка в другом - надо тебе затащить дескрипшн термина вниз - взял и затащил мышью. Хочешь картинку из ноды в шапке выводить - взял и вывел. И не надо никаких вьюсов и кодинга - сокращается время на разработку. Если ничего такого не нужно, то и панели не нужны.

fairrandir написал:
1. Отсутствие сквозных блоков. Если задан кастомный заголовок например, то придётся пройтись по всем панелям и поменять вывод.

Согласен - это минус

fairrandir написал:
2. У блоков - не подхватываются классы из модуля block class, например. Да и вообще настройки блока в принципе.

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

fairrandir написал:
3. Гибкие панели - только для прототипов. Каждая гибкая панель - это отдельный, генерируемый css файл. Ну и конская вложенность. (где-то в глубине 20-ти дивов спряталось маленькое содержимое поля.

Гибкие панели не юзал. Лишние обёртки при необходимости убираю в шаблонах.

Аватар пользователя fairrandir
fairrandir 11 месяцев назад

>> В панелях можно задавать классы любым фрагментам, т.е. при использовании панелей block class вообще не нужен.
Конечно можно. Каждому фрагменту. Какой хочешь. Но это скорее следствие пункта 1 - невозможность сквозных блоков. У меня есть сайт на поддержке, около 40-ка панелей, на 30-ти есть блок, которому надо было класс прописать. Я огорчился.

Аватар пользователя VasyOK
VasyOK 11 месяцев назад
gun_dose написал:
надо тебе затащить дескрипшн термина вниз - взял и затащил мышью. Хочешь картинку из ноды в шапке выводить - взял и вывел

Ну дескрипшн термина в блок, картинка ноды в шапке - еще блок. Один блок вверх другой вниз. Стили одинаково для этих элемнтов прописывать. Что они в панелях, что нет.
"И не надо никаких вьюсов" - на вьюсах между прочим очень удобно хлебные крошки делать :)

/*Добавлено*/
Конечно - вьюсом. Им же и хлебные крошки более кастомизированней чем всеми модулями крошек.

Аватар пользователя gun_dose
gun_dose 11 месяцев назад

Чем ты засунешь дескрипшн термина в блок, если не вьюсом?

Для крошек есть path breadcrumbs

Аватар пользователя bsyomov
bsyomov 11 месяцев назад
1

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

В статье перечислено немало заблуждений.
1. Тут сложно что-то сказать, зависит от того что где и зачем...
2.Для этого есть context, копии блоков, программное получение блока и вывод его куда угодно.
3.Это прекрасно делается с без панелей. Если речь о шаблоне, можно делать даже простой темизацией.
5.Нужно просто уметь правильно делать тему, использовать фреймворки, и правильно переиспользовать код.
6. Это лучше делать своим модулем. =)

Я оптимизировал довольно немало сайтов. И избавление от панелей, зачастую, даёт ускорение в пару раз и уменьшает использование памяти до 10 раз! Без шуток. Так что подумайте 10-20-30 раз, стоит-ли в вашем случае скорость разработки значительного падения производительности. Например, для магазина время отклика может быть очень критичным, а именно в них я чаще всего эти проклятые панели и встречаю. =)

Пройдитесь профайлером по сайту с панелями, и сайту с использованием слоя темизации/кастомных модулей. Вполне возможно, вас очень сильно удивит результат, и вы не будете писать о "простом и лёгком" коде панелей.

Аватар пользователя gun_dose
gun_dose 11 месяцев назад

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

х9 х3
х6 х6
х5 х7
х4 х4 х4
х12

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

Что касатеся того, стоит ли скорость разработки падения производительности - однозначно стоит. Не всегда, но на небольших проектах точно.

Что касается магазинов, то там алгоритм ускорения совсем другой:
0. Перенастроить вьюсы с полей на отрендеренные сущности
1. Использовать поисковой индекс
2. Если Search API DB недостаточно - ставить solr
3. Переделать вывод меню каталога в статику. Очень интересный пункт, особенно в случае всяких мегаменю. Дело в том, что меню не кэшируется, т.к. на каждой странице нужно высчитывать актив трэйл по новой. Наверное, об этом будет мой следующий пост))

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

Аватар пользователя bsyomov
bsyomov 11 месяцев назад

«0. Перенастроить вьюсы с полей на отрендеренные сущности»
Ну главное не на ноды... =)
Это, кстати, далеко не всегда оптимальное решение, и при его принятии стоит тестировать производительность, и убедиться перед этим, что сервер БД нормально настроен.
1,2 При чём тут поиск вообще?,
3. Интересно будет почитать об этих граблях.

Аватар пользователя gun_dose
gun_dose 11 месяцев назад

Ээээ, правда не знаешь, зачем поисковый индекс в магазине?

Аватар пользователя bsyomov
bsyomov 11 месяцев назад

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

Аватар пользователя gun_dose
gun_dose 11 месяцев назад

Затем, что от индексации ускорение больше, чем якобы тормоза от панелей)))

Аватар пользователя bsyomov
bsyomov 11 месяцев назад

Индексации чего?
У вас есть страница с панелями, есть та же без них. Один из вариантов работает эффективнее.
Каким боком тут индексация, если это не страница результатов поиска?
Или вы каталог весь предлагаете используя поиск вместо простой выборки про категории показывать, например?
Или у вас в магазине будет только форма поиска и страница с результатами? =)
Или я вообще не понимаю ход вашей мысли. Брр.

Аватар пользователя multpix
multpix 11 месяцев назад

 search_api
На базе поискового индекса можно делать свои выборки,
простой пользователь сразу и не скажет, что это поиск, для него это каталог с фильтрами и сортировкой.
Работает в разы быстрее привычных выборок (а в случае с solr еще есть плюшки).

Панели тут не причем.

Аватар пользователя gun_dose
gun_dose 11 месяцев назад

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

ЗЫ: на самом деле ресурсы жрут не панели, а php и mysql , но вы отказ от них почему-то привели в последнюю очередь)))

Аватар пользователя bsyomov
bsyomov 11 месяцев назад

Не php и mysql, а излишние абстракции, и кривые запросы.

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

Кстати, join, и даже несколько сами по себе не так страшны, если есть нужные индексы.

Аватар пользователя voviko
voviko 11 месяцев назад
bsyomov написал:
Использование панелей в подавляющим большинстве случаев, это плата производительностью и потреблением памяти за возможность "Накликать" шаблон.

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

Аватар пользователя bsyomov
bsyomov 11 месяцев назад
1

Панели не заменяют views, и наоборот.
Панели заменяют отчасти темизацию отчасти context. А темизация на шаблонах в разы быстрее, что и не удивительно - создать структуру по заданной программе куда накладнее, чем вставить значения в готовую структуру.
По поводу кеширования - без панелей оно тоже есть, причем масса разных уровней кеширования от views до кеша страниц, и даже boost, на любой вкус. Почему бы им не пользоваться? Тот же буст будет куда эффективнее, если вы можете позволить себе кеширование. =)
Ну и всегда надо помнить о том, что кеш надо перестраивать, о чём многие забывают, а это очень важно...
Кроме того, кеш не всегда применим в принципе.

Ещё раз советую всем тем, кто возражает по поводу быстродействия произвести эксперимент с профайлером и одинаковым функционалом с панелями и без. Это быстро поставит всё на свои места. Devel + xhprof вполне просто ставятся и неплохо работают. Даже с xdeug не придётся разбираться.

Аватар пользователя kuzmich111
kuzmich111 11 месяцев назад
1

На почти голом друпале стандартные 15 блоков вывел традиционным способом и через Panels. У панелей оверхед 136%, что весьма не приятно. Хотел использовать в качестве п.5, теперь сижу думаю.

Аватар пользователя bsyomov
bsyomov 10 месяцев назад

Поздравляю. Хоть один здравомыслящий человек решил-таки проверить. =)
Это, кстати, ещё ничего - не такой и большой оверхед. Обычно всё ещё намного хуже, особенно, если начинают везде этими панелями заменять темизацию...
Там бывает и на порядок получается разница.

Аватар пользователя sergeybelya
sergeybelya 10 месяцев назад

На мой взгляд Panels один из наиболее бесполезных модулей. Для лендингов гораздо удобнее параграфы, а больше панели ни на что не годятся.

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

Специально же расписал, что к чему, а вам всё лэндинги))

Постараюсь ещё раз резюмировать в двух словах: панели - это не только таскалка квадратиков в админке, но во многих местах хорошая замена вьюсам, а также хорошее их дополнение + инструмент с мощным АПИ.

А для лэндингов лучше параграфы.

Аватар пользователя sergeybelya
sergeybelya 10 месяцев назад

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

Аватар пользователя VasyOK
VasyOK 10 месяцев назад

спасибо попробую https://www.drupal.org/project/paragraphs,
а у панелей действительно весомое преимущество, в том что они нужны многим заказчикам.

Аватар пользователя Studio VIZA
Studio VIZA 10 месяцев назад

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

Аватар пользователя Studio VIZA
Studio VIZA 10 месяцев назад
VasyOK написал:
у панелей действительно весомое преимущество.

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

VasyOK написал:
в том что они нужны многим заказчикам.

Прямо ходят и просят? я бы сказал - вспоминают с содроганием.

По моему опыту - использование панелей повышает скорость сайта, если они не криво сделаны.

Аватар пользователя VasyOK
VasyOK 10 месяцев назад

реально во многих объявлениях о работе вижу пункт panels

Аватар пользователя bsyomov
bsyomov 10 месяцев назад

Что, часто,говорит о том, что заказчикам не стоит выбирать инструменты, с помощью которых будет сделан их сайт.
Ну и следующий, после такого заказа с панелями, у заказчика другой заказ - сделайте что-нибудь, чтобы сайт хотя бы на выделенном сервере не тормозил.
Вот тут то панелям и хана. =)

Аватар пользователя sergeybelya
sergeybelya 10 месяцев назад

Объявления в основном составляют хрюшки, понахватавшись умных слов у тл-ов.

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

В объявлениях панели требуют знать только от тех, кого ищут на постоянку в нормальную контору. К слову, наблюдается интересная корелляция - больше всего панели не любят фрилансеры.

Аватар пользователя VasyOK
VasyOK 10 месяцев назад

ага хотел в одну нормальную контору устроится, так меня прям порога спросили:
"Скажи мне брат, любишь ли ты панели как люблю их я, а не наплодишь ли ты регионов в теме оформления"

Аватар пользователя sergeybelya
sergeybelya 10 месяцев назад

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

Аватар пользователя VasyOK
VasyOK 10 месяцев назад

gun_dose, можешь в теме голосование поставить? Пункты на твое усмотрение, как вариант эти.
Panels это...
1) инструмент разработки универсальных решений (использую везде)
2) инструмент разработки кастомных решений (использую редко)
3) инструмент выбивания денег из забугорых заказчиков (использую потому что платят)
4) неудобный инструмент (не использую вообще)

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

Опросы глючат. Виснет страница при голосовании.

Аватар пользователя bsyomov
bsyomov 10 месяцев назад

Забыл ещё вариант:
5) Приходится вырезать на каждом втором оптимизируемом сайте. =)

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

Ты так говоришь со знанием дела и опытом. В связи с этим интересно, какого масштаба сайты приходилось оптимизировать?

Аватар пользователя bsyomov
bsyomov 10 месяцев назад

Т.е. технические доводы кончились и начались вопросы в стиле "а ты ещё кто тут такой"?

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

2мегахита в день масштабный сайт?
Сеть сайтов раздающий видео в потоке 40Гбит масштабный проект?
Или вам интересен какой-нибудь ресурс, который у всех на слуху? Не, вот таких как-то не было, увы.

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

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

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

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

Аватар пользователя Studio VIZA
Studio VIZA 10 месяцев назад
VasyOK написал:
можешь в теме голосование поставить

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

Аватар пользователя fairrandir
fairrandir 10 месяцев назад

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

Вот это ты стопудово гонишь, что панели в три раза увеличивают потребление ресурсов.

Аватар пользователя bsyomov
bsyomov 10 месяцев назад
1

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад
1

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

Аватар пользователя bsyomov
bsyomov 10 месяцев назад
1

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

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

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

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

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

Аватар пользователя bsyomov
bsyomov 10 месяцев назад

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

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

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

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

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

Аватар пользователя multpix
multpix 10 месяцев назад

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

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

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

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

Аватар пользователя bsyomov
bsyomov 10 месяцев назад

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

Так он же как раз в итоге и грузит ноду по айдишнику через node_load. Или нет?

Аватар пользователя bumble
bumble 10 месяцев назад

Он использует загруженный wildcard'ом элемент (грузится при вызове страницы, что и есть контекст).

Аватар пользователя bumble
bumble 10 месяцев назад

ЗЫ - тут описано как работает.

Аватар пользователя bsyomov
bsyomov 10 месяцев назад

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

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

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

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

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

В рендеренном массиве страницы не будет рендеренных регионов.

Аватар пользователя negociant
negociant 10 месяцев назад
gun_dose написал:
В рендеренном массиве страницы не будет рендеренных регионов.

У нас видимо разные друпалы

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

Это у меня наверное из-за панельных тормозов)))))

Аватар пользователя bsyomov
bsyomov 10 месяцев назад

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад
1

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

Аватар пользователя Orion76
Orion76 10 месяцев назад
3

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

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

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

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

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

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

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

Аватар пользователя Studio VIZA
Studio VIZA 10 месяцев назад

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

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

Аватар пользователя bsyomov
bsyomov 10 месяцев назад

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

Аватар пользователя Orion76
Orion76 10 месяцев назад
2

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

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

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

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

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

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

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

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

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

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

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

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

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

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

Аватар пользователя bsyomov
bsyomov 10 месяцев назад
3

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

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

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

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

Аватар пользователя bumble
bumble 10 месяцев назад
4

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

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

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

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

Аватар пользователя bsyomov
bsyomov 10 месяцев назад
4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад
bsyomov написал:
И кстати, написать несколько строк кода, бывает куда быстрее и эффективнее, особенно, если знать как это делается.

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

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

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

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

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

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

Аватар пользователя bsyomov
bsyomov 10 месяцев назад

И что, спасли бы этого неумеху панели? Он бы такого наворотил, что я как раз часто и разгребаю. =)

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

Это точно. Там нужна была большущая линейка из нержавейки. Чтобы по рукам бить. ))

Аватар пользователя Studio VIZA
Studio VIZA 10 месяцев назад
1
gun_dose написал:
заходишь на страницу блоков, а их там 200 штук

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

Аватар пользователя VasyOK
VasyOK 10 месяцев назад

Формучане вопрос такой:
насколько различны возможности панелей в Drupal 8 и в Backdrop ?

Аватар пользователя Mihail.space
Mihail.space 10 месяцев назад

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

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

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

blocks

s

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

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

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

Аватар пользователя Mihail.space
Mihail.space 10 месяцев назад

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

Как таковых нет, но админка один в один. Более того, названия шаблонов как в  Radix Layouts

Аватар пользователя Mihail.space
Mihail.space 10 месяцев назад

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

Аватар пользователя VasyOK
VasyOK 10 месяцев назад

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

Аватар пользователя Mihail.space
Mihail.space 10 месяцев назад

Я не знаю, что вырезано у панелей в Drupal 8 так как пока не приходилось их использовать. Надо ставить, смотреть.

Аватар пользователя dgastudio
dgastudio 10 месяцев назад

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

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

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

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

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

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

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

не так?

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

Аватар пользователя gun_dose
gun_dose 10 месяцев назад

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

Аватар пользователя Studio VIZA
Studio VIZA 10 месяцев назад

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

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

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