Семён Кудрявцев

Впервые вижу человека, выбирающего сопоставление таблиц бд по критерию скорости, и при этом игнорирующего саму суть сопоставления (и сортировки если что)
Если рассматривать заметку исключительно как инструкцию по починке эмодзи, без учета появления проблем с другими вещами — то ок, пусть будет так.
И по поводу многоязычности, на моноязычном сайте так же возможны появления других языков со своей спецификой, не часто, но бывает. Например в комментариях.

Что-то в кучу всё свалил, Денис) Без обид, но есть кодировка базы данных (Сharset) и есть сопоставление в таблицах (Collation) — это не одно и тоже. И сегодня лучше не использовать по возможности utf8mb4_general_ci
Я могу конечно побыть занудой и всё расписать здесь в комментарии, но предлагаю для тех, кому реально нужно разобраться в этом вопросе, прочитать вот эту статью, читается вполне сносно даже с гугл-автопереводом на русский

Очередной крик души)
Мне знакома твоя ситуация, я сам был в ней 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, целью которого как раз являются такие вот сложные, многослойные проекты, вот собственно его я и выбрал и подробно в нем копаюсь последний год, пока впечатления только положительные.

Пока только к Laravel, полет отличный. Не думаю что с MODX будут проблемы

В поисках оптимального для простых и средних сайтов поискового движка я наткнулся на очень молодой и интересный проект — github.com/loupe-php/loupe
Для жизни ему нужно очень мало по сравнению с аналогами, а вот вопросы поиска, сортировки и фильтрации он решает довольно неплохо. Опять же с пониманием максимального на данный момент количества индексируемых документов (около 32 000 штук). Чего для большинства будет с головой.

ZoomX, modHelpers, controlErrorLog

К сожалению директива map работает только в контексте http, поэтому её использовать на modhost.pro не получится.
Но можно попробовать другой вариант, правда более медленный, но если получится напишите сюда. Я честно его не пробовал, просто первое, что в голову пришло, но теоретически развить этот вариант можно попробовать

http {
    server {
        listen 80;
        
        location / {
            if ($http_accept ~* "text/html") {
                # Do something if the Accept header contains "text/html"
            }
        }
    }
}

Можно позаимствовать реализацию у онлайнтрейда — www.onlinetrade.ru/basket.html,
очень удобно создаешь сколько угодно тебе корзин, называешь их как тебе надо, типа — присмотрел к др, подраки на нг, ит.д
Лежат себе и кушать не просят, актуализируются автоматически.
Если сделать грамотно, очень удобно будет. Корзины хранятся в бд, доступны менеджерам из админки, в любой момент могут их посмотреть, помочь клиенту дособрать, или оформить любую из корзин.

У клиента была УТ 10, перешли на 11, компонент работает норм, но рекомендовал бы обновиться до свежей версии, она хоть и не без багов, но жить можно, а если руки «прямые» то и баги можно пофиксить. В общем на последней УТ 11 полет нормальный

Не обещаю очень большую активность, но точно помогу с тестированием

Что мне для этого нужно сделать?

Круто, могу помочь протестить

Для большей универсальности я бы ещё вынес всю работу по изменению html из метода status (js класс корзины)
в какой-нибудь отдельный метот, типа — applyHTMLChanges или лучше renderCart, так метод status будет чистым — отвечать только за получение данных актуальной корзины.

Сегодня был в работе магазин, в котором корзина и оформление — разные страницы.
Есть несколько компонентов, которые так или иначе пересчитывают корзину, ну и само собой все товары в ней.
Так вот в каждом таком компоненте авторы, в своем js, кто как реализует обновление данных корзины в html:
1) Кто-то циклом проходит и меняет в товарах цену и старую цену, а также результирующий блок
2) Кто-то целиком меняет весь кусок html кода корзины

Если в коробке miniShop2 будет универсальный метод получения актуальной корзины и обновляющий соответственно html на странице корзины, тогда в любом компоненте можно просто будет вызвать что-то типа

/**здесь любая логика по расчетам и.т.д*/
/**а в конце*/
miniShop2.Cart.status()

И всё сразу обновилось на странице на актуальные цифры.

Если понадобится что-то кастомное делать в чанке корзины, то поправить нужно будет только коробочный класс корзины (имею ввиду не исходники, а доработанную копию). То есть изменить только в одном месте.
Не придется лезть во все js других компонентов и везде менять реализацию обновления данных корзины.

Ну и ещё на ум пришел пример, если корзину делать на условном React, Vue, любом реактивном фреймворке, то как-то нужно получать стейт корзины из js, чтобы вьюха по стейту всё обновляла на странице.

Изучаю новый комплект js, и такой момент вижу

Мне одному кажется, что метод должен называться — sendRequest? Так как шлем «запрос» на сервер.
Или я тут что-то не улавливаю до конца?
Ещё момент, очень не хватает со стороны js метода запроса получения актуального состояния корзины,
чтобы прямо из консоли можно было вызвать так — miniShop2.Cart.status(); Без параметра, метод возвращал бы актуальную корзину, а с параметром как обычно отрабатывал. По аналогии как сейчас работает miniShop2.Order.getcost();

Прикольный компонент получился, хорошая альтернатива ContentBlocks от modmore.com
Единственное, что сразу бросилось в глаза, это при создании коллекции и выводе её в шаблоне через сниппет получается следующее неудобство:
Если в коллекции один элемент — возвращается объект
Если в коллекции более одного элемента возвращается массив
Если уж это коллекция то по идее должен всегда возвращаться массив, иначе нужно делать дополнительные проверки в шаблонах на то, что там вернул сниппет, массив или объект.

Это кстати уже не первый такой пакет в modstore, есть — eShopLogistic с таким же принципом.
Честно говоря такая практика не очень мне лично нравится, но хорошо, что хоть какие-то решения ещё появляются для MODX

Да с этой статьей уже знаком, и там в первом абзаце пишут, что EAV это про универсальность, а нам по сути это и нужно, угадать какая точно архитектура будет нужна конкретному магазину нереально, EAV как коробочное решение будет решать задачу универсально, пусть и не самым эффективным образом. А если продумать и заложить возможность полной замены реализации хранения и привязки опций — это даст ещё больше удобства, просто берешь отключаешь коробочное решение, и включаешь своё — но сомневаюсь, что многие этим будут пользоваться, моя статистика показывает, что там где уже есть EAV — мало кто пытается заменить на более производительное решение, так как хватает с головой коробочного. Но если речь про многомиллионные ассортименты и просто нереальное количество опций — то я думаю тут просто не падет выбор на MODX, как на платформу в целом.

Здорово, что ребята находят силы и время развивать продукт, спасибо им за это! Но чтобы компоненту хоть немного приблизиться к профильным решениям на рынке Ecommerce, его реально надо ставить на коммерческие рельсы и открывать обсуждение функционала в широкие массы, как и сбор средств на его развитие. Чтобы я хотел видеть в ecommerce решении для MODX из коробки:

1)Хоть какой-никакой адекватный функционал управления заказами из админки, я имею ввиду, возможность создавать заказы, печатать документы по ним, адекватный пересчет всех параметров заказа (состав, доставка, оплата, скидки), также нужен минимальный функционал выйти на связь с клиентом, хотя бы через отправку E-mail. Сегодня чтобы это реализовать нужно поставить минимум 6 дополнений, которые сломают интерфейс окна заказа, так как каждое добавляет свои поля и настройки в extjs как попало, потому что нет регламента расширения интерфейса окна заказа. Приходится лезть в исходники extjs этих компонентов и переписывать их.

2)Заложенная в коробку и продуманная система скидок/подарков/бонусов — это ключевой блок, на котором разработчики смогут зарабатывать на своих дополнениях. То, что сейчас есть, куча дополнений, где каждое считает несогласованно с другими — это проблема плохой архитектуры. Один компонент переписывает напрямую сессию, второй пытается через методы пересчитывать, в итоге один перебивает расчеты другого — полная вакханалия. Нужен четкий интерфейс для дополнений, чтобы их можно было выстраивать в логические цепочки для конечного расчета заказа. Кому-то нужно сначала применить промокод, а потом скидку от суммы, а кому-то наоборот, это должно решаться простейшим изменением порядка срабатывания и желательно не завязанного на приоритет плагина компонента. Где-то видел, уже не помню на какой платформе, решение — раздел скидок сделан в виде цепочки, куда можно перетягиванием добавлять узлы (компоненты скидок, промокодов, бонусов) — и прям мышкой можно настроить их порядок срабатывания и другие условия совместной работы, типа установка пороговой суммы при которой следующий узел будет активным. Это самое удобное решение из всех, что я видел)

3)Сосредоточиться на API, если будет полное покрытие функционала на API, это даст просто нереальную свободу, будут писать и собственные админки для менеджеров в виде пакетов на всяких Vue.js и React.js и дополнения смогут использовать всю мощь API, вместо того, чтобы придумывать свои велосипеды. Я считаю, что если магазином можно будет пользоваться на полную, просто сидя в том же Postman и посылая запросы — это будет победа и залог на хорошие перспективы развития. Не сделать это на старте — будет ситуация как с текущим miniShop2, тонны дополнений, где часть ломает работу магазина, из-за того, что не поспевают за обновлениями базы, и часть, где царит велосипедостроительство, так как нет API и четких интерфейсов. Как итог, с последней версией miniShop2 адекватно работают, на моей практике из всего modstore, ну компонентов 10-15, и то если их допилить.

4)По поводу опций товаров — я надеюсь, что ребята используют EAV для архитектуры, так как это самое популярное решение сейчас во всех топовых Ecommerce продуктах. Ну и да систему фильтрации хорошо бы тоже иметь из коробки, это неотъемлемая часть любого интернет-магазина, странно было бы видеть этот функционал отдельным компонентом вне коробки, хотя чего удивляться, сейчас он вообще в компоненте поиска по сайту запилен (mSearch2)

5)По поводу финансирования разработки — однозначно нужно завести всякие «бусти» для донатов, но чтобы деньги пошли, нужна мотивация, а для этого нужно что-то показывать, прогресс, демо, видосы, больше деталей, классная дока. Всё это в сумме может дать необходимую мотивацию поддерживать проект, а редкие посты в сообществе о том, что ну процесс идет, нужны деньги — так себе мотивирует) Без обид. Я сам готов поддерживать проект и финансово и идеями, так как у меня довольно много интернет-магазинов в разработке и на поддержке, правда всё меньше на MODX, но хочется верить, что ситуация исправится. Готов поддерживать при условии, что буду видеть прогресс и развитие.

Верно это не логгер ошибок, а как Вы написали красивый var_dump, для логирования ошибок в MODX хорошо бы прикрутить другой проект, так же от Spatie — называется ignition, он также с недавних пор framework agnostic, используется в Laravel по умолчанию.
Текущая версия buggregator поддерживает только локальную разработку, ну или если есть возможность поднять докер на сервере. А вот официальное приложение от Spatie позволяет добавлять и подключать сервера по SSH, но оно платное. Так что всё в руках разработчика, любые задачи решаемы)