Я не видел весь твой код, но думаю что $c это объект класса xPDOQuery, который является конструктором SQL-запросов. А $c->leftJoin(), $c->select() это всё вызовы методов конструктора запросов. После все манипуляций получается обычный SQL, который и отправляется в БД.
Если упрощать, то когда ты делаешь leftJoin одна таблица ставится рядом с другой так, чтобы совпали поля, которые ты указываешь в условии ON (или передаешь третьим параметром в метод leftJoin). Таким образом получается новая таблица, но с бОльшим количеством столбцов, при этом количество строк будет таким же как и в первой таблице. Например, если у тебя в первой таблице одна запись, а во второй две, в итоговой таблице будет одна запись. Именно поэтому ты не можешь просто взять и присоединить все товары, тебе нужно сгруппировать их по id заказа, упаковать их в одну строку и только потом присоединять. вот так можно получить товары для заказа с id = 594

<?php
$q = $this->modx->newQuery('msOrder');
$q->leftJoin('msOrderProduct', 'Product', 'msOrder.id=Product.order_id');
$select = <<<EOD
        CONCAT(
                '[', GROUP_CONCAT(
                    DISTINCT CONCAT(
                        '{"name":"', Product.name, '", "count":"', Product.count, '", "price":"', Product.price, '"}'
                    )
                    SEPARATOR ','
                ), ']'
            )
EOD;
$q->select('msOrder.id as order_id, :products AS products');
$q->where(['msOrder.id' => 594]);
$q->groupby('msOrder.id');
$q->prepare();
$sql = $q->toSQL();
$sql = str_replace(':products', $select,$sql);
$stmt = $modx->prepare($sql);
if($stmt->execute()){
    $result = $stmt->fetchAll(PDO::FETCH_KEY_PAIR);
    print_r($result);
}

Самое главное: нет конкретики…

Что за список товаров? Если в админке — он и так выводится в списке заказов, когда модалку открываешь. Если в публичной части сайта, к примеру, в ЛК, то зачем тащить процессор? Не проще ли составить нужный запрос в сниппете и в зависимости от id заказа цеплять товары? Ну, плюс ещё проверять принадлежность заказа к юзеру.

Зачем нужен пункт 1 и 2? Ведь это решается стандартными полями ресурса в MODX?

Для полного контроля над страницами и логикой отображения.

Инструкция! Вот чего не хватало, спасибо!!!
Зачем нужен пункт 1 и 2? Ведь это решается стандартными полями ресурса в MODX?

У меня css корректно сжимаются, но js если даже 1 файл добавил, то сразу в 500 сайт падает, не понимаю в чем проблема, попробую попробую конечно логи сервера посмотреть, но не понятно в чем причина. Странно, но на компонент нет документации ни какой. В интернете тоже нет особо комментариев.

копал и накопал что в пути не хватает папки img, т.е. путь должен быть espkrf.ru/vendor/ img/ /files/reports/reglament-documents/osnovnyie-trebovaniya-k-ekspertam-espk.pdf, отсюда вопрос, как это исправить?

А в логах следующее:
(ERROR @ /home/c/cz42644/test-iflower/public_html/core/xpdo/xpdo.class.php: 644) Could not load class: ms2_order_products from mysql.ms2_order_products.
(ERROR @ /home/c/cz42644/test-iflower/public_html/core/xpdo/xpdo.class.php: 644) Could not load class: msorderProducts from mysql.msorderproducts.
[2025-04-13 15:04:21] (ERROR @ /home/c/cz42644/test-iflower/public_html/core/xpdo/xpdo.class.php: 1827) No foreign key definition for parentClass: msOrder using relation alias: Product

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

Большое спасибо за ответ, но к сожалению я мало чего понял из него… Я даже не до конца понимаю, что такое фронт… Это фронт-енд? Т.е. панель администрирования? Или отработка скриптов?
Как я это себе вижу=) А ты меня поправь.
Те данные, что присутствуют в таблице с заказами, берутся из таблицы _ms2_orders, у меня уже получилось расширить эту таблицу данными из таблицы _ms2_order_addresses, это выглядело сложно, но я справился (скажу даже, что я не менял исходники, а сделал красиво, именно расширив своими файлами), т.к. нужный запрос уже присутствовал в процессоре (фильтрация заказов частично делается и по этой таблице). Я так понимаю, что за это отвечает эта часть кода $c->leftJoin('msOrderAddress', 'Address'); Т.е. дальше, я просто немного изменил SQL-запрос добавив выборку нужных полей.
Сейчас, мне нужно в запрос подключить еще одну таблицу, а именно _ms2_order_products, причем еще нужно сделать сортировку по id заказа, т.к. товаров в одном заказе может быть много.
Не получится ли сделать подобным образом?
или нужно идти по пути, который ты предложил?

Что такое msOrderAddress в данном случае $c->leftJoin('msOrderAddress', 'Address');? А самое главное откуда оно берется, это же не таблица в БД, а объект, класс или что-то еще? Где можно найти рождение msOrderAddress этого? Выше написанная строчка кода делает алиас в запросе, и при дальнейшем обращении я уже могу обращаться к таблице _ms2_order_addresses как Address.

Действительно опечатка, спасибо, исправил

Не выводятся товары привязанные к данной категории, как дополнительной
В админке они отображаются в обеих категориях, опубликованы, кэши сняты
Showlog также их не видит

{'!msProducts' | snippet : [
            'parents' => $_modx->resource.id,
            ]}

MODX 3.1.2-pl
MiniShop3 — 1.0.0-alpha

Но с другой — это сложнее: нужно учить, какие атрибуты куда вставлять.

однозначно сложнее, поэтому так делаю только я)))

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

Как работает мультиязычность?

Скоро будет отдельная статья про мультиязычность.

По сути, добавлять атрибуты в вёрстку — это то же самое, что вручную расставлять плейсхолдеры.

Не совсем. При натягивании совы на глобус верстки нужно расставить плейсхолдеры и записать значение плейсхолдера в админке. А перед этим нужно создать поля для этих значений. А тут ты расставил атрибуты, запустил скрипт и плейсхолдеры расставились, поля создались, значения записались. Другое дело, что migx не лучший способ хранения данных, поэтому твой подход безусловно круче.

Как работает мультиязычность? Допустим я перевел блок на три языка, как на фронте переключить язык?

Скажи пожалуйста, есть вариант получить ключ бесплатно для локальных экспериментов?

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

если удастся реализовать автоматическое заполнение контентом напрямую из вёрстки

В компонент уже встроена экспериментальная функция AI Block, которая позволяет на основе верстки автоматически создать конструктор блока, чанк и сразу добавить заполненный блок на текущую страницу — без каких-либо дополнительных атрибутов в верстке.
К сожалению, со сложными блоками ChatGPT справляется плохо, поэтому я пока отложил этот функционал.
Для включения этой функции нужно добавить ключ в настройку pageblocks_chatgpt_apikey и после этого в меню настроек блоков (рядом с кнопкой «Создать») добавить соответствующий пункт.

По сути, добавлять атрибуты в вёрстку — это то же самое, что вручную расставлять плейсхолдеры. Только ещё нужно знать, какие атрибуты использовать и куда их вставлять, поэтому этот вариант пока не рассматривается.

Сейчас в приоритете — режим разработчика и роутинг.

Скажи пожалуйста, есть вариант получить ключ бесплатно для локальных экспериментов? По описанию очень крутая штука, если удастся реализовать автоматическое заполнение контентом напрямую из вёрстки, выкину нафиг свой MigxPageConfigurator)))

Тсс :) Давай потише, а то сбегутся сейчас фанаты MIGX и запинают нас за то, что пытаемся отправить в прошлое эпоху foreach-ей и fromJSON-ов в шаблонах и чанках.

Так-то программирование в чанках с начала времён (появления php-шаблонизаторов) считалось плохой идеей, но MIGX так располагает, что про это многие забыли. Просто fenom даёт слишком много свободы, а MOGX как бы располагал к тому, чтобы этой свободой злоупотреблять…

Так что ты, @Aleksandr Huz тот самый наш герой, который показывает, что мир может быть другим, и код — красивым!
Вы вообще видели этот синтаксис в примерах «Режим разработки» из поста? Анбиливабл эвесамнесс какой-то! Слов нет как круто...

Во-первых, MIGX не умеет создавать вкладки, панели и, тем более, кастомные поля у ресурсов или пользователей.
Во-вторых, настройка таблиц в PageBlocks куда мощнее: данные сохраняются не в JSON, а в нормальной структуре БД, что даёт гибкость для фильтрации, поиска и реализации сложной логики.
А ещё в PageBlocks есть блоки, синхронизация блоков между ресурсами, встроенный роутинг и многое другое.

Поэтому PageBlocks на порядок мощнее MIGX — это уже полноценный фреймворк внутри MODX.

Хорошо, что ты об этом заговорил. Мы написали короткий блог на английском языке на сайте Sterc: sterc.com/en/knowledge/blog/modx-ai-hackathon-2

Если у тебя появятся вопросы — не стесняйся, задавай!

Спасибо ChatGPT за перевод. ;-)

Вау! Это уже в некотором смысле закрывает часть функционала MIGX, который порядком поднадоел, и к тому же не располагает к написанию красивого и качественного кода (к сожалению). С этим обновленным PageBlock будет ещё один повод вместо MIGX выбрать для создания CMP (custom manager page) в админке именно его.

Автору — спасибо! Будем пробовать при случае!

Как прошло мероприятие? Получилось ли прикрыть какие-то issue или подготовить PR в рамках прошедшего хакатона?
@Henk Everts поделитесь, пожалуйста!