можно так

{
"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, если не найдётся тот, кто разжуёт всё для малообразованных вроде меня, будет сложно разобраться.

Первым делом я написал mmxDatabase, который добавляет возможность работы с основными таблицами MODX через Eloquent. Про это уже давно и много где говорили, но дальше примеров «смотрите как можно» дело до сих пор не зашло.

Хз, Вась ) А зачем тебе тогда modx?
И зачем этот пакет? Просто заменить один синтаксис другим?
Если тейк про скорость, то это не элокенту

Пока не могу проверить ни то, ни другое. Доберусь только завтра. Сайт вообще отключён уже, а спам идёт дальше!

По словам автора FetchIt использует тот же бэк, что AjaxForm, поэтому вряд ли переход на него спасёт от спама. А вот SendIt может помочь.

Они шлют прямыми запросами на assets/components/ajaxform/action.php.
Сделайте сниппет chkbot:

<?php
$_SESSION['afchk'] = 1;
return true;

Добавьте его в &preHooks:

[[!AjaxForm?
&preHooks=`chkbot`
&hooks=`spam,email`
...
]]

А в файле assets/components/ajaxform/action.php на 23 строке добавьте:

if($_SESSION['afchk'] != 1){
    echo  $AjaxForm->success('Сообщение успешно отправлено.');
    die();
}
unset($_SESSION['afchk']);

Блин. Насчет того, что точно не буду использовать vesp/core 4 кажется погорячился. Проблема в том, что ресурсов на собственный аналог не хватает :-(. Чтоб предложить более менее полноценное приложение надо потратить много времени… В принципе можно было бы перейти на vesp, но главная проблема отсутствие модульности. У нас сайт с, условно, сотней модулей. Пересоберать весь сайт при изменении одного модуля или добавлении нового желания нет.
У меня, при использовании gtsAPI, на странице вызывается сниппет, который подгружает однофайловый модуль на vue. Который весит пару килобайт. Соберается за секунды и никак не влияет на другие модули. Нужно, чтоб модуль можно было отдельно редактировать и соберать. Чтоб модуль отдельно подгружался при использовании на странице и чтоб при загрузке какой-либо страницы не загружались все сто модулей.
Пример модуля ExcelCalc

Нда… вот бы была такая система год назад… Сейчас уже активно пишу на более простом самописном аналоге с primeVue. Все проще и PSR-7 не поддерживает, но зато все мне понятно. Так что для меня врядли пригодиться. Хотелось бы современный и понятный стандарт, чтоб не плодить кучу разнообразных систем в которых ногу сломишь, но по моему новинки в программировании редко взлетают. С минишопом у Вас повезло. Ко времени пришелся. А vesp/core 4 может и не взлететь. Разве что на авторитете подымется. Думаю 3 проблемы помешают.
1 это не простой порог входа. Подробной документации еще нет, но система кажется не простой.
2. MODX с системой сниппетов и чанков довольно простой конструктор сайтов. Многие не знают php и пишут на MODX сайты. А с vesp/core уже так не получиться.
3. У vesp нет компонентов и модулей, чтоб не писать нужный функионал с 0, а как, например, установил минишоп и просто под свой сайт подстроил.

Ну это я так вижу :-). Может у кого-то другие впечатления…