Виталий Валерьевич

Сниппет msProductOptions выводит товары общим массивом. В принципе, никто не запрещает в чанке вывода делать с этим массивом всё что угодно, в том числе и делить по категориям. Однако всё чаще поступает запрос от клиента не только вывести категории, но и соблюсти их сортировку.

Для этих целей мне пришлось msProductOptions переписать. Мой вариант сниппета воспроизводит запрос msProductData::loadOptions с сортировкой по полю rank категории, затем группирует все опции по категориям с соблюдением сортировки самих опций.

Подскажите или намекните как правильно реализовать следующее:

11000 товаров
У каждого производителя есть свои коллекции.
в коллекции существуют множество товаров (напольная плитка, плинтуса, настенная плитка и т.д.)

как в карточке товара (какая-либо коллекция) вставить все товары которые есть в этой коллекции

Пример:
Рассмотрим коллекцию А. в ней существует 3 вида товаров (Напольная, Настенная, и плинтуса)

если
в коллекции есть:
Плинтуса -> то выводить надпись Плинтус и все товары данной колекции
иначе если есть
Напольная плитка -> то выводить Напольная плитка и товары и т.д.

Извиняюсь за такое подробное описание, но я выложил суть вопроса как можно подробнее

Всем, кто хоть раз пытался завести mFilter2 на большом кол-ве товаров и хотя-бы 10 опциях в фильтре, известно, что тормозов не избежать. Вот и мне попался на днях сайт, в котором, казалось бы, всего-то 7000 товаров и 10 опций на странице каталога. Однако сниппет фильтра отрабатывал за 3-4 секунды. Переписал на Fenom — стал отрабатывать за 2-3 секунды.
Не годится! Тем более, что у заказчика было требование: «Чтобы сайтом было комфортно пользоваться». Что-ж, взял задачу — надо решать!

Дебаг показал, что проблема в методе mse2FiltersHandler::getMsOptionValues, а именно в запросе (7k товаров!), который выглядит как-то так:

SELECT `product_id`, `key`, `value` FROM `modx_ms2_product_options` AS `msProductOption` 
WHERE (`msProductOption`.`product_id` IN (3394,3408,еще 7 тысяч ID)
AND `msProductOption`.`key` IN ('atr_n1','atr_n6','atr_n5','atr_n12','atr_n43','atr_n46','atr_n29','atr_n11','atr_n44','atr_n2'))

Возникла необходимость при помощи msOptionsPrice2 реализовать составной товар. Оказалось, что компонент не умеет прибавлять к начальной цене товара несколько цен из модификаций одной опции.
Например, есть опция Наполнители, у нее около 20 значений. На фронте, при выборе каждого из значений, цена товара должна увеличиваться на N рублей. Проблема заключается в том, что имена тегам чекбоксов мы даем в виде массива:

<input type="checkbox" name="cb[]">

Компонент, в свою очередь, с таким работать не умеет. Предлагаю решение в четыре простых шага!

В сообществе часто проскакивают вопросы про мультидоменность на одной копии MODX. А у меня, как раз, сайты демо версий компонентов реализованы таким образом. Думаю, информация будет полезной!

Приветствую сообщество!

Вопрос собственно в следующем!
Как бы мне сделать вкладки как на здесь на modx.pro для одного юзера! (заметки, комменты, избранное)
П.С.
Говорить о том, что «надо сначала воспользоваться поиском» не надо, пишу это как раз потому, что воспользовался!

Понимаю есть ааахренеть сколько мануалов и примеров, например здесь:

https://modx.pro/howto/7909-page-users-on-modxpro/

но тем не менее пример у меня не работает, даже не хочет работать элементарно страница пользователя!
Сама страница пользователя у меня тем не менее есть и организована так:

<?php
// обрабатываем только события OnPageNotFound, на случай, если отметили галкой и другие в настройках плагина
if ($modx->event->name != 'OnPageNotFound') {
    return false;
}
// на случай, если у нас настройки кто-то менял, получаем значение переменной, через которую передаются ссылки в modx от веб-сервера
$alias = $modx->context->getOption('request_param_alias', 'q');
// проверяем, что такая переменная есть, иначе и обрабатывать нечего
if (!isset($_REQUEST[$alias])) {
    return false;
}
// наш запрос, который нужно разобрать и обработать
$request = $_REQUEST[$alias];
// разбиваем ссылку на составляющие,
// как правило, будет что-то вроде users/username, на выходе будет массив с этими значениями
$chunks = explode('/', $request);
// на всякий случай проверяем, что у нас есть корневой ресурс для пользователей, страница users
if (!$users = $modx->getObject('modResource', ['id' => 571])) {
    $modx->log(modX::LOG_LEVEL_ERROR, 'Entry point resource for users not found.');
    return false;
}
// а теперь обрабатываем нам запрос. 
switch ($chunks[0]) {
    // сверяем первую часть ссылки с алиасом нашего ресурса для пользователей, должны совпадать
    case $users->get('alias'):
        // еще одна проверка существования ресурса (наверное можно удалить, взял пример из реального проекта)
        if (!$usersSection = $modx->findResource($chunks[0])) {
            return false;
        }
        // у меня ссылки генерились с html, поэтому я вырезаю расширение перед поиском самого юзера 
        $userAlias = str_replace('.html', '', $chunks[1]);
        // еще одна проверка + убираем концевые слеши и редиректим на нормальную ссылку
        if ($chunks[1] != $userAlias || (isset($chunks[2]) && $chunks[2] == '')) {
            $modx->sendRedirect($chunks[0] . '/' . $userAlias);
        }
        // пробуем найти пользователя по username из запроса, если не нашли, то посылаем 404 заголовок
        // тут важно вручную послать страницу 404, иначе, если вернем просто ошибку, то у нас опять запустится обработчик 
        // 404 ошибки, опять запустится наш плагин, опять тут будет ошибка и привет бесконечный круг и ААААА! Ничего не работает!!!!!
        if (!$user = $modx->getObject('modUser', ['id' => $userAlias])) {
            $modx->sendForward($this->getOption('error_page'), $this->getOption('error_page_header', null, 'HTTP/1.0 404 Not Found'));
        }
        // пользоввателя нашли, теперь подгружаем его данные (профайл, расширенные поля и тд)
        /** @var modUserProfile $profile */
        $profile = $user->getOne('Profile');
        $extended = $profile->get('extended');
        // прописываем все наши данные в плейсхолдеры, чтобы потом на странице их вывести
        $modx->setPlaceholders($user, 'user.');
        $modx->setPlaceholders($profile, 'user.');
        $modx->setPlaceholders($extended, 'user.');

		// тут у меня еще момент, что пользователь может указать, что у него профиль приватный и его никому показывать нельзя,
        // поэтому в таком случае тоже 404 возвращаем. Но можно удалить
        // profile private, we should return not found error
        // if (isset($extended['private']) && $extended['private'] == 1) {
        //     $modx->sendForward($this->getOption('error_page'), $this->getOption('error_page_header', null, 'HTTP/1.0 404 Not Found'));
        // }

        // ну и отправляем нашу страницу с шаблоном профиля пользователя, где уже выводим всю его подноготную
        $modx->sendForward($usersSection);
        break;
}

Сделана по этому примеру:

https://modx.pro/help/9820/

Прошу помощи! Но так, чтобы не пришлось менять вид чанков и политики вызова данных пользователя на фронт! Заранее спасибо за любою помощь!

Использую сниппет msCart для вывода корзины. Вопрос — как можно сделать, чтобы после добавления в корзину кнопка превращалась в Товар уже в корзине. Где хранится информация об этом?

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

Обычно использую office, который обеспечивает готовый личный кабинет из коробки с минимальными усилиями, он же позволяет сохранять все в базу, пользователей. Но вот беда, полей катастрофически не хватает. Логичным решением было создавать страницы для каждого пользователя, и добавлять сколько угодно TV. Так я и делал, но решил заморочиться и не дублировать страницы, а расширить таблицу пользователей и работать с ней напрямую, как с ресурсом.

Вот что я сделал:

Описан алгоритм для модуля интернет-магазина minishop2. Для других модулей алгоритм похож, но объекты отличаются.

Задача: сделать автоматический пересчет стоимости товаров в зависимости от общего количества товаров, находящихся в корзине.

$cartArray = $cart->get(); // Массив товаров в корзине
$cartProduct = $cartArray[$key]; // Один товар в корзине

Решение: пройти по всему массиву корзины и изменить цену товаров.

Вот и подоспело очередное, уверен, горячо ожидаемое обновление pdoTools.

На этот раз я придумал, как можно иначе подключать Fenom, что дало возможность реализовать кучу встроенных модификаторов, а там где их не хватит — автозагрузку модификаторов из сниппетов.

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

Следует учесть, что я реализовал не все фильтры MODX (но очень много), и не все из них работают точно так, как в MODX — поэтому потрудитесь прочитать документацию, прежде чем жаловаться, что у вас там опять что-то не того.

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