На сайтах B и C пишешь плагин на событие OnDocFormSave. В этом плагин отправляешь запрос с помощью CURL с данными ресурса на сайт A. На сайте A обрабатываешь входящий запрос: создаёшь или обновляешь ресурс пришедшими данными.
Хотел видео записать) Но у меня и без всяких ВПН, прокси и т.п. все работает и качается — по крайней мере сейчас) В общем мое решение в любом случае работает (как минимум пригодится для тех кто разрабатывает локально) и не требует вложений + тот же ютуб разблокирует)
Не будет этот вариант работать. Соединение с репозиторием идет с ip сервера, где у вас MODX не ужели не улавливаете?) Да и протокол, который вы указали блокируется, по крайне мере в Москве.
Ну я говорю разную скорость при одних и тех же условиях.
1 — зашел на страницу — 0.5 сек
2. — просто обновил страницу — 2 сек
3. — выбрал один чекбокс — 1 сек
4 обновил страницу с этим же чек боксом — 2,5сек
Что касается просто открытия/обновления страницы (без значений в URL), то довольно ровно 0.4 – 0.49.
В остальном чем больше фильтров выбрано, тем дольше обработка (проверяется больше условий).
Если выбраны только новинки, то 0.45, если добавить еще что-то, будет дольше.
Ну и зависит, конечно, от типа поля. Для TV и опций товаров нужны дополнительные запросы.
Захожу на страницу, по счетчику грузится за 0,5 сек
Обновляю просто страницу, страница загружается по счетчику за 2 секунд. Также и по фильтрам, скорость загрузки скачет в 4 раза при одних и тех же условиях.
Есть проблема с расширением, убирает из контекстного меню «Open with Live Server», с файлами шаблонов понятно это допустимо, хотя и не очень нужно, но а в .html то зачем убирать, приходится его отключать, неудобно. В настройках смотрел, нет ничего, как это исправить?
Иногда нужно отобрать в этой логике (например, блюдо по ингредиентам, чтобы было и то и то).
В демке именно так, но ничего не мешает указать в вызове &mode=`or` и будет стандартный режим.
Демо с 1 000 товарами в одной категории и логикой AND (то есть выполняются все условия по отмеченным опциям):
Я проверил… выбрал все цвета — получил 0 результатов. Реально AND работает. Выбирается товар у которого одновременно есть Красный, Синий, Белый и так далее цвета. Однако типовой фасетный фильтр работает через OR, то есть выбрать все товары у которых цвета Синий ИЛИ Белый ИЛИ Красный т.д.
То есть налицо логическая ошибка и антипаттерн. Не могу представить ситуации, в которых такая архитектура может быть уместна.
Не сочти за претензию, я скорее удивлен твоему выбору.
У Modstore есть правила размещения и это компромиссный вариант, который устроил обе стороны.
В любом случае никто же не заставляет покупать и всегда хорошо, когда есть выбор.
Нужно что-то большее, подождите выхода нового mFilter и купите его — никто же не запрещает.
Что касается скорости, то это решение для небольших магазинов, у которых в одной категории порядка 300-500 товаров (согласитесь, таких много).
Да, на большом количестве будут тормоза, ну так они и на mFilter2 есть и ничего, многие пользуются. Вот, к примеру, всего порядка 650 товаров в категории подтормаживает не меньше и ничего.
Новинки, Акции, Хиты, Цена и Цвет — поля товара miniShop3.
На складе — TV-шка.
Материал — опция категории (ms3_product_option).
Компонент потому и «simple», что не претендует на суперскорость.
Для >1000 товаров в категории или большого кол-ва фильтров нужно использовать другие решения.
Всего 125 657 комментариев
Как перестанет работать без впн, так мой метод пригодится)
1 — зашел на страницу — 0.5 сек
2. — просто обновил страницу — 2 сек
3. — выбрал один чекбокс — 1 сек
4 обновил страницу с этим же чек боксом — 2,5сек
Время округлил
В остальном чем больше фильтров выбрано, тем дольше обработка (проверяется больше условий).
Если выбраны только новинки, то 0.45, если добавить еще что-то, будет дольше.
Ну и зависит, конечно, от типа поля. Для TV и опций товаров нужны дополнительные запросы.
Обновляю просто страницу, страница загружается по счетчику за 2 секунд. Также и по фильтрам, скорость загрузки скачет в 4 раза при одних и тех же условиях.
Интересно, почему так происходит?
В демке именно так, но ничего не мешает указать в вызове &mode=`or` и будет стандартный режим.
Я проверил… выбрал все цвета — получил 0 результатов. Реально AND работает. Выбирается товар у которого одновременно есть Красный, Синий, Белый и так далее цвета. Однако типовой фасетный фильтр работает через OR, то есть выбрать все товары у которых цвета Синий ИЛИ Белый ИЛИ Красный т.д.
То есть налицо логическая ошибка и антипаттерн. Не могу представить ситуации, в которых такая архитектура может быть уместна.
Не сочти за претензию, я скорее удивлен твоему выбору.
В любом случае никто же не заставляет покупать и всегда хорошо, когда есть выбор.
Нужно что-то большее, подождите выхода нового mFilter и купите его — никто же не запрещает.
Что касается скорости, то это решение для небольших магазинов, у которых в одной категории порядка 300-500 товаров (согласитесь, таких много).
Да, на большом количестве будут тормоза, ну так они и на mFilter2 есть и ничего, многие пользуются.
Вот, к примеру, всего порядка 650 товаров в категории подтормаживает не меньше и ничего.
На складе — TV-шка.
Материал — опция категории (ms3_product_option).
Компонент потому и «simple», что не претендует на суперскорость.
Для >1000 товаров в категории или большого кол-ва фильтров нужно использовать другие решения.
Также в планах работа с MIGX-параметрами, но это позже.