Разобрался. Спасибо!

Указывать нужно либо modx, либо fenom

Баха, а подскажите пожалуйста, как сделать синтаксис как у вас на фото. Не выходит.
Прописал вот так:

"files.associations": {
      "*.tpl": "html | modx | fenom"
    }

Работает либо одно, либо другое.

Спасибо!

Vue/React не делают шаг назад. Добавили серверного рендеринга, чтобы банально быстрее грузилось, чтобы пользователь быстрее мог увидеть интерфейс, а не белый лист с индикатором загрузки.

Проблемы с расширяемостью готовых Vue/React/Svelte компонент действительно существует, проблема не решается в лоб. Но об этом знает любой front-end разработчик с релевантным опытом.

Добрый день!
Спасибо за проделанную работу! Очень нужное дополнение. Донат отправил.

Респект, хоть и пользуюсь phpStorm)

На страницах-символичеких ссылках не работает

Тут решение. Пишите в ТП на Модстор в следующий раз.

Спасибо товарищ за теплые слова, они зачастую бывают важнее всего остального

Очередной крик души)
Мне знакома твоя ситуация, я сам был в ней 2 года назад и вот к чему пришел в итоге поисков я:

• MODX, действительно, скажем честно, вряд ли ожидает новый взлет популярности — всему причина нежелание разработчиков кардинально менять движок, но с другой стороны он как решал прекрасно свои задачи 10 лет назад так и решает их сейчас. Если Web-мастеру становится тесно с ним жить, то значит он перерос этот движок, что хорошо на пути развития как специалиста.
• Куда двигаться дальше? Мой путь: Laravel, Spiral Freamework — просто «миллиарднократный» скачок в плане Developer Experience, всё по полочкам, всегда знаешь где, когда и откуда растут ноги у малейшей ошибки в коде, мониторинг запросов и ещё куча всего всего, просто на голову выше качество кода самих фреймворков — есть чему учиться.
• PHP или Nodejs — бесспорно нода за последние годы выросла и на ней можно реально делать хорошие, сложные проекты, но мне гораздо легче оставаться в рамках знакомого языка, который полностью покрывает потребности проектов, что мне достаются. И тут замечу, что php умеет обрабатывать js на стороне сервера, а то меня это смутило как-то в твоем крике души, вопрос лишь гугления. Если просмотреть внимательно тенденцию реактивных фреймворков — до них всех начало доходить, что всё делать на клиенте не самый лучший путь, отсюда как грибы у всех начали появляться Server Actions — многие «старики» даже ржут с этого, так как по сути эти «реактивисты» возвращаются к тому же с чего уходили, то есть к серверному рендерингу, просто с последующей гидратацией. С другой стороны классические движки наоборот переняли многое от реактивщины и сегодня можно комфортно писать привычные шаблоны на бекенде прямо в виде SFC как например во Vue и это всё уедет на клиент отрендеренное. Хороший обмен опытом между двумя путями.
• Ну и чуть приближенней к твоей задаче из моего личного опыта: такие вещи как CRM и ERP системы нужно писать на очень зрелых технологиях, проверенных временем и как правило такие системы пишутся и состоят из 2 частей отдельный проект API, и отдельный проект это клиентские приложения, на чем бы они не были написаны. Сегодня ты делаешь сайт, завтра понадобится мобильное приложение под android и под ios, а послезавтра уже десктопный софт на винду и macos. Когда есть API с хорошей документацией, развивать проект гораздо удобнее и легче. ERP это один из самых сложных по структуре проект из всех что мне доводилось встречать, куча асинхронщины, что многих php-шников сразу вводит в ступор, но тут появляется Spiral Framework — чудо мутант PHP + GO, целью которого как раз являются такие вот сложные, многослойные проекты, вот собственно его я и выбрал и подробно в нем копаюсь последний год, пока впечатления только положительные.

Именно, вам не повезло или вы так специалистов выбирали. Например, не могу порекомендовать себя на данный момент в этом стеке, т.к. сам учусь в процессе.

Сколько людей, столько и мнений, возможно, вам этот подход не подходит, а может не разобрались толком, а может используете не там, где надо, а может «спецы» такие и т.д. Есть масса задач, для которых CMS подходят куда лучше, ибо нечего велосипед изобретать, а есть такие, реализуя которые на CMS сталкиваешься с массой сложностей и ограничений. Василий отлично описал это в статье, упомянутой выше в комментарии. В мире MODx — это ExtJS, это конфликтующий сам с собой Composer (а точнее разные версии дополнений, необходимые для разные дополнений) и т.д. Сравните реализацию одного и того же на Vue и ExtJS.

Такая компания, как Сбер, наприимер, использую не по наслышке React, не жалуется ?

Ух, где же Вы, Николай Ланец, вас в этом обсуждении очень не хватает :)

нет слов, вы большой молодец.

Со стороны представителя сообщества хочу сказать огромное спасибо тебе Баха. Ты большой молодец. На полном энтузиазме, не прося ничего в замен, не хвастаясь (ну ладно чуть чуть среди своих) — проделал огромную работу. Кто не в курсе Баха занимался этим наверное полгода, периодически показывая нам в закрытой группе небольшие кусочки проделанной работы.

Друзья, вот именно на такие заметные проекты, ускоряющие вашу собственную работу и идут донаты.
Мы от коллектива поощряем нашего друга на сумму 20 000 рублей. Но хотелось бы выделить больше.
Потому в очередной раз призываю вас всех поддержать копеечкой сообщество или лично Баху для дальнейшего развития.
Все реквизиты сообщества можно посмотреть здесь

Могу высказать свое, личное и не объективное мнение.
Считаю что даже в 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 и т.д.
Ну у тебя может получиться что-то интересное, но мне вот сомнительно :-(. Я к тому что ты зря работу не делал. Но если и не получиться то будет опыт :-). Ну посмотрим. Вдруг ты придумаешь что-то сверхестественное ;-)

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