Могу высказать свое, личное и не объективное мнение.
Считаю что даже в 2023 году ни node ни vuejs все еще не доросли до такого уровня, чтобы их использовать как основной стек для крупных, серьезных проектов. К самой ноде особых притензий нет, но поскольку она всегда идет в связке с каким то vuejs или react то и говорю о них как об едином целом.
Почему я так говорю. Ну во первых из последнего опыта. Долгие годы работали с классическим стеком технологий для веба, последние два проекта решили делать «модными». Тем более что это были закрытые crm системы и там не нужно было думать о сео и как следствие о ssr.
Наняли специально фронтендщиков, которые в грудь себя били что ничего лучше vuejs в мире не бывает и что они любую задачу там решат. И что в итоге — полный провал по всем срокам, все задачи выполняются в 4-10 раз дольше. Постоянные проблемы с тем, что никто не хочет писать ничего своего, все из готовых vue компонентов собирается и оказалось, что сложные вещи делать на vue очень сложно. Все привыкли какой-то туду лист по примерам сделать и считают что все — теперь на vuejs могу любой сложности проекты делать. А потом приходит заказчик, говорит, мол отличная таблица с данными, только встройте в нее такой то функционал и вот такой то, разработчики пытаются один готовый компонент впихнуть в другой, возникает кучу проблем. Короче говоря, то, что я могу сделать на чистом js/html/css за день (при условии что я бекендщик) на vue занимает недели. А учитывая, что заказчик очень переменчивый и может каждый день менять решения, то внести визуальные и логические изменения становится нашим фронтендищикам все сложнее и сложнее.
Можно и нужно конечно сказать, что это нам так не повезло, что мол есть фронтендщики которые делают любой сложности задачи и быстро. Может и есть, но у нас это уже третий опыт, третья попытка нанять опытных фронтедщиков и третий раз она заканчивается полным срывом сроков.
Но это мой опыт, но есть и другие звоночки, что сама идея современного фронтенда (рендеринг на клиенте) не была гениальной и может в скором времени быть признана неперспективной. Видели новый next.js? В нем разработчики делают шаг назад и постепепенно отказываются от рендеринга на фронте. видео
Мой вывод (очень субъективный) — на 2023 год vuejs все еще интересный, но не продакшен реди инструмент, на котором легко делать простые вещи (туду лист и прочее) но сложно и долго делать сложные вещи.

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

Думаю, как и многие здесь, начал разработку сайтов благодаря курсам, заметкам и пакетам, созданными @Василий Наумкин. Лично я стал зарабатывать первые деньги именно благодаря 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 и все заработало