Ну да, лучше, причем намного, если искать по первым буквам глазами. С группировкой будет ещё лучше, но это уже. Я в 90% случаев использую поиск через Crtl+F, но это когда знаешь название, а когда не знаешь — только вычитывать, и ровные колонки тут выигрывают у любых мясных кнопок))

Вот так? Я подумаю, куда можно вывести стилизацию списка блоков.

… возможно к каким-то JS-библиотекам и т.п.)

Короче говоря последнее, что я хочу (и могу) делать на этом этапе, это снова заниматься программированием — разбирать данные из массивов, сверяться с документацией по бекенд-технологиями (таким как PageBlocks, искать там кастомные модификаторы) — мне хватает того, что для простых преобразования в стиле (:lowercase или :ellipsis) у меня открыта документация по фильтрам вывода (в плюс к тому набору выше).

Поэтому использование в вызове чанка специализированный модификатор (:pbJson) — это прекрасно, что такая возможность в принципе есть, но пока не освоишь инструмент очень глубоко (и не забудешь через год, когда на поддержке вернешься к проекту и надо будет добавить присоединение какой-то таблицы) про это в нужный момент не вспомнишь и встрянешь — это совсем не то же самое, что в сниппет pbResources передать нужные параметры для полноценной подготовки данных для их последующей верстки и оформления. Потому что при любом раскладе, когда работаешь с данными, ты пойдешь в документацию (или код) сниппета и посмотришь возможные параметры, отвечающие за подготовку данных и раскладывание по чанкам. Так почему бы не дать возможность избавиться от программирования в чанке и как альтернативу перенести вызов этого модификатора в подхватывающиеся по шаблону (префиксу) параметры вызова сниппета — тогда вся подготовка данных будет происходить в одном месте (вызове сниппета), а всё оформление — в другом (в чанках). Аналогично тому, как например в mFilter2 можно указывать кастомные чанки row и outer для любых полей, просто добавляя их в параметры вызова прямо по именам, задаваемых в этом же вызове — это почти также красиво и понятно в коде, как твоё @Aleksandr Huz описание содержимого табов в PageBlocks))

А тот момент, что у одной задачи есть несколько вариантов решений, как раз и делает инструмент по-настоящему гибким!

Спасибо за отклик!

Ну хоть что-то, хоть это и немного не то ;)
Попробую пояснить: Когда я занимаюсь интеграцией макетов с админкой, я включаю «режим разработчика» — открываю документацию (или справку/код других проектов), хожу по шаблонам и расставляю вызовы сниппетов, где в этот момент я полностью работаю с данными — их выводом, преобразованием, разбором массивов и прочим, и раскладываю данные по чанкам. Может даже где-то пишу свои модификаторы вывода для сложных случаев. В этот момент я почти не смотрю на фронтенд, меня мало интересует верстка и стили, главное вытащить нужные данные из админки (из БД, конечно).

Далее, я иду в чанки, и там уже добавляю к данным оформление. В этот момент я «включаю режим фронтендера верстальщика»: меня в большей тепени беспокоит как выглядят данные, какие отступы, сходится ли с макетами, у меня открыта совсем другая документация (MDN, возможно SASS, дока к моему фронтенд-фреймворку, возможно к каким-то

На этом скриншоте ещё визуально хочется выровнять по левому краю надписи внутри кнопок.

Когда кнопок мало (одна, две) надписи в центре смотрятся гармонично, а когда много, ищешь глазами название, а они все начинаются на разной вертикальной оси — когнитивная нагрузка возрастает, поиск усложняется и замедляется.

@Aleksandr Huz рассмотри плиз возможность сделать выравнивание надписей!

P.S. Я такое уже встречал, когда занимался пакетом Formalicious — видимо в дизайне админки MODX никто не планировал много кнопок)) На скриншоте в той заметке тоже некрасиво, я позже исправлял…

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

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

Исправил. Проверьте мин. через 20

Что-то сломалось:

Ошибка установки
Error в /core/packages/pageblocks-1.0.5-pl/modCategory/5a3f1955c1726110b623e8d154a7e154.setupoptions.resolver:47:
Undefined class constant 'version'
Невозможно установить пакет с подписью: pageblocks-1.0.5-pl

Уже обновили — extras.modx.com/package/pageblocks?version=1.0.5-pl

В документации для 2й версии увидел что сниппеты другие (в первой просто один PageBlocks), вот и спросил)

Во второй версии нужно заменить на pbBlocks

Спасибо за оперативность! Правда парни из modx.com наверное не сразу пакет опубликуют?)

Уже отправил. Обычно это быстро.

Вау, какой красивый и короткий код! Там где описане содержимого вкладки — просто магия какая-то! Давненько такого не видел)))

Спасибо.

Из пожеланий, всё-таки не терять MODX-style и дать возможность использовать систему чанков полноценно, не прибегая в foreach циклам в коде шаблонизатора.

Вместо этого:

{foreach $list as $item}
    <li>{$item.title}</li>
{/foreach}

можно написать так, если сильно хочется:

{$list|pbJson:'<li>{$title}</li>'}

А ещё там внутри чанка можно сделать доступным {$idx} и {$total}

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

Чтобы было примерно так:

{$list|pbJson:'@INLINE <li>{$title}</li>'}
{$list|pbJson:'list_item_tpl'}

и в чанке list_item_tpl дополнительно будет доступно {$_idx}, {$_total}, {$_first} и {$_last}

просто обновляешь поверх нее — и все

В документации для 2й версии увидел что сниппеты другие (в первой просто один PageBlocks), вот и спросил)

Исправлю сегодня.

Спасибо за оперативность! Правда парни из modx.com наверное не сразу пакет опубликуют?)

Привет.

Вторая мажорная версия только платная, так? А первая (выложенная на modx.com) бесплатна?

Совершенно верно

Но при этом я вижу что у нее относительно свежий релиз.

Исправлять ошибки тоже нужно.

Я сейчас начал работу с бесплатной, если пойму, что её возможностей мало — на 2-ю версию будет трудно уйти?

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

4) у ресурса осталось старое имя чанка, всё сломалось, поменять его нельзя?

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

Привет! не до конца понял по версиям компонента! Вторая мажорная версия только платная, так? А первая (выложенная на modx.com) бесплатна? Но при этом я вижу что у нее относительно свежий релиз.
Я сейчас начал работу с бесплатной, если пойму, что её возможностей мало — на 2-ю версию будет трудно уйти?

И еще есть небольшой вопрос: 1) создал блок, указал имя чанка, 2) добавил этот блок к ресурсам, заполнил контентом, 3) переименовал чанк у блока, 4) у ресурса осталось старое имя чанка, всё сломалось, поменять его нельзя?

UPD: Рабочий вариант — сниппет для вывода списка контекстов, может кому то пригодиться

<?php
$contexts = $modx->getCollection('modContext', ['key:NOT IN' => ['mgr']]); // Исключаем админский контекст

$list = [];
foreach ($contexts as $context) {
    $contextKey = $context->get('key');

    // Получаем название контекста из самого объекта modContext (а не из modContextSetting!)
    $contextName = $context->get('name'); 

    // Получаем настройки контекста (чтобы достать site_url)
    $contextSettings = $modx->getCollection('modContextSetting', ['context_key' => $contextKey]);
    $settings = [];

    foreach ($contextSettings as $setting) {
        $settings[$setting->get('key')] = $setting->get('value');
    }

    // Получаем URL (если не задан - пропускаем контекст)
    $siteUrl = isset($settings['site_url']) ? $settings['site_url'] : '';
    if (empty($siteUrl) || empty($contextName)) {
        continue;
    }

    $list[] = ['name' => $contextName, 'url' => $siteUrl];
}

// Сортируем список по названию
usort($list, function ($a, $b) {
    return strcmp($a['name'], $b['name']);
});

// Получаем текущий контекст
$currentContextKey = $modx->context->get('key');
$currentContext = $modx->getObject('modContext', ['key' => $currentContextKey]);

// Получаем его название (из поля "Название" в админке)
$currentContextName = $currentContext ? $currentContext->get('name') : $currentContextKey;

// Получаем site_url текущего контекста
$currentSettings = $modx->getCollection('modContextSetting', ['context_key' => $currentContextKey]);
$currentSiteUrl = '';

foreach ($currentSettings as $setting) {
    if ($setting->get('key') === 'site_url') {
        $currentSiteUrl = $setting->get('value');
        break;
    }
}

// Вывод HTML
$output = 'Текущий город - <strong>' . htmlspecialchars($currentContextName) . '</strong>';
$output .= '<select onchange="window.location=this.value">';
$output .= '<option value="">Выберите город...</option>';

foreach ($list as $item) {
    $selected = ($item['url'] == $currentSiteUrl) ? ' selected' : '';
    $output .= '<option value="' . htmlspecialchars($item['url']) . '"' . $selected . '>' . htmlspecialchars($item['name']) . '</option>';
}

$output .= '</select>';

return $output;

Вау, какой красивый и короткий код! Там где описане содержимого вкладки — просто магия какая-то! Давненько такого не видел))) Спасибо!

Из пожеланий, всё-таки не терять MODX-style и дать возможность использовать систему чанков полноценно, не прибегая в foreach циклам в коде шаблонизатора.

Думаю это выглядело бы примерно так:

{'!pbResources'|snippet: [
    ...
    'tables' => 'seo_list as list' // Присоединяем таблицу seo_list и заменяем имя на list
    'tpl_list' => 'list-data-item' // С префиксом tpl_ используется alias присоединенной выше таблицы. Если параметр не указан, list будет доступен как массив.
    'tpl' => 'pb-seo-card', // Чанк вывода
]}

Зачем это нужно?

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

А ещё там внутри чанка можно сделать доступным {$idx} и {$total} (его, возможно, и снаружи, с префиксом типа list_total или как-то так) чтобы не городить их опять же в коде чанка, который для разметк (aka верстки) предназначен, а не для логики.

Это конечно не правка бизнес-логики компонента, а больше к Developer Expierence, но вроде всё так красиво реализовано для разработчиков (уже), что такая вишенка на торт возможно придется кому-то (вроде меня :) ) очень кстати!

спасибо, воспользовался вторым вариантом

Мы ценим и уважаем Ваш труд! Спасибо!
Классно, теперь могу поставить клиентам. Мне больше нравится темная тема, но клиентам некоторым привычнее работать в светлой. Удобно что можно будет переключаться. Простая вещь, а как удобно.

Спасибо большое! На первом же сайте нашла подходящий для нас вариант.