Александр Туниеков

Для поиска советую яндекс поиск для интернет магазинов

У яндекса нет фасетного поиска. То есть фильтров нет

modx.pro/components/23283#comment-135724
Кажется ошибся. Тема для minishop2

Выяви на каком именно плагине и его код сюда.

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

да

Так плагин не надо было создовать. Надо было проверить что похожего плагина нет

resourceMap либо не генерируется либо его что-то прибивает. Не генерируется значит что то не так с модекс. Что-то прибивает вот здесь modx.pro/solutions/22267 рекомендуют плагин который прибивает

Костыль OnMODXInit ниже может послужить хорошим решением данной проблемы, и будет надёжным подспорьем довольно долгое время.

//  Resource map patch to reduce parse time
  if( ! empty( $modx->context->resourceMap ) ) {
      $options = [ xPDO::OPT_CACHE_KEY => 'context_settings/' . $modx->context->key ];
      if( $val = $modx->getCacheManager()->get( 'context', $options ) ) {
          $val[ 'resourceMap' ] = [];
          $modx->getCacheManager()->set( 'context', $val, 0, $options );
      }
  }
  //--//

Искушённый читатель предложит расширить стандартный класс менеджера кеширования и подменить его. На мой взгляд избавиться от плагина потом проще

Ну напрямую я редко пишу. Так что не делал и с проблемами не сталкивался. Возможно в этом ничего страшного нет.
А вот через API сталкивался с тем что импорт тупит. Но мне через API проще

Мнда… не зная ваш скилл пнуть и еще в верном направлении.
Для импорта из эксель надо знать структуру хранения данных в модэкс минишоп. Затем как читать эксель в php. Это PHPOffice или конвертировать эксель в csv и читать в php csv файл. Затем эти данные раскидываешь по полям базы данных с помощью API MODX либо напрямую в базу писать(не рекомендую)

Я сталкивался хостер порты блокирует.

в файле \core\cache\context_settings\web\context.cache.php часть массива resourceMap присутствует?
Только метод научного тыка. Смотреть по коду что вообще происходит. Пробовать убирать добавлять что-то и так пока не поймешь в чем причина.
Или modx переставить или сайт заного переписать с обновленным модекс

файл кеша \core\cache\context_settings\web\context.cache.php

$resourceMap это карта ресурсов modx. Она генерируется при первой инициализации контекста modx и сохраняется в кеш.
Ошибка значит, что $resourceMap пустая. Проверьте кеш modx. Что там права на запись есть. Почистите кеш. И проверьте чтоб плагины $resourceMap не прибивали. Это иногда рекомендуют на больших сайтах.

@Артур после вчерашнего разбора mapFilter не сильно выигрывает у mFilter2. Так что его разработка обратно повисла.
Вообще участие в разработке Минишопа меня не сильно интересует. Он меня и в теущем виде устраивает, но вот фильтры для Минишопа интересуют. С ними проблемы есть.
mSearch2 платный компонент и дорабатывать его, чтоб деньги шли левому дяде меня обламывает :-).
Думаю, что участие в разработке бесплатных фильтров для Минишопа, мне интересно. Есть только одно препятствие. Я, обычно, пишу на jQuery. И на ванильный JS не спешу переходить. На jQuery удобней писать и есть мого примеров в интернете. Но если перед глазами будут лучшие примеры кода на ванильном JS, то писать на нем, конечно, смогу.
Примете в комманду? :-)

Решил описать кеширование mFilter2. Начал здесь https://modx.pro/development/23310

Ну тогда надо архитектуру как-то менять.
TV rubrika со списком множественного выбора (там несколько значений вида имя1==1||имя2==2||имя3==3) храниться в базе как текст например такой «1||3||13». И ни как запросом LIKE не отличишь 1 от 13.
Нужно список множественного выбора хранить как отдельные значения в таблице. Например tvsuperselect храниться в 2 таблицах и как текст «1||3||13» и в отдельной таблице отдельные значения. Я не помню как именно.
Если использовать tvsuperselect, то, наверно, можно в pdoPage подцепить 2-ю таблицу и написать что-то вроде

[[!pdoPage?
        &parents=`4`
        &loadModels=`tvsuperselect`
        &leftJoin=`{"2-таблица":....}`
        &groupby=`modResource.id`
        &where=`{"2-таблица.value":[[*option]]}`
        &tpl=`RowTpl`
]]

Может так

[[!pdoPage?
        &parents=`4`
        &includeTVs=`rubrika`
        &where=`{"rubrika:LIKE":"%[[*option]]%"}`
        &tpl=`RowTpl`
]]

если значения rubrika меньше 10 должно ловить. Если больше 10, то на option=1 словит и 1 и 10 и 11 и т.д.

Не быстрее. Так только от 1 запроса на картинку избавишься. По идее самый быстрый вариант подцепить парент титле и картинку в pdoResource. На 99% уверен. Но, конечно, если гнаться за скоростью, надо тестировать все варианты и на практике смотреть уже.

Не знаю как в прошлый раз тестировал. Тогда в моем компоненте mapFilter загрузка с подсчетом результатов на 10т товавов в каталоге выдавало около 10с, а сейчас первая загрузка около 1,2с а вторая с кешем mysql 0.0769041: Total time. (В каталоге 10т. товаров — это самый большой каталог. Всего товаров на сайте 27т.). Правда сейчас я чуть подшаманил и запрос делаю только для 1 каталога.
А вот прокешированный mFilter2 на этом же каталоге при загрузке из кеша массива ids ресурсов тратит 1.7866640: Total time. И при выборе какого-то фильтра делает suggestions 25с.
mapFilter:

mFilter2:


То есть mapFilter работает все таки быстрее mFilter2. И имеет смысл его доделывать. То есть, я не буду выкладывать код. В течении 2-3 месяцев доделаю и буду продовать :-).

пс. Почему-то mFilter2 ошибочно считает suggestions. Для женщин он посчитал 31 кольцо, а на самом деле их 4082.

пс2.

в mFilter есть подсчёт результатов по каждому фильтру, но для фильтров из коробки я этого делать не планировал

На самом деле, если сделали фильтры как в mFilter2, то suggestions уже просто посчитать. В mFilter2 это 100 строк кода всего.

Да я про подсчет результатов. Почему-то называл всегда подсказками :-(

поэтому скидывайте кейсы

Сейчас код вне зоны доступа :-). Завтра скину