Андрей Степаненко

3. Как поправить ресолвер таким образом, чтобы добавление системных настроек и остальных данных из папки elements происходило после создания таблиц из схемы в базу, и установки всех добавляемых компонентов?

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

4. Каким образом сделать выбор компонентов при установке как в компоненте modMySettings

Здесь все есть:
https://github.com/webnitros/modMySettings/blob/master/_build/setup.options.php

Еще момент: при удалении компонента, резолверы удаляют и папку с шаблоном. То есть все что положиться в core/elements/ будет уделено

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

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

Получаем 30 записей отправляем их на exec_bg_script.
Ждем пока у этих 30 записей поставиться метка: завершено.
После чего получаем следующие 30 и продолжаем дальше.
Пока из обработки не уйдут все записи во временной таблице.

Так всегда можно отследить когда был запуск и завершение.

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

Если отключить сессии и не дожидаться ответа, то получится аналогичный функционал:
Через ajax посылать все запросы разом к примеру в 1000 запросов, и не ждать ответа. Что то типо через цикл запустить.

А как контролировать?
Понятно что на 1000 ресурсов можно использовать. А если обновляется 100к ресурсов, Получается ответ не получен!
Очередь таких заданий забьет память и процессор.
Просто думаю как это встроить к примеру в msPre так как достаточно долго обновляется даже те же 2000 ресурсов при объеме в 100к.
Точней даже понимаю что это работать будет только, в безконтрольном режиме. И это проблема.

При учете что мне к примеру не нежно ничего получать из site_content а только id, оно еще быстрее будет.
Ноооооо если мы используем getCollection) То innerJoin не позволит сделать select!
Так что скорость ощутим упадет))
Кстати, твой код, исключает getCollection. О чем я писал когда говорил о IN.
Так что если по играть, с кодом, то явно увидишь разницу.

if($objectCount = $modx->getCount('msProductData', $q)) {
return $objectCount;
}
в $objectCount запишется 0
Приходилось встречаться что в итоге 0 это тоже true, скорей всего это в старом каком то php
по этому лучше так

if($count = (boolean)$modx->getCount('modResource', array())){
    
}

ну это интересно)) Запомню на будущие.
А теперь тоже самое только к примеру с получением pagetitle и price)
Вот тут явно увидите разницу

Как)) Мне просто интересно?
getCollection — дергает все поля как с site_content так и c ms2_products
Как он может быть быстрее даже с этого ракурса?
Обращение к msProduct?

Покажите код? Один и другой

Наверное поле куда делался IN, без индекс, и это обычное текстов поле.

И еще за актуальность временных таблиц следить. Причем разных нужных данных может быть много вариантов. Вроде кол-во перестановок пропорционально n! Если 2 таблицы по 5 колонок, то кол-во возможных выборок 10! = 3628800 вариантов :-).

Временная таблица!
Актуальность в одну минут, вообще не принципиально)))

'select' => ['*
        FROM `modx_tsklad_detail_naryad_smena_link` AS `tSkladDetNSLink`
        LEFT JOIN `modx_tsklad_order_list` `Detail` ON Detail.id=tSkladDetNSLink.det_id
        LEFT JOIN `modx_tsklad_orders` `Order` ON Order.id=Detail.sk_order_id
        LEFT JOIN `modx_tsklad_naryad` `Naryad` ON Naryad.id=tSkladDetNSLink.naryad_id
        LEFT JOIN `modx_tsklad_smena` `Smena` ON Smena.id=tSkladDetNSLink.smena_id
        LEFT JOIN `modx_nomenclature_detail_nom` `DetailNom` ON DetailNom.id=Detail.nom_id
        LEFT JOIN `modx_nomenclature_detail_class` `DetailClass` ON DetailClass.id=DetailNom.class_id
        LEFT JOIN `modx_nomenclature_type_job` `NomTypeJob` ON NomTypeJob.id=DetailClass.type_job_id
        LEFT JOIN (
            SELECT NextDNL.det_id AS next_det_id, NextDNL.naryad_id AS next_naryad_id, NextN.name AS next_naryad_name, NextDNL.smena_id AS next_smena_id, NextS.date AS next_smena_date, NextS.number AS next_smena_number
            FROM `modx_tsklad_detail_naryad_smena_link` AS `NextDNL`
            LEFT JOIN `modx_tsklad_smena` `NextS` ON NextS.id=NextDNL.smena_id
            LEFT JOIN `modx_tsklad_naryad` `NextN` ON NextN.id=NextDNL.naryad_id
            ORDER BY NextS.date ASC, NextS.number ASC) `NextDNL1` 
                ON tSkladDetNSLink.det_id = NextDNL1.next_det_id AND 
                (NextDNL1.next_smena_date > Smena.date OR (NextDNL1.next_smena_date = Smena.date AND NextDNL1.next_smena_number > Smena.number)
        ) 
        AND NextDNL1.next_smena_id = (
            SELECT NextDNL.smena_id AS on_next_smena_id
            FROM `modx_tsklad_detail_naryad_smena_link` AS `NextDNL`
            LEFT JOIN `modx_tsklad_smena` `NextS` ON NextS.id=NextDNL.smena_id
            LEFT JOIN `modx_tsklad_naryad` `NextN` ON NextN.id=NextDNL.naryad_id
            WHERE NextS.date > Smena.date OR (NextS.date = Smena.date AND NextS.number > Smena.number)
            ORDER BY NextS.date ASC, NextS.number ASC
            LIMIT 1
        )
        LEFT JOIN `modx_plazma_list` `PlazmaList` ON PlazmaList.det_id=tSkladDetNSLink.det_id
    '],

Никогда не понимал зачем такие мега запросы писать. Бесполезных join-нов куча. Этаж сколько выборка этого всего идти будет. А потом еще сидеть постоянно разбирать что там написано.

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

Почему то всегда охота все в один запрос запихать, но по опыту еще больше времени тратишь на всякие такие выборки.
Еще как вариант делать несколько запросов и получать id которые уже потом идут where в виде product_id IN (тут список id из какой то таблицы)

На примере получения товаров:
Этот код будет делать выборку в десятки раз быстрее:

$ids = [];
$q = $modx->newQuery('modResource');
$q->select('id');
$q->where(array(
    'published' => 1,
    'class_key' => 'msProduct',
));
if ($q->prepare() && $q->stmt->execute()){
    while ($row = $q->stmt->fetch(PDO::FETCH_ASSOC)) {
        $ids[] = $row['id'];
    }
}


/* @var msProductData $object*/
$q = $modx->newQuery('msProductData');
$q->where(array(
    'id:IN' => $ids
));
if($objectList = $modx->getCollection('msProductData', $q)) {
    foreach ($objectList as $object) {
       echo '<pre>';
       print_r( $object->toArray()); die;
    }
}

Чем

/* @var msProduct $object*/
$q = $modx->newQuery('msProductData');
$q->where(array(
    'Product.published' => 1,
    'Product.class_key' => 'msProduct',
));
$q->innerJoin('msProduct','Product','Product.id = msProductData.id');
if($objectList = $modx->getCollection('msProductData', $q)) {
    foreach ($objectList as $object) {
        echo '<pre>';
        print_r( $object->toArray()); die;
    }
}

join — зло еще то))

Не выяснял подробности проблемы, но суть в том что если хранить сессии на диске, то происходит блокировка сессии. То есть, пока первая страница не загрузится до конца. Вторая не начнет грузится, так как первая еще не записала сессию.
При хранении сессий в базе (как у modx по умолчанию), то что происходит со старой сессией? Так как блокировка при хранении в базе не срабатывает.

Добавил, обновлятесь

Прикручу

Не какие, только контекст.
Эта функция возвращается значения из карты сайта. А карта сайта хранится в кэше с ключем контекста.

public function getChildIds($id= null, $depth= 10,array $options = array()) {
        $children= array ();
        if ($id !== null && intval($depth) >= 1) {
            $id= is_int($id) ? $id : intval($id);

            $context = '';
            if (!empty($options['context'])) {
                $this->getContext($options['context']);
                $context = $options['context'];
            }
            $resourceMap = !empty($context) && !empty($this->contexts[$context]->resourceMap) ? $this->contexts[$context]->resourceMap : $this->resourceMap;

            if (isset ($resourceMap["{$id}"])) {
                if ($children= $resourceMap["{$id}"]) {
                    foreach ($children as $child) {
                        $processDepth = $depth - 1;
                        if ($c= $this->getChildIds($child,$processDepth,$options)) {
                            $children= array_merge($children, $c);
                        }
                    }
                }
            }
        }
        return $children;
    }

С этой проблемой уже сталкивались.
У вас дублирующий alias! Процессорый не умеют отдавать ошибку о дублиющих алиасах.

Сперва алиас уникальный сделайте у товара.

cp1.megagroup.ru/my/s3/data/menu/edit.php?ver_id=2614730&access=08aedbd3f&menu_id=22060861&popup=0&query_id=0#/my/s3/data/shop2/view.php?object_id=4167061&ver_id=2614730&access=08aedbd3f

Ну вы в курсе что стоимость того функционала 11 000р в месяц?

В общем купите и разбирайтесь с msImportExport))

А что за скрипт?

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