Вы сейчас прям описываете работу компонента MagicThemes.
Где весь описываемый функционал есть и в удобном варианте.
Чуть по другому работает, но суть такая же.

В качестве эксперимента поменял конфиг комбобокса, который подтягивает данные с процессора, на локальный:

CalcPackage.combo.TemplatePage = function (config) {
    config = config || {};
    Ext.applyIf(config, {
        store: new Ext.data.ArrayStore({
            id: 0
            ,fields: ['unit','display']
            ,typeAhead: true
            ,typeAheadDelay: 2000
            ,preventRender: true
            ,triggerConfig: {
                tag: 'span',
                cn: [
                    {
                        tag: 'div',
                        cls: 'x-form-trigger',
                        trigger: ''
                    },
                ]
            }
            ,data: [
                ['1','listovki']
                ,['2','vizitki']
            ]
        })
        ,mode: 'local'
        ,displayField: 'display'
        ,hiddenName: 'display'
        ,valueField: 'unit'
    });
    CalcPackage.combo.TemplatePage.superclass.constructor.call(this, config);
};
Ext.extend(CalcPackage.combo.TemplatePage, CalcPackage.combo.ComboBox);
Ext.reg('calcpackage-combo-template-page', CalcPackage.combo.TemplatePage);

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

Общие выводы:
в таблице БД, которую выводит грид, значение поля (на которое установлен комбобокс) хранится в цифровом виде. При загрузке страницы процессор дергает значение поля, затем комбобокс — для данного примера — обрабатывает ЛОКАЛЬНО это значение, подсовывая строку из массива — skrinshoter.ru/s/150522/fUKjGSB6.

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

В итоге, так и непонятно, что делать в этом случае. Не будешь ведь добавлять js-костыль, который после полной загрузки страницы будет генерировать событие click по этой кнопке skrinshoter.ru/s/150522/s76QqLsq

Спасибо за ответы. Все получилось )

В шаблоне нужной страницы должен быть вызов сниппета

[[getImageList? &tpl=`fancybox`&docid=`1`&tvname=`fancyboxTv`&toSeparatePlaceholders=`img`]]

с параметром &docid=`1`, где 1 — id главной страницы. <cut/>

ЗЫ. Упс — опоздал с советом))

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

Ура получилось) вопрос решен)

Может быть как-то в вывоз надо указать что хотим показывать картинки с id =1?

[[getImageList? &docid=`1` &tpl=`fancybox`&tvname=`fancyboxTv`&toSeparatePlaceholders=`img`]]

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

<?php
$fqn = $modx->getOption('pdoFetch.class', null, 'pdotools.pdofetch', true);
$path = $modx->getOption('pdofetch_class_path', null, MODX_CORE_PATH . 'components/pdotools/model/', true);
if ($pdoClass = $modx->loadClass($fqn, $path, false, true)) {
    $pdoFetch = new $pdoClass($modx, $scriptProperties);
} else {
    return false;
}


$blockList = $modx->resource->getTVValue("blockList");
$blockList = json_decode($blockList ,true);

$html = "";
foreach ($blockList as $key => $block){
    if (empty($block['chunkName']) or $block['isActive'] != 'Да')
        continue;

    $chunk = '@FILE blocks/'.$block['chunkName'];

    $html .= $pdoFetch->getChunk($chunk, $block);
}

return $html;

примерно так.

Почти как у меня))) И я пожалуй спионерю у тебя пару идей))) Добавлю скриншоты и сделаю заготовки для шаблонов. У тебя твой сниппет который всё это разбирает не тормозит загрузку страницы? В моем варианте происходит прегенерация кода шаблона он сохраняется в файл и потом парсится как обычный шаблон, это здорово, некоторые страницы получаются статичными, но вот обновлять их может оказаться ресурсозатратно. Можешь показать код сниппета?

Опишу вкратце, как организовывал подобный функционал я, может кому то будет интересно.
Кода не будет, будут только общие концепции.
1) Есть конфигурация migx которая содержит
— название блока. Это для того чтобы менеджеру было сразу понятно, о чем этот блок. Никакой другой цели не несет.
— скриншот. Хранит скриншот того, как этот блок выглядит на странице. Тоже чтобы менеджеру было удобно.
— заголовок блока. Это текст, который может быть в блоке а может и нет. Например на одной странице нам нужно вывести иконки и написать вверху над ними — наши преимущества. А где то нужно обойтись только иконками.
— чекбокс Активен блок или нет.
— название чанка, хранящего верстку блока.
— описание. Для удобства менеджера, если управление блоком не очевидно и требует каких то комментариев.
— откуда брать данные для блока. Выпадающий список с такими вариантами. — брать с текущей страницы — брать с общих настроек. Детальнее что это опишу ниже.
2) На основании этой конфигурации создаем ТВ поле блок. Привязываем к нужным нам шаблонам.
3) Для удобства менеджера облегчим ему жизнь. Создадим несколько служебных ресурсов. Назовем их
— общие настройки
— категория товара
-товар
— инфостраница
Называем примерно так, чтобы была визуальна видна связь с шаблонам. Зачем нужны эти ресурсы. Они будут являться образцами. К примеру мы идем в служебный ресурс Товар и создаем там блоки (имеются ввиду ТВ поля типа migx).
Настраиваем их, располагаем в нужном нам порядке, так как хотим чтобы выглядела страница товара.
4) При создании любого ресурса срабатывает наш плагин (важно. именно при создании нового а не при обновлении) который понимает какой именно ресурс хотят создать (анализируя шаблон или анализируя родителя, внутри которого его хотят создать). К примеру плагин понял что хотят создать товар. Он идет в служебный ресурс товар и копирует оттуда все блоки, которые заранее настроил менеджер. Если плагину не удалось точно понять, какой ресурс хотят создать, он скопирует блоки с служебного ресурса — общие настройки.
5) мы сохранили новый ресурс и он уже заполнен блоками в нужном нам порядке. Но если менеджер хочет что то изменить, он может редактировать блоки уже принадлежащие этому ресурсу. Сделать эту страницу чем то отличающуюся от стандартного шаблона.
6) как это все работает и почему блоки отображаются на странице. А шаблонах не содержится верстки, кроме основного скелета html. На странице вызывается самописный сниппет buildpage задача которого получить значение migx tv с блоками на этой странице, получить инфу активен ли блок (нужно ли его вообще отображать на странице) и если активен — вызвать нужный чанк (имя которого тоже лежит в блоке). Очередность блоков задается менеджером путем перетаскивания строк в админке.
7) последнее время чанки, которые формируют внешний вид блока начал делать по типу компонентов vue. Имеется ввиду лишь идея, в чанке прописан как блок со стилями, так и html так и javascript относящийся к блоку. Соответственно если блок не активен, то нет и лишних стилей и скриптов.
8) осталось рассказать только об одном — о данных. Сами блоки — это лишь внешний вид, им нужно откуда то брать данные, причем эти данные могут быть разными для блока, в зависимости от того на какой странице он вызван. Данные для блоков храню так же в migx tv полях. Возьму для примера тот же блок — наши преимущества (не знаю как у вас но наши сеошники аж трясутся над этим блоком и пихают его чуть ли не по 10 штук на страницу). Так вот. Создаю конфигурацию migx задача которой хранить изображения. Создаю ТВ поле — блок наши преимущества, которые построен на этой конфигурации. Это ТВ поле есть как у служебных ресурсов, так и у реальных ресурсов, создаваемых менеджером. Настройка в блоке, с именем «Откуда брать данные» как раз и отвечает за это. Менеджер может заполнить один раз данные для блока преимущества (загрузить иконки, возможно написать текст) в служебном ресурсе Общие настройки. Активируя блок «наши преимущества» на любой странице сайта менеджер просто выбирает — брать данные из общих настроек. Если нужно для этой страницы задать индивидуальные данные, то нужно всего лишь перезаполнить соответствующее ТВ поле уже этого ресурса и выставить у блока — «брать данные с этой страницы».
В общем то и все.

@nikolrazumov @Avex

Проверяйте хостинг — не воспроизводится!

Создал 2 ТВ поля с типом изображение, привязал к шаблону и вывел в шаблоне.
Загрузил 2-е картинки для каждой страницы в jpg/png и никаких проблем не наблюдается.

Больше скажу — ни одного кроме ваших сообщений об ошибке не видел в сообществе и в репозитории.

Пруф: disk.yandex.ru/d/6nw6QBBC7UPqfw

Ок, спасибо.

Конечно.

Либо через mod_proxy, либо через mod_rewrite.

Значит Nuxt может работать и с Апачем?

а вот еще хотелось бы мне подискутировать на затронутую мной же тему jwt токенов.
Кто скажет, почему payload не шифруется а лишь кодируется? В чем сокральный смысл использовать base64, который очень просто раскодировать и узнать данные?
Как я понимаю жизненный цикл access токена:
— сервер авторизации и сервер, на котором мы хотим обратиться знают один и тот же ключ, при помощи которого создана сигнатура в токене.
— мы при каждом запросе мы передаем этот токен на сервер. Сервер (в каком то midleware ну или как там разработчик сделает) берет payload и кодирует тем же ключем. И сравнивает сигнатуру которую он получил с той, что пришла в токене.
— если сигнатуры совпали это говорит о том, что запрос пришел от того, кто обращался на наш сервис авторизации и смог получить токен.
— НО мы ничего еще не знаем о самом клиенте. Кто именно делает запрос. А если у нас есть деление на какие то роли и не каждый кто просто получил токен имеет пользоваться всем. Или же мы ведем логирование запросов и нам нужен хотя бы id пользователя. Тоесть как ни крути, там же на этапе аутентификации нужно раскодировать payload и получить исходные данные, чтобы получить например объект с перечислением ролей и определить, допустима ли тому, кто отправил запрос, операция удаления пользователей.
— тоесть сам факт проверки сигнатуры не дает еще полной картины, раскодировать payload прийдется каждый раз.
— и в такой схеме действительно возникает проблема. Если токен украли, то пока он «жив» вор может пользоваться им и нанести вред.

Теперь собственно моя идея.
— раз нам все равно на каждый запрос нужно раскодировать payload токена, то почему не включить в него информацию, которая позволит решить проблему с угоном токена. Что-то что будет служить дополнительной защитой.
— к примеру ip адрес того, кто обратился на сервер авторизации и получил токен. Добавим ip в payload и на этапе аутентификации на своем сервере, сравниваем, а тот ip что пришел в токене и реальный ip который мы получаем из самого запроса — совпадают ли?
— так же в случае если мы говорим про применение jwt не для общения с api, а для использования в браузере, в токен можно добавить user-agent, который даст информацию о том, с какой операционной системы и с какого браузера был получен токен. И есть еще масса уникальной информации, которую можно получить и использовать для идентификации того или иного устройства.
— что это нам дает. Решение классической проблемы — угнали токен и до конца его жизни могут пользоваться. Теперь даже в случае угона токена, он не будет принят на сервере, на который мы стучимся, потому что точно не пройдет проверку ip и скорее всего не пройдет проверку user-agent.
— нельзя конечно полностью утверждать, что это 100 процентная защита от угона токена, вернее от возможности его использование вором, но это уже сильно усложнит жизнь вору. Насколько я знаю, подделать ip с которого отправляешь свой запрос на какой то конкретный (а чтобы токен прошел валидацию нужен именно конкретный), не так уж и просто. Но предположим что супер хакеры умеют.
— и мы возвращаемся к моему вопросу — почему payload просто кодируют, а не шифруют? Тот кто украл токен имеет прямой доступ к информации, пусть даже и не знает ключа шифрования, при помощи которого была создана сигнатура. В моей схеме, вор получив токен сразу же использует его чтобы получить доступ к нашему сервису. Не выходит, банально потому что его ip не совпадает с тем с которого он совершает запрос.
— если payload только закодирован base64 вор получает с него данные и видит, что в данных содержится и ip. И начинает как то решать эту проблему и искать способ подделать свой ip на этот конкретный. Если время жизни токена невелико то и времени для поиска решения не много. Но ведь можно не дать ему и этого шанса. Не будем кодировать, будем шифровать payload. Мы уже используем один ключ, который создает сигнатуру. Можем использовать его или завести еще один. Чистые данные шифруем при помощи ключа. получаем payload. payload шифруем при помощи ключа — получаем сигнатуру. Складываем их вместе, получаем довольно безопасный токен.
— теперь даже если украсть токен, то «тупое» его использование ничего не даст и дело не во времени его жизни, а в несовпадении данных из токена с реальными данными запроса. И посмотреть что лежит в payload хакер тоже не может, данные не закодированы, а зашифрованы и не имея ключа их не расшифровать.

Такой подход, как мне кажется, даже позволит завести в свой системе авторизации пару приятных плюшек:
— автопродление токена. Поскольку у нас теперь токен содержит дополнительные уровни защиты, то в зависимости от уровня безопасности всего проекта, можно облегчить жизнь нашим пользователем. Если токен пришел на сервер и в нем все идеально, кроме времени жизни (он уже протух), можно не отправлять пользователя на повторную авторизацию руками, а самим сделать запрос на наш сервис авторизации, передать туда данные из payload и получить новый токен. Никто ведь из людей не любит очень часто вводить пароль. Но это для проектов, чей уровень безопасности не высок.
— можно вести статистику успешных и неуспешных использований токена и на основании ее изменять время жизни токена для конкретного пользователя. Если видим, что присылается токен с зашитым внутрь одним ip а запрос приходит с другого ip, то в следующий раз этому клиенты выдадим токен не на 30 минут, а на 5 минут.

спасибо, я понял.

Так можно сделать только если на сервере всего один сайт, который займёт 80 порт.

А если сайтов 2 или более — то нужен Nginx или Apache2, которые будут разруливать запросы.

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

Можно через консоль или через логи =).

$_modx->log(1, print_r([2,3,4,5], 1));

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