Лёш, чес слово, я найду время потестить твой доп, щас проект доделаю и найду)))

Ты так и не сказал, если блоков много время ответа сервера не страдает?

Пробовал так
switch ($modx->event->name) {
case 'OnWebPageComplete':
//Получаем доступ к готовому DOM дереву
$output = $modx->resource->getContent();
$modx->log(1, output );
break;
}

Но получаю не полностью сам контент страницы, а часть покрайней мере так в консоли, видел в консоле 1 вызов [[++settings_version]]

То есть какой-то сжатый кусок, сама страница дефолтная от установки modx'a, но получаю сжатый такой кусок в таком виде. Сохранил вывод с

$modx->resource->getContent();

в файл.

<p>You have successfully installed MODX Revolution [[++settings_version]]!</p>
<p>Now that MODX is installed you can login to the manager to create your templates, manage content and install third party extras to add functionality to your website.</p>
<h2>New to MODX?</h2>
<p>Pages on a MODX site are called <a href="https://docs.modx.com/current/en/building-sites/resources">Resources</a>, and are visible on the left-hand side of the manager in the Resources tab. Resources can be nested under other resources, making it easy to create a tree of resources. There are different types of resources for different use cases.</p>
<p>Building your website is done through a combination of <strong>Templates</strong>, <strong>Template Variables</strong>, <strong>Chunks</strong>, <strong>Snippets</strong> and <strong>Plugins</strong>. Collectively these are known as <strong>Elements</strong>, and can also be found in the left-hand side of the manager, in the Elements tab.</p>
<p><a href="https://docs.modx.com/current/en/building-sites/elements/templates">Templates</a> contain the outer markup of any page. Each resource can only be assigned to a single template at a time. By adding <a href="https://docs.modx.com/current/en/building-sites/elements/template-variables">Template Variables</a> to a template, you can add custom fields for any resource using that particular template.</p>
<p>With <a href="https://docs.modx.com/current/en/building-sites/elements/chunks">Chunks</a> you can share parts of the markup, such as a header, across different templates. <a href="https://docs.modx.com/current/en/building-sites/elements/snippets">Snippets</a> are pieces of PHP that return dynamic content, such as summaries of other resources or the current date. With snippets, you will often use Chunks to mark up the pieces of content it returns, instead of mixing the PHP and HTML.</p>
<p>Finally, <a href="https://docs.modx.com/current/en/extending-modx/plugins">Plugins</a> enable more advanced features by hooking into the extensive events system provided by MODX.</p>
<p>To learn more about MODX, be sure to check out the <a href="https://docs.modx.com/current/en/getting-started">Getting Started</a> section in the official documentation.</p>

А это получается что я получаю именно контент самого ресурса а не контент шаблона перед рендером

Получается, что так. Но с другой стороны, почему всегда стопроцентно загружаются всё поля, когда кликаешь тут — skrinshoter.ru/s/150522/s76QqLsq? Ещё одна непонятка.

Правильно ли я понял, что данные не успевают загрузится, а грид уже сформировался?

Вы сейчас прям описываете работу компонента 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 может работать и с Апачем?