Sphinx

Проблема в том, что у доп. поля множественный выбор. Когда значение одно, фильтр нормально отрабатывает, но когда значений несколько, они сохраняются так: 1||2 и, конечно, это значение не равно 1.

Я выхожу из этой ситуации таким образом. В значениях доп. поля ставим не числа, а слова — завтрак==breakfast||обед==lunch||ужин==dinner||. В этом случае условие с LIKE нормально отработает и для случаев с одним значением, и для нескольких:

'where' => [
    'serviceTime:LIKE' => '%' ~ $servTime ~ '%'
]

Может пригодиться моя сборка modExtra
github.com/webnitros/siteDev/tree/master/core/components/sitedev/Extras/modExtra

Еще считаю полезно прицепить вот такие кнопки

А то вспоминать откуда у тебя компонента скачивается, постоянное мучение.

Ссылка на то как кнопки добавить:
https://github.com/webnitros/siteDev/blob/103270a49c69539d934bafc4ff9f9891dde7a684/core/components/sitedev/Extras/modExtra/core/components/modextra/controllers/home.class.php#L91

Можно конечно в какой нибудь плагин завернуть, но я не стал заморачиваться, добавил их в контроллер с проверкой на существования папки Extras/myComponent, в случае если папка существует то кнопки показываются

'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 — зло еще то))

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

/**
 * Remove objects
 */
protected function remove()
{
    /** @noinspection PhpIncludeInspection */
    $removed = include($this->config['elements'] . 'remove.php');
    if (!is_array($removed)) {
        $this->modx->log(modX::LOG_LEVEL_ERROR, 'Invalid structure detected on \'Remove\' source');

        return;
    }

    $count = 0;
    foreach ($removed as $className => $conditions) {
        /** @var xPDOIterator $objects */
        if ($objects = $this->modx->getIterator($className, $conditions)) {
            /** @var xPDOObject $object */
            foreach ($objects as $object) {
                $count += (int) $object->remove();
            }
        }
    }
    $this->modx->log(modX::LOG_LEVEL_INFO, $count . ' items have been removed');
}

Соответственно, в папку elements добавляется новый файлик — remove.php, где указываются класс сущности в качестве ключа и условия в качестве значения.

return [
    'modResource' => ['id' => 1],
    'modTemplate' => ['id' => 1],
];

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

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

Никогда не задумывался что так можно. Интересный способ — и правда быстрее. Правда надо в XML схемах ориентироваться.
Но надо еще понимать, что в этом случае мы не получаем управление записями в табличке внутри админки, только через API.
Или MIGX и здесь может помочь?

Я вот таким вариантом пользуюсь:

<?php

if( in_array($modx->event->name, ['OnManagerPageInit','OnBeforeManagerLogin']) ) {
    $logpath = MODX_CORE_PATH . 'cache/logs/error.log';
    
    if( file_exists($logpath) ) {
        if(filesize($logpath) > 5000000) {
            $logcontent = file_get_contents($logpath);
            $filename = 'error-'. date("Y-m-d_H:i:s");
            
            $zip = new ZipArchive();
            $zip->open(MODX_CORE_PATH . 'cache/logs/'. $filename . '.zip', ZipArchive::CREATE);
            $zip->addFromString($filename . '.txt', $logcontent);
            $zip->close();        
            
            $modx->runProcessor('system/errorlog/clear');
        }
    }
}

docs.sencha.com/extjs/3.4.0/ — Самый лучший источник, я только его использовал и использую.

Источник как обычно google.
Пару ссылок
https://metanit.com/web/extjs/12.3.php
https://ilyaut.ru/extjs/
https://modx.ws/extjs-urok-ext-js-script-modx-revolution
http://bustep.ru/modx/extjs/

Вообще есть типо официальная документация, но как всегда мне лень её читать, по этому ищу по случаю, когда что то надо.

Так как всяческих приемов очень много как можно сделать, все пишут как хотят. На то он и JS там сложно чтото стандартизировать.

Но можно выделить такие направления для изучения в js как: события, переопределения любых функций, классов, методов в общем того что в php работает иначе. Когда понимаешь как они устроены то намного легче работать с ExtJs. Ну а за все это отвечает javascript, так что надо в первую очередь его изучать.

Как бы я уже прекрасно понимаю как работает даже тот же VueJs (так как реализовал на нем интернет-магазин в связке с minishop2 через RESTfull), да простые приложения легко пишутся, но капни в насправлении Хранилища, и тут засада начинается не меньше чем с ExtJs. И кстати по документации тоже не очень просто найти что то сложное. VueJs хорош но я наверное не стал бы его использовать для той же админки modx.

Почему бы просто не сказать клиенту чтобы он нажал ctrl + shift + r?
Все равно придется менять в настройках каждый раз, а это не удобно.

1 вариант. Делать без процессора через newObject
2 вариант. Сделать политику на основе AdministratorTemplate, включить нужные разрешения — для создания документа new_document, дать доступ анонимам к контексту web c этой политикой, и еще могут понадобиться add_children, new_document_in_root, publish_document