23 минуты назад
Нет. Сейчас категории и товары создаются напрямую через xPDO-модели:
— категории: newObject(msCategory::class) → save();
— товары: newObject(msPro...
CommerceBridge 1C — двусторонняя интеграция 1С с MODX 3 и miniShop3 по CommerceML 2. 2
Вчера в 17:54
Только что столкнулся с таким на modx3, ранее 1 раз видел на modx 2.8 — не было времени и мотивации разбираться.
Но проблема есть и она старая.
Кл...
Не срабатывают статичные плагины 1
19 июня 2026, 23:14
Обновление компонента
История изменений MaxNotify 3
1.2.0-pl
добавлен канал max в Центр уведомлений miniShop3;добавлена отправка из Центра дл...
MaxNotify3 3
19 июня 2026, 21:05
Копать надо в браузере. На вкладке сеть, если ответ 500, тогда в логи сервера.
Зависает корзина минишоп2 1
16 июня 2026, 15:00
Последний FormIt + последний FetchIt = белый экран
Последний pdoTools + последний MODx v3 = белый экран
FormIt 5.2: нативный AJAX и reCAPTCHA v3 5
15 июня 2026, 19:12
Благодарю) сижу ломаю голову, все сайты положил
Не получается установить PdoTools 6
Всего 125 971 комментарий
1. Помни, это может поменяться, обращай внимания на обновления FetchIt
2. Пиши так:
Но проблема в том, что конфиг генерируется во время рендера страницы. Так уж задумано. Я подумаю как можно облегчить такие задачи в будущем
Установил 3.0.3 поверх 2.8.5, админка перестала работать сразу. Просто ни одна кнопка не работает и всё. В консоли — куча ошибок.
После выполнения трюка с заменой Om часть русских букв появилась, остальное — так же нечитаемо. Админка осталась мёртвой.
Я согласен, что это не самое удобное решение, но вынужден повторить — в моей практике нечасто встречаются кейсы требующие манипулировать значениями перед отправкой, поэтому я и не добавил дополнительных событий.
Нет, лозунг был другой: одна отключаемая зависимость лучше двух обязательных.
Потому что счёл его риторическим, логично же что никаких работ по усовершенствованию не ведётся, разработан новый API и его развивают.
Ты меня за идиота принимаешь? Я решаю возникающие у меня задачи, удобным для меня способом. Мне нужно показывать процесс загрузки, Fetch API этого не умеет, я использовал XMLHttpRequest. По-моему всё логично.
Мне кажется ты упускаешь суть: ты писал компонент с целью внедрения Fetch API, я писал компонент с целью повысить удобство собственной работы и отказаться от использования jQuery. Не вижу причин по которым я обязан был использовать Fetch вместо XMLHttpRequest. Для пользователя компонента это вообще не важно, что там под капотом, главное это стабильное выполнение необходимых ему функций.
И наконец, всё что ты перечислил в качестве проблем AjaxFormitLogin, всего лишь твоё скромное мнение, о чем ты забыл упомянуть, отчего кому-то может показаться, что перечисленные тобой «проблемы» действительно серьезно могу усложнить жизнь пользователю моего компонента. Я думаю тот, кому понадобится больше событий и API, легко поймёт, что всё это есть в FetchIt, и выберет именно его.
Хорошо, ты не смог придумать, а я представь — смог. Тык, тык и тык.
Прости, но мне придётся поязвить — ты же обязательно покажешь как расширить класс? Т.е. для простой задачи добавить и/или изменить значение в форму перед её отправкой, нужно манипулировать с DOM или расширить класс? Прикольно.
Я уже понял. Именно с этим лозунгом ты сменил jquery-form на XMLHttpRequest
Ты проигнорировал вопрос про асинхронность в XMLHttpRequest, но это приводит к более веселой ситуации: А когда в XMLHttpRequest появится (спойлер — не появится, но есть библиотеки-обёртки над ним в которых реализована асинхронность) ты обратно перепишешь с Fetch API на XMLHttpRequest?