Здравствуйте. Версия для MODX3 уже есть.
Вот ссылка

Олег, приветствую! Я вообще не понимаю github, вопрос простой, migx пока установить получается нельзя на modx 3?

СПС. js пагинация то, что надо.

код снипета.

<?php
/* Запрос к БД */
$results = $modx->query("SELECT * FROM employee_info");
$employeeList = $results->fetchAll(PDO::FETCH_ASSOC);
$out=' ';
foreach($employeeList as $data) {
    $depNum = $data['tirazhNum'];
    $startDate = $data['finishDate'];
    $jobTime = $data['finishTime'];
    $status = $data['status'];
    $salary = $data['salary'];
    $cardNum = $data['cardNum'];
    $varNum = $data['varNum'];
    $uniNum = $data['uniNum'];
    
    $out .= $modx->getChunk('employeeListOutput', array(
        'depNum'=>$tirazhNum,
        'startDate'=>$startDate,
        'jobTime'=>$jobTime,
        'status'=>$status,
        'salary'=>$salary,
        'cardNum'=>$cardNum,
        'varNum'=>$varNum,
        'uniNum'=>$uniNum
        ));
}
return $out;

Соответственно шаблон вывода в чанке employeeListOutput, а на ресурсе вывод сниппетом.
Получется сумашедшая портянка — более 400сот записей.

Да, читал про данное дополнение и кажись ваш пост был как раз) но время поджимает и мне быстрее написать своими силами, дабы не тратить время на понимание компонента

Рекомендую попробовать ZoomX на сайте-доноре. Компонент отлично справляется с построением API как раз с json ответами, и умеет отдавать сразу файлы, если вдруг вы его будете формировать заранее.

Как вы выводите записи на страницу? Если все сложно, можно использовать js пагинацию

Спасибо! Думаю все таки сделаю задачу в cron на вторичном сайте, чтобы он делал запрос по расписанию на какой-нибудь update.php основного сайта, а тот уже пусть выдает ответ в виде json с новыми расценками товаров

ну так перетащите часть из верхнего меню в подпункты (Иконка шестеренки в правом углу — Меню ). Либо у вас зум стоит в браузере

Обмен между двумя сайтами лучше производить в формате JSON. Это общепринятая система.
Инициатором обмена может быть как одна, так и другая сторона.
Варианты, которые вижу я.
1. Изменение цены одного продукта. В этом случае запускается событие, которое отправляет API запрос на сайт на сайт-приемник. В запросе артикул продукта и цена.
2. Изменение группы цен на сайте-доноре, в результате какой-то синхронизации со складом, например. В этом случае формируется текстовый файл json формата и посылается уведомление о готовности новых данных, со ссылкой на файл. Сайт-приемник, получив уведомление запускает скрипт обработки json файла
3. Сайт-приемник, самостоятельно, по расписанию запрашивает сайт-донор. Если товаров не много — то забирает на лету сформированный json Ответ. Если товаров много, то забирает файл, подготовленный заранее.
4. Если товаров много, то можно пойти дальше. Сайт-приемник первым запросом отправляет уведомление донору и необходимости подготовить свежие данные. Затем через несколько минут (сколько там нужно временим на подготовку файла с ценами), вторым запросом забирает подготовленный файл.

В целом все крутится вокруг json файла (или массива данных) и нескольких достаточно простых API запросов.

Если отключить — то получается не смогут. Согласен здесь проблема.
Наиболее простое решение это опираться на IP адрес клиента и срывать\показывать нужные компоненты.
Но это отдельный проект. Владельцы и разработчики далеко не дураки — я думаю в конце концов придумают решение.

Также авторам компонентов modstore, связанных с этими соцсетями — требуется компоненты отключить

А если компонент захотят купить из другой страны, где не запрещены эти соцсети, то не смогут?

Спасибо большое! Вариант с выгрузкой + cron мне больше нравится!

Да нормальный вариант.
Или на основном сайте сделайте выгрузку в простейший файл (текстовый) в формате «артикул: цена», а со второго по cron раз в час считывайте его да и обновляйте цены.

Не за что!

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

Хорошо, что разобрались.

Я тогда с гитом был на Вы совсем и с гитхабом тоже. Многое не знал. В итоге, скорее всего, просто создал новый репозиторий и пушнул в него. В MODX-репозитории тоже не сразу стал указывать ссылки на гитхаб, в большинстве случаев потому что выкладывать пакеты стал раньше, чем гитхабом пользоваться. Этот же vapor в репозиторий в 2013 году выложил, а в гитхабе только в 2015 году первый коммит. То есть я потом постепенно стал выкатывать исходники в гитхаб.
А заорхивировал я практически все свои репы, связанные с MODX, потому что это теперь не мой профиль.

Ну вот пока ты не написал, это было неочевидно. Цели обесценить твой труд у меня не было. Твой пакет на github заархивирован, ссылки на оригинальный код (в виде форка) нет, чтобы это можно было увидеть хотя бы здесь — github.com/modxcms/vapor/network/members. В описании пакета на modx.com тоже ничего нет о том, как было на самом деле (а выложить там может каждый, просто загрузив архив с пакетом). Спасибо, что написал и пояснил.

Добавлю объективности. Автором этого пакета являюсь именно я, и выложен он мной. Хотя львиная доля его, конечно же, написана Джейсоном. С тем же успехом можно говорить, что все сайты, написанные на MODX, идут за авторством MODX LLC, ведь в большинстве случаев основная часть этих сайтов написана командой MODX.
А тем vapor-ом, который лежит у Джейсовна, в чистом виде, пользоваться вот так не совсем получится. Очень подробно (в том числе и про авторство), написано вот здесь: freecode.academy/topics/modxcloud.com-vapor-i-klonirovanie-sajtov.html

Исходники на гитхабе github.com/MODX-Club/vapor
Есть там и такой файл: github.com/MODX-Club/vapor/blob/master/import.php, которого нет в исходном пакете.

Очень «рад» твоей высокой оценке моим трудам (немало пришлось покопать ядро, написать решения). В погоне за пропогандой MODX ты слишком уж забываешь о конечных разработчиках, и что они тоже имеют ценность.