Алексей

Эти соответствия уже хранятся в БД, судя по комментам выше. Могу ли я получить срок доставки не по id, а по названию города?

Собираюсь реализовать расчет срока доставки в карточке товара. Название населённого пункта я получаю по geoAPI. Судя по документации, получается, что мне нужно самостоятельно хранить в БД соответствие названий населённых пунктов и их id. Правильно я понимаю?

Вы опять не поняли) Функционал выбора значений для фильтра реализован. Непонятно, какое имя таблицы указывать при вызове спиппета mFilter. Ладно, вечером у меня будет возможность всё протестировать

Я использую msProducts, но кастомную таблицу с остатками. Исходя из того, что при вызове фильтра нужно использовать код таблицы, непонятно что туда передавать, когда таблица кастомная. У неё нет кода. Скорее все туда можно передавать любое значение, а таблицу задавать внутри методов.

По ссылке неполный пример. Там реализовано 2 метода из трёх. Если мой фильтр отличается только способом получения значений, я могу определить только метод getMyFilterValues. А для сборки и фильтрации будут использованы buildDefaultFilter и filterDefault. Верно?

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

Забавно)

Ок, 1С вычеркиваем. Остаются менее популярные системы учета, которые распространены среди небольших магазинов. Они умеют пробрасывать оффлайн-заказы через API.

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

Обычно такие решения поставляются как веб-сервисы под ключ без доступа к коду. Поставщики разрабатывают такие сервисы-сайты для партнеров по системе «дропшиппинг». На чём написаны ваши сайты с подобной архитектурой?

Автор, в демке поправьте «Мориторинг» в title

Самое интересное, что может быть реализовано в реальном времени — это реалтайм синхронизация. С 1С, с моим складом, с amoCRM(если речь об услугах). Насколько мне известно, даже у битрикса, который имеет монополию в сфере инструментов онлайн-продаж на PHP и в то же время является разработчиком инфраструктуры 1С, решения по синхронизации со складом далеки от реалтайма, по сути они компромиссные. Если такая немагазинная по своей природе CMS как MODX вместе с минишопом сделает серьёзный рывок в области инструментов онлайн торговли. MODX на сегодня является самым гибким для SEO коробочным решением, но нераскрученный бренд и, возможно, отсутствие плюшек, как вышеуказанная мной, мешают движку занять свою нишу в этой категории

Спасибо за ответ. Я уже почти всё понял экспериментальным путем. Тем не менее ваша ссылка будет для меня очень полезна.

В данный момент меня интересуют 2 вопроса.

1. Какое имя таблицы использовать при вызове фильтра, если фильтр работает с таблицей стороннего компонента?

2. Я собираюсь фильтровать товары по остаткам конкретной опции. Не станет ли система внутреннего кеширования помехой для отображения актуальной информации в режиме реального времени. Если станет, то как с этим бороться

404

Опция определялась. Проблема была в том, что timeweb не отправлял через mail любые письма, содержащие ссылки. Даже var_export($_SERVER, true). И всё это на оплаченном тарифе. Проблема решилась настройкой SMTP

Спасибо за ответ. По вашей ссылке приведён пример организации остатков для обычных товаров. Если товар имеет модификации, созданные, например, с помощью дополнения msProductRemains, то остатки будут храниться в отдельной таблице или в таблице MIGX. Будет ли mSearch2 работать с такими данными?

А причем здесь переключение контекстов? Основные разделы сайта региононезависимы. Мне нужно, находясь в контексте web, правильно ставить ссылки на нужный региональный раздел, расположенный на отдельном контексте, и подтягивать подтягивать региональные блоки конкретного региона.

Спасибо за ответ! Регион итак хранится в куках, но когда кука ещё не выставлена, чтобы избежать многократного определения региона и выставления кук, вынес эту проверку в плагин. В итоге мне помог ваш вариант с плейсхолдером:
В плагине:

$key = $modx->setPlaceholder('region_key', $key);

В сниппете:

$key = $modx->getPlaceholder('region_key');

Задать константу в плагине не получается…

Как передать параметр из плагина в несколько сниппетов?

Стоп. Чанк не подходит для хранения информации о пользователе, при условии, что интерфейс многопользовательский. Нужен какой-то объект, который будет доступен из сниппета, в который можно положить context_key. Есть такое в MODX?

$cr = $modx->newQuery('modContextSetting');
$cr->where(array('key' => 'region','value' => $region));
$cs = $modx->getObject('modContextSetting',$cr);
if(!is_null($cs))
{
    $key = $cs->context_key;
    $c = $modx->getObject('modContext',array('key' => $key));
}

Ошибся. Шаблоны общие для всех контекстов. Пробую реализовать. Как задать главную страницу для поддомена?

Как я понимаю, есть проблема с использованием общих шаблонов во всех контекстах и получении сущностей 2-го контекста из первого. Поправьте, если я не прав. Я писал, что использование контекстов мне не подходит. Если это так, то нужен альтернативный вариант