Сейчас это еще не реализовано в официальной сборке, но покажу на примере слингов. Сразу скажу, что действий не мало надо сделать.
И еще: для обеспечения обратной совместимости хоть какой-то, придется дополнительно напрячься с переопределением классов. Единственное что могу сказать положительное, это то, что версия 2.1.0 как раз и вышла с дополнениями, которые писались под этот функционал.
Конечно, это не самое лучшее решение, и более правильный функционал появится позже в самой сборке, но если надо срочно, что чтож, значит надо делать. Итак, поехали.
Готовим параметры и базу данных
1. Создаем необходимые TV-параметры
Надо создать TV-шки этих параметров, меняющихся в товарах. В нашем случае это size и color. При этом надо в этих полях не конечное значение указать, а именно перечислить имеющиеся варианты. К примеру, у вас галстук с размерами L,X,XL и цветами Красный, Синий, Зеленый. В самом товаре надо будет выбрать все возможные значения, которые соответствуют наличию товара.
Лучше всего заводить TV-поле типа Мульти-список, в котором в возможных вариантах сразу прописать все возможные варианты. Вот так:
?
В нашем случае не принципиально, но все-таки числовые ID-шники всегда предпочтительней.
В таблице заполненных данных TV-полей у вас будут примерно такие данные: M||XXL||L. То есть по разделителю || можно будет понять, что по этому товару есть размеры M,XXL,L. Получить массив размеров можно будет через explode('||', $value);
2. Редактируем таблицу Заказ-Товар
Надо отредактировать вручную таблицу modx_billing_order_products (через phpMyAdmin или типа того):
2.1 Добавить колонки этих параметров (повторюсь, в нашем случае это size и color). Тип данных сами определите, но ни в коем случае эти колонки не должны быть nullable, и нельзя вставлять значения null.
2.2 Надо подправить индексы — удалить уникальный ключ order_id-product_id и создать уникальный ключ со своими параметрами. В нашем случае это order_id-product_id-size-color.
2.3 Подправить map-файл класса OrderProduct. Надо в него добавить описание ваших колонок. Лучше всего для этого использовать CMPGenerator. На всякий случай ревизия: gist.github.com/Fi1osof/f0372195175ade7a72fb/revisions
Суть этого действия в том, чтобы получить возможность в одном заказе иметь несколько товаров с одним и тем же id, только с разными параметрами.
3. Правим шаблоны
Все, на этом этапе мы уже имеем возможность добавлять товары с различными параметрами. Теперь нам просто надо в форме вывести чекбоксы или выпадающие списки с размерами и цветами, и эти данные отправить на процессор добавления товара в корзину. С шаблоном ничего показывать не буду — это обычная задача на уровне шаблона добавить поля в форму. Эти данные автоматически будут передаваться в запросе. Нам остается только на сервере поймать эти данные и учесть в добавлении товара. И вот тут начинаются трудности побольше…
Переопределяем процессоры
Для начала немного общей теории по добавлению товаров в корзину.
При добавлении товаров в корзину, запрос идет на процессор orders/products/add. Но если товара нет в заказе, то его надо добавить к заказу новой строчкой. А если уже есть, то тогда запись надо обновить. Это уже два разных действия и два совершенно разных процессора: один — create-процессор, создающий новую запись, а второй — update-процессор, обновляющий существующую запись.
3. Добавляем свой add-процессор.
Создаем свой add-процессор в вашей папке процессоров (у меня это site/web/basket/orders/products/add в неймспейсе modxsite), и в нем переопределяем метод поиска записи товара в заказе: gist.github.com/Fi1osof/642525c6ed5de4b38698#file-gistfile1-php-L28
Собственно здесь все. Если запрос на добавление товара будет отправляться на этот процессор, то товар будет искаться с учетом заданных параметров. Только не отправляйте поиск объекта дальше в родительский процессор, а то он получит первый же попавшийся товар с этим id, только без учета дополнительных параметров.
4. Переопределяем action-процессор.
Вот и все. Более удобный функционал для подобных задачах появится в самых ближайших версиях движка.