Клиент сегодня озадачил. Пришлось побороть проблему.
Создаем веб приложение и прописываем в google консоле uri
ваш_сайт/manager/?a=home&namespace=googlesheets

А откуда SendIt получает ответ от минишопа (со ссылкой редиректа или номера заказа)? Я сделал так же только на ajaxform, и вот вопрос, как передать ответ минишопа в событие успешной отправки ajaxform?

$(document).on('af_complete', function (event, response) {
    if (response.success) {
        // Можно ли тут получить номер заказа или ссылку на оплату?
    }
});

Из статьи:

… если вы забудете правильно удалить зависимость, и сайт упадёт — никаких проблем, просто установите её обратно и удалите как положено.

Вы же всё равно это делаете из консоли сервера и нерабочая админка вам никак не помешает всё починить.

Зная разработчиков, могут и не заметить что сайт упал. Так что работа из админки даёт сайд-эффект пассивной проверки работоспособности)

Лучше всё-таки консоль использовать как fallback, а не как основной инструмент. ИМХО.

2. Как отвечать на вопросы от Composer при разруливании зависимостей?

А если помечтать, потенциально возможно прикрутить UI и всё-таки ставить пакеты из админки, ну бывает же Web UI для composer…?
(кстати сделано на твоём плюс-минус стеке? из slim и bootstrap)

Но после погружения в докер и прочие консоле-зависимые технологии, я уже замечал что сложно бывает объяснить как может быть, что при работе над сайтами люди никогда её не открывают). Но они есть (например я и те команды у кого я перенимал workflow, и кому передавал), как и есть те кто иногда меняет пару строчек кода в админке MODX минуя IDE (это не я)…

Но всё-таки знать, что полностью не вылезая из админки есть возможно работать — это очень хорошо, особенно для новичков.

Василий, велком бэк :) И спасибо за новости!

Способ установки дополнения — интересный, и видно что много пользы под капотом!

В рамках фидбека, озвучу пару моментов, которые настораживают

• Дружелюбность установщика в консоли — не удобно от слова совсем. Возможно для тех кто разрабатывает фреймворки, CMS, и модули к ним, такой метод ок, но для тех, кто собирает сайты и лендинги — очень не очень, и отпугивает новичков системы (потому что в WP и Битриксе консоль не нужна чтобы собрать сайт)

• Тащить на фронтенд 430Кб CSS и JS для форм (которые 1,7 мб не сжатые) во времена расцвета повсеместной погони за PageSpeed для UX и SEO — для меня прямо стоп-фактор. Это в 10 раз больше, чем тащим для полнофункциональных форм сейчас:

— менее 40 килобайт на весь зоопарк (тоже сжатое, не gzip правда, а brotli, но там разница в ~10%)

C этим для затаскивания в продакшен mmxForms надо что-то будет делать… Может для форм в личном кабинете подойдет и как сейчас, но для страниц, куда из поиска посетители приходят — в таком виде пока не вариант.

P.S. А конструктор Vueform интересный конечно, Formalicious попроще будет, класс!

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

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

можно так

{
"field": "image",
"caption": "Изображение пузыря",
"inputTVtype": "image",
"sourceFrom":"config",
"sources":"[{\"MIGX_id\":\"1\",\"context\":\"web\",\"sourceid\":\"5\"}]"
}

где 5 — это id источника

Там если транспортник будет выполнять

composer exec mmx-forms install

при установке

и

composer exec mmx-forms remove

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

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

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

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

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

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

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

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

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

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


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

Через AjaxForm без FetchIt происходит тоже самое, игнорирование измененного чанка письма, удаленных/измененных input, проверок на пустоту и тд. Прямая какая-то проброска идет через assets/components/ajaxform/action.php.

В соседней теме как раз из той же области походу.

Буду пробовать SendIt, на новых точно уже без AjaxForm.

Благодарю, добавил проверку сессии, только сразу

die('Сообщение успешно отправлено.');

до этого ставил редирект на главную (спам проскакивал пару раз). Сейчас уже 3 часа полет нормальный.

Насколько я понял (php со словарем:)) там изначально проверка только на то что есть запрос ajax или нет, который получается можно подделать?

Прямые запросы на assets/components/ajaxform/action.php в логах остались, количество сократилось.

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

Привет! Молодец, как всегда)
mmxDatabase понравился! Прям чешутся руки применить и попробовать, осталось найти где. По нему небольшой вопрос, сторонние модели возможно добавлять в список поддерживаемых разработчику? Например для miniShop3 (когда-то в будущем)?

И вопрос по mmxForms, верно понял, что использование компонента на фронте выливается примерно в 1,5 мб дополнительного css и js? Много, конечно, если речь про формы типа «Перезвоните мне»

Ну так можно реализовать установку из композер и завернуть это в транспортный пакет.
Пакет будет установлен с учетом всех зависимостей и тд. Пакет будет в данном случае как обертка. Не будет занимать много места, будет так же работать и откат и тд и все фишки пакета MODX.

до сих пор придерживаются транспортных пакетов?

Устоявшаяся экосистема, привычные механизмы, куча реализованных пакетов (а переписать все это нужно много времени)? Типа работает — не трогай))

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

Да это очень напрягает, когда на сайте сразу 3 версии Guzzle с разных дополнений и приходиться придумывать велосипед как заставить это работать.

Отличный пример!!! Применю обязательно.

ps. Что мне непонятно, так почему ребята которые задают курс MODX до сих пор придерживаются транспортных пакетов? Когда в ядре уже есть все необходимое для установки через композер…

2. Те, кто не знают php, могут и дальше по старинке работать.

Давно мечтал о подобных формах! Спасибо!

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

В SendIt всё это есть, только без БД. Файлы загружаются автоматически и удаляются автоматически при перезагрузке или закрытии страницы. Если отправлять не надо, то пишешь хук, который переместит файлы. В общем, я вдохновлялся AjaxForm и AjaxSnippet и получился универсальный компонент для отправки форм.

Вообще очень интересно получилось. Твои старые компоненты на фронте используют jQuery, а теперь ты врываешься с Vue, VanillaJS не зашёл тебе совсем?)))

Что касается твоих идей, мне они кажутся революционными для Modx, если не найдётся тот, кто разжуёт всё для малообразованных вроде меня, будет сложно разобраться.