Василий Наумкин

Каким образом можно будет избежать конфликтов

Composer просто не позволит установить конфликтое приложение, и ничего не сломается.

Нужно будет поискать более подходящее приложение, или попросить автора адаптировать своё. Например, указать другие возможные версии зависимостей, как уже сделал я с vesp/core, для нормальной работы в MODX 3.

Скорее, это что-то с настройкой веб-сервера, потому что на modhost.pro дружественные url включать не нужно.

Главное, чтобы любой запрос попадал на index.php, а там уже сработает плагин.

Все запросы в приложение перехватываются плагином на onHandleRequest, дальше проверяется адрес запроса и, если он начинается с /mmx-forms/, то передаётся контроллеру.

У тебя, судя по всему, или не работает плагин mmxForms, или запрос перехватывает раньше кто-то другой. Во всяком случае, текст ошибки не выглядит как обычная страница MODX.

Я только что проверил работу на modhost — всё отлично, проблем нет.


Попробуй и ты, я дополнил заметку инструкцией для этого хостинга.

1. Что делать, если зависимостей много и установка прервётся по таймауту? Это же web-запрос
2. Как отвечать на вопросы от Composer при разруливании зависимостей?

Но я, конечно, никому не могу помешать так делать.

Это тоже изврат, не надо такое поддерживать.

Мало того, что это сам по себе костыль, так еще и непонятно как зависимости через админку разруливать, в случае чего. А дальше надо опять как-то собирать траспортный пакет через MODX, грузить в репозитории, там еще что-то может поломаться…

Народ даже придумал консольный сборщик GPM, который работает по json схеме. Никому не нравится собирать транспортные пакеты, это издевательство.

Куда лучше потихоньку писать новые дополнения и переводить старые на установку из Composer. Будут хорошие дополнения использовать этот подход — будут и юзеры.

сторонние модели возможно добавлять в список поддерживаемых разработчику

Да конечно, как только mmxDatabase установлен в системе, можно писать свои модели, расширяющие класс Model из Eloquent.

Любой будущий пакет может просто указать у себя в зависимостях mmx/database, а так как у нас всё через Composer, то установлен он будет только один раз, неважно сколько пакетов его требуют.

использование компонента на фронте выливается примерно в 1,5 мб дополнительного css и js?

Это только если без gzip — а с ним 420 Кб.


Тоже многовато, но оно закэшируется и больше грузиться не будет. Для всех форм на всех страницах будет грузиться один и тот же комплект файлов.

такое уже есть в SendIt

У Vueform всё немного сложнее. Там грузятся временные файлы до отправки формы, а потом их можно удалить или заменить.

А это значит, что файлы нужно где-то временно хранить и отслеживать, были они отправлены или нет. То есть, сохранять их в БД, чистить неотправленное и всякое такое.

В логике mmxForms это новые таблицы, модели и связи. Sendit, насколько я вижу по исходникам, с БД вообще не работает.

Стоит еще добавить, что если сайт использует современнный CSS фреймворк, то он уже может поддерживать тёмный режим из коробки.

Например, вот как это работает в Bootstrap 5.3.

Если дело только в английском — то не парься, все всех поймут. В крайнем случае доставай телефон, переводи там и показывай, никаких проблем.

На мою самую первую встречу в Беларуси 2015 нанимали переводчицу, и с ней иностранные гости приехали в ресторан. Первые полчаса пытались общаться с её помощью, но это очень медленно и скучно, так что накатили немного и начали понимать друг друга напрямую.

Больше переводчиков на тусовкох не было, насколько я помню.

а у MODX как движка есть дорожная карта?

Неа, ничего нет и ждать не стоит. Всё будет примерно как сейчас. Собственно, ровно так же, как оно было и с Evolution.

Если нужно развитите — или переходи на другие системы, или развивай сам. Других вариантов, на мой взгляд, давно уже нет.

Я так понимаю, системе помогут твои полезные комментарии.

Неинтересно — проходи мимо, чего вонять-то.

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

Обычно всё главное происходит до и после официальной части. Презентации и доклады — это просто официальный повод встретиться и затусить.

Весь.

Только при работе из браузера запрос обычно обслуживает php-fpm с одним конфигом, в при запуске из консоли php-cli с другим.

MODX должен пытаться выставить правильную временную зону всё равно, но конфиг PHP может запрещать это делать.

ЕСЛИ убираю ms|price:number (т.е. фильтр цены), то время ответа примерно 3 секунды, что терпимо
НО с ms|price:number время ответа 50 секунд
как фильтр цены может так влиять на время ответа?

Очень просто.

В miniShop2 есть событие для изменения цены товара плагинами — msOnGetProductPrice. Если у вас установлены какие-то плагины, меняющие цены, то они срабатывают в момент подготовки фильтров. И генерируют вам дополнительные десятки тысяч запросов.

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

mFilter2 медленный по причине медленного устройства традиционных баз данных и языка PHP в принципе.

Вот уж не соглашусь — из базы он только выбирает данные, затем строит файловый индекс, и его фильтрует на PHP, пробегая по массивам. И, полагаю, делает это совсем неоптимально.

Сегодня есть гораздо более быстрый компонент k-samuel/faceted-search, который я опробовал на разных проектах, в том числе и с большим количеством данных — результаты отличные. Вопрос только в том, сможет ли кто-то, и захочет ли, прикрутить этот пакет к MODX.

Вот тут пример интеграции вместе с кодом, а вот тут можно потыкать результат вживую.

А с базой MODX работать придётся даже ElasticSearch, потому что именно в ней хранятся данные товаров, которые нужно фильтровать.

Классика — это не читать документацию.

Нужно было просто заменить [[+total]] на {{+total}}, тогда парсер MODX пропустит этот плейхолдер, а pdoTools обработает как надо.

P.S. @Иван Бочкарев В вашей версии документации в примере указаны неправильные теги — в моей старой версии всё верно.

Вот твой коммит, с изменением смысла примера.

На всякий случай, даже 8я версия PHP уже устарела и получает только обновления безопасности.

www.php.net/supported-versions.php

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

Вместо передачи токена корзины в заголовке, у меня указывается uuid корзины как часть адреса для запроса, типа /api/web/cart/fc30e4d7-ed56-40ec-9f6e-69f1fcd70582.

Оформление заказа так же происходит с указанием uuid корзины /api/web/orders/fc30e4d7-ed56-40ec-9f6e-69f1fcd70582, после чего заказ получает уже собственный uuid, а старая корзина удаляется.

Таким образом, авторизация вообще не нужна, заказ можно создавать и просматривать гостям — главное знать нужные uuid, которые не поддаются перебору.

Теперь становится возможно менять опции товара прямо в корзине, и если выбранный комплект опций совпадает с другим пунктом корзины, то комплекты просто суммируются.

А как эти товары потом разделить обратно, если соединил по ошибке? Разрешать делать что-то, без возможности отмены, мне кажется несовсем правильным.

1. pdoTools
2. Collections
3. Tagger
4. SimpleSearch
5. FormIt
6. SeoSuite
7. Formalicious
8. GoogleAnalytics
9. ModxDashboardWidgetsPack
10. QRNFCGenerator

Это те, что на вскидку вспомнил, потому что работал с ними недавно. Если покопаться, найдутся еще.

Таких пакетов уже довольно много, хоть бы и новый pdoTools. Видишь, здесь грузится свой собственный autoload.php, который может содержать любые зависимости?

Теперь представь, что так может делать любое дополнение в MODX 3. Кто-то будет тестировать свой пакет на совместимость со всеми остальными в репозитории? Очень сомневаюсь.

А значит, с каждым новым дополнением, с каждой новой версией, с каждым месяцем у тебя всё больше шанс словить проблему.

Это есть и во 2й версии, просто там этот шанс гораздо ниже, но отнюдь не нулевой.