Доброго времени суток ✌

Думаю, как и многие здесь, начал разработку сайтов благодаря курсам, заметкам и пакетам, созданными @Василий Наумкин. Лично я стал зарабатывать первые деньги именно благодаря MODx и Василию. Дай Бог Вам здоровья! ?

Сейчас же, Василий создал несколько курсов (в данный момент в бесплатном доступе на bezumkin.ru) по своей новой системе VESP: Vue + Eloquent + Slim + Phinx. Статьи, где упомнут такой выбор стека, к сожалению, не нашёл, помню, что выбор пал из-за того, что PHP хорошо знаком (мягко говоря) и переход на более современные тенденции более плавный. Мне эта идея понравилась и, изучая курсы, стал сразу работать над новым проектом, используя новую систему. Легче задышалось! Вы сами выбираете, где и что как должно работать, система вас не ограничивает! Рекомендация к прочтению: bezumkin.ru/sections/projects/3075
Понимаю, что создание того же (а именно агрегатор для бань с календарем и массой нестандартных решений) на MODx, несмотря на имеющийся Agenda, котрый покрывал 80% моих задач, был бы сплошной мукой. Даже простые вещи, как например, доабвить в календарь вывод номера телефона, ведь пришлось бы править исходники или выдумыать, как инетгрироваться в пакет без правок.

API на PHP, причём некотрые вещи, типо миграций и управление базой данных идентичны Laravel, а он в свою очередь имеет огромное сообщество, дополнения, инструкции и т.д. А управление фронтендом перенеслось на Vue + Nuxt для серверного рендера.
Выбор стека может быть любым: будь то полный переход на JS, как вы описали, или же React + дополения для роутинга и т.д. Vue — фреймворк, React — библиотека, и разница в том, что во Vue и Nuxt за вас уже решили (стандартизировали, можно сказать) структуру и архитектуру, не нужно придумывать велосипед. В React же выбор остается за программистом и стек может быть очень разным, как структура проекта, так и используемые технологии. Думаю, многие оценили прелести линтеров и преттиеров для js. Бесят, но зато разбираться в своем/чужом коде, оформленным по определенным правилам, куда проще ?

Выбор за вами :) Если полный переход на JS вас не пугает, как совершенно новое, чему придётся учиться с нуля — вперёд, всё получится! ?

Ок. Посмотрим на реализацию :-)

Начнем с того, что mfilter хоть и оптимальное решение, но сама схема таблиц такова, что при большом количестве товаров, даже с отключённой агрегацией, фильтры работают медленно. Кстати в моем компоненте агрегации нет, я ей никогда не пользовался и практический смысл её весьма сомнительный, но не суть. Ничего гениального я не придумал, принцип работы остался тем же: выбираем по каким полям фильтровать, выводим эти поля на фронт фильтруем. Разница только в том, что значения для фильтрации заранее собираются в отдельную таблицу(для маленьких сайтов) или в несколько таблиц(для больших). Что касается раздувания БД, то в текущей реализации у меня к 100К товаров 170К индексов(так я называю собранные для фильтрации данные). Если злоупотреблять опциями с множественным выбором, то можно конечно таблицу раздуть знатно. Опять же, это уже вторая версия, в первой индекс строился иначе, и там в БД было больше миллиона записей, однако запросы отрабатывали менее чем за 1сек, и если бы не проблема с невозможностью фильтрациии по множественным знаниям, я бы схему индексации менять не стал.

Интересно. Обычно вроде в mfilter2 у каждой категории товаров делают свои фильтры. Или если магазин простой, то для всех категорий один фильтр. Автоматическая сборка значений опций поможет сделать таблицу значений опций, но если таблица будет одна для опции и всех категорий, то в фильтр будут попадать значения опций из других категорий. А если для каждой категории и опции своя таблица, то это дофига раздует базу :-).
В фасетном поиске (фильтрации) самая проблема получить список значений опций. Чтоб не было не нужных значений и делалась агрегация(предварительный подсчет кол-ва товаров для значения опции). А сам то поиск штука не хитрая select join where значение опции = 'шина' например и это делается быстро и базу не особо грузит. Насколько я разбирался то, как сделано в мфильтер решение по моему оптимальное (за исключением кеширования) на php. Лучше только будут специализированные сервера Elasticsearch, Sphinx и т.д.
Ну у тебя может получиться что-то интересное, но мне вот сомнительно :-(. Я к тому что ты зря работу не делал. Но если и не получиться то будет опыт :-). Ну посмотрим. Вдруг ты придумаешь что-то сверхестественное ;-)

Будет только фильтрация.

В первой версии скорее всего будет только конфиг примерно такой

return [
    12 => [
        'filters' => [
            'width' => [
                'filter_type' => 'numrange',
                'field_type' => 'number'
            ]
        ]
    ]
]

12 — id категории, width — опция. По этой конфигурации будет создана таблица в БД с полями id, rid, width в которую будут записаны значения опции width для каждого товара. В шаблоне ты будешь вызывать сниппет и указывать ему параметр configName = 12 и шаблоны для каждого поля, по аналогии c mFilter2, а он тебе отрисует фильтры.

на то она и демо =)

У демо страницы беда печаль с мобильной версией

Ждем бету, хотелось бы протестировать его на каком-нибудь боевом проекте)
И ещё вопрос, будет только фильтрация или как в mSearch2 так же поиск будет?

Привет. Тут немного не понятно. А сами фильтры как формируются? В mfilter2 назначаешь поле и тебе в фильтер вываливаются доступные параметры. А у тебя как? Параметры вручную прописываешь?
В mfilter2 как раз подбор доступных параметров и занимает основное время. Сама фильтрация поиск по запрошенным параметрам это не долго.

Добрый день.
Только что установили компонент.
Не работает поиск и нельзя установить точку на карте в админке. Пробовали на нескольких сайтах.
joxi.ru/12MLKPMH8V6Lqm

Первым делом нужно сгенерировать API ключ. Заходите в Кабинета Разработчика, там жмёте «Получить ключ» и при заполнении полей выбираете сервис «JavaScript API и HTTP Геокодер».

Такой настройки нет joxi.ru/Q2KWdPEHgVMWk2

Что с этим делать, как исправить?

С mapex2, кстати, такая же ситуация…

Отвечу сам себе. Не указал

inputValue: 1

у полей xtype: 'xcheckbox'

Расширяю плагином отзывы, чтобы можно было ставить галочки и еще доп. поля. Делаю все по инструкции из документации. Текстовые поля сохраняются в админке, галочки нет. Поля xtype: 'xcheckbox'. В базе создал по типу поля «Опубликован». Ошибок в консоли нет. Не работает именно сохранение в базу. В чем может быть причина?

В общем, по итогу я сделал через обычный TV.
А то, что в JSON формате хранится нельзя отфильтровать (по крайней мере рус точно), т/к там все кодируется.

Потому что я о нем первый раз слышу :-). Блин… технологии быстро развиваются :-(. Теоритически перескочить на ноду нам возможно за года 3. В принципе сейчас рефракторинг кода нужен и заодно можно попробовать пересесть на другую технологию. Но вот вопрос? Передем мы на ноду, а за это время не появиться какой-нибудь новой технологии, что придется снова весь код переписывать??? Сейчас модно строить приложение как js фронт и апи-сервер. Мне кажется, что это на долго не устареет. И перетянув основную логику приложения на фронт потом можно будет просто менять апи сервер. Но вот не устареет ли эта концепция за 3 года? О_О

Спасибо ОГРОМНОЕ.

Версия MODX 2.8.6?
Если да, то попробуйте это: modx.pro/news/24265#comment-140918

PS
Уже написали ))

Ну это потому что у вас modx 2.8.6 Надо править исходники библиотеки phpthumb

Нашёл ниже ответ

поправил в 3 файлах

components/faq/model/faq/mysql/faqitem.map.inc.php
components/faq/model/bd_faq/mysql/bd_faqitem.map.inc.php
components/faq/model/schema/faq.mysql.schema.xml

тип на string и все заработало

Олег, добрый день)
Пишу спустя годы, т.к. пользуюсь до сих пор вашим готовым решением вопрос-ответ.
И после обновления modx revo На 2.8.6 при написании в админке ответа на вопрос и сохранении появляется 0, как на скриншоте:


И возможно вы это уже как-то исправили… и если возможно поделитесь пожалуйста новой версией) Сам пытался найти почему так, но не удалось(