Александр Туниеков

BannerY видел 6 лет назат и напрочь забыл что там

pdoResources делает getChunk на каждую запись из базы. То есть на каждый ресурс вызывается обработка чанка.
Насколько я понимаю задачу, то либо вызывать pdoResources 2 раза, либо писать свой сниппет.
1) вызывать pdoResources 2 раза

<div class="col-lg-6">
	<div class="swiper>
		{* Start &TPL part-1 *}
                {'!pdoResources' | snippet : [
		      'tpl' = '<div class=" swiper-slide">{$name}</div>'
                ]}
		{* End &TPL part-1 *}
	</div>
</div>
<div class="col-lg-6">
	<div class="swiper-tabs">
		{* Start &TPL part-2 *}
                {'!pdoResources' | snippet : [
		      'tpl' = '<div class="swiper-tab">{$name2}</div>'
                ]}
		{* End &TPL part-2 *}
	</div>
</div>

Либо написать сниппет, например, getRes. Только для modx 2.x

$pdo = $modx->getService('pdoFetch');
$pdo->setConfig([
    'parents'=>'10',
    'return'=>'data',
    'limit'=>20
]);
$resources = $pdo->run();

return $pdo->getChunk('getResTPL',[
    'resources'=>$resources
]);

getResTPL

<div class="col-lg-6">
	<div class="swiper>
		{* Start &TPL part-1 *}
                {foreach $resources as $res}
                    <div class=" swiper-slide">{$res.name}</div>
                {/foreach}
		{* End &TPL part-1 *}
	</div>
</div>
<div class="col-lg-6">
	<div class="swiper-tabs">
		{* Start &TPL part-2 *}
                {foreach $resources as $res}
                    <div class="swiper-tab">{$res.name2}</div>
                {/foreach}
		{* End &TPL part-2 *}
	</div>
</div>

Хм… чет я притупил.

А php не весь на сервере выполняется? То есть по идее не важно откуда запущен должно же брать время сервера О_О

А вот что касается Vue внутри MODx, ну, апплодировать ногами тоже можно, но лишь ради развлечения других людей.

Грубовато :-)

Товары будут продаваться и без Vue.js

Чисто на товары Vue и не надо. Надо на динамичное приложение. Уже надоело как надо показать какую-то не стандартную модалку, то чанки на феном и он на фронте не работает. Приходиться идти по ajax на сервер выбирать отдельно данные закидывать их в чанк и html уже забирать. Много лишних телодвижений. Шаблоны лучше на фронте заливать данными. По большому счету я хорошо знаком только с модекс. Другие системы смотрел, но что-то не производят они впечатления. Пару api можно быстро создать, но чтоб чисто сделать апи для 200 таблиц понадобиться год. И еще год фронт написать. Тут на работе не будут ждать 2 года, чтоб у них все заработало. Новое можно только постепенно. Сейчас неделю ночи трачу обдумывая как на основе модекс бек сделать. По идее в часов 200 в течении 2-3 месяцев можно сделать такой функционал, что потом переезд будет в разы проше чем на каком-либо другом беке.

Ясно. Спасибо. Посмотрю потом

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

Реплиировать бд это синронизация бд или просто раз скопировать?
Если раз скопировать, то как функционал который еще не написан, а работать компании нужно? А написать год или 2.
Если синхронизировать, то это может гемор. Самописно я пробовал и точно гемор. А какой либо софт не знаю не смотрел еще. Если подскажете, будет интересно. И еще многие таблицы исторически созданны не оптимально. Хочется их переопределить, но сайт под эту структуру таблиц уже заточен. При синхронизации хотелось бы переопределить структуру таблиц :-(.

Ну на модекс написан за 8 лет большой функционал и на другой сервер его маленькими блоками не перекинешь.
И большими может тоже не перекинешь :-(. Вообщем есть таблица заказов и от нее зависит склад, производство, снабжение, логистика и т.д. Я счас пытаюсь маленькие блоки на vue перевести. Например распределение деталей из заказов по сменам производства. Или хотя бы написать распределение ресурсов(работников) по сменам.

Хороший вопрос :-). Сам думал. Но gtsAPI это только часов 6-12 остальное разборки с vue. Чтобы отдать чисто страницу с #app надо реализовать функионал который выдается pdoMenu и Login еще. Это еще часов 40 для реализации авторизации. Ну меню конечно роуты SPA дают не так сложно если по стандарту идти, но весь функционал за 8 лет написанный я в vue за неделю не напишу. И за года 2 не напишу наверно :-). То есть надо и меню модекс переключать и меню SPA. Что тоже сложно. Пока проще pdoMenu и Login от модекса и только подрубать часть функионала на vue на странице.

Хм. Я чет не подумал что у меня ситуация отличается. У меня 200 таблиц в базе и на фронте. Писать контроллер на каждую таблицу замучишься. А для большинства таблиц как раз только GRUD и требуется. Под это и заточено. Еще перенести функионал getTables на PrimeVue и треть работы сделана :-)

Спасибо за донат. Хотел в заметке спросить надо ли дальше и подробнее описывать :-) но уже запарился. Теперь буду знать. Надо расписывать. Только блоками работы поменьше, чтоб не запариваться и чтоб понятнее было. А стартовый блок работы получился большим. Я насчитал 60 часов работы О_О.

Да правильно. Сложновато написал. Хорошо еще что сейчас начал описывать. Потом вообще бы тяжко было все хитро сплетения прописывать.
В таблице указываешь точку монтирования — это куда слать запрос. Указываешь класс контроллера и путь к нему — то есть это где искать код код обработчика.
Но фишка то в том чтоб по возможности код обработчика вообще не писать. Класс контроллера остовляешь пустым и указываешь нужную таблицу и GRUD API уже есть. Думаю это съэкономит время.

Или в index.php 'msProductData' вместо массива строка

'msProductData' => "require_once 'msproductdata.map.inc.php'",

Какой то не правильный плагин в папке core/components/minishop2/plugins/. Там плагины для расширения полей базы данных минишопа в виде index.php например

<?php
return array(
    'map' => array(
        'msProductData' => require_once 'msproductdata.map.inc.php',
    ),
    'manager' => array(
        'msProductData' => MODX_ASSETS_URL . 'components/minishop2/plugins/myplugin/msproductdata.js',
    ),
);

и msproductdata.map.inc.php

<?php
return array(
    'fields' => array (
		'avaible' => 1,
		'europrice' => 0.0
	  ),
    'fieldMeta' => array (
		'avaible' => 
		array (
		  'dbtype' => 'varchar',
		  'precision' => '50',
		  'phptype' => 'integer',
		  'null' => true,
		),
		'europrice' => 
		array (
		  'dbtype' => 'decimal',
		  'precision' => '12,2',
		  'phptype' => 'float',
		  'null' => true,
		  'default' => 0.0,
		),
    )
    ,'indexes' => array(
.....

наверно index.php присутствует, а файл определенный в строке ниже отсутствует

'map' => array(
        'msProductData' => require_once 'msproductdata.map.inc.php',

то есть для msProductData отсутствует файл msproductdata.map.inc.php.

Возможно в этом причина. Код брал со страницы Плагин товара для miniShop2 MODx Revo

Это предупреждение наверно не из этого чанка галереи. Во первых стоит проверка {if $files?} во вторых если ругается на второй вызов {foreach $files as $file}, то должно ругаться и на первый вызов {foreach $files as $file}.
И, самое главное, в третьих ругается в файле /public_html/core/components/minishop2/model/minishop2/minishop2.class.php на строке 630. То есть чанк вообще не при чем. Посмотрите что есть там у вас в файле minishop2.class.php на строке 630

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

В курсах Василия по Vesp есть интересный движок https://github.com/k-samuel/faceted-search

Ок. Посмотрим на реализацию :-)

Интересно. Обычно вроде в mfilter2 у каждой категории товаров делают свои фильтры. Или если магазин простой, то для всех категорий один фильтр. Автоматическая сборка значений опций поможет сделать таблицу значений опций, но если таблица будет одна для опции и всех категорий, то в фильтр будут попадать значения опций из других категорий. А если для каждой категории и опции своя таблица, то это дофига раздует базу :-).
В фасетном поиске (фильтрации) самая проблема получить список значений опций. Чтоб не было не нужных значений и делалась агрегация(предварительный подсчет кол-ва товаров для значения опции). А сам то поиск штука не хитрая select join where значение опции = 'шина' например и это делается быстро и базу не особо грузит. Насколько я разбирался то, как сделано в мфильтер решение по моему оптимальное (за исключением кеширования) на php. Лучше только будут специализированные сервера Elasticsearch, Sphinx и т.д.
Ну у тебя может получиться что-то интересное, но мне вот сомнительно :-(. Я к тому что ты зря работу не делал. Но если и не получиться то будет опыт :-). Ну посмотрим. Вдруг ты придумаешь что-то сверхестественное ;-)

Привет. Тут немного не понятно. А сами фильтры как формируются? В mfilter2 назначаешь поле и тебе в фильтер вываливаются доступные параметры. А у тебя как? Параметры вручную прописываешь?
В mfilter2 как раз подбор доступных параметров и занимает основное время. Сама фильтрация поиск по запрошенным параметрам это не долго.