5 часов назад
Возвращался к этому вопросу, чтобы не грузить ничего заранее, делаем просто встраивание iframe после нажатия на div и вместо него встраиваем iframe. Н...
Вставка видео с Rutube с управлением на сайте 6
Вчера в 20:23
Вариант 1
Переопределить метод msOrderHandler::submit() таким образом, чтобы там перед установлением статуса «Новый» проверялся способ оплаты и, если...
[miniShop2] Дополнительная логика отправки писем при оформлении заказа 1
Вчера в 11:23
Вот давно для себя писал: modx.pro/solutions/18489
или через мускул (перед выполнением обязательно сделайте дамп) напрямую + потом кеш почистить
U...
Автопереименование повторяющегося URL 9
Вчера в 11:10
Надо глянуть структуру XML что именно поменялось, если что пишите в ЛС могу посмотреть.
mSync - проблема с интеграцией с 1С Предприятие 8.5 1
Вчера в 11:06
Используй phpThumbOn он как раз в префиксе указывает размер изображения.
Ссылка: modstore.pro/packages/photos-and-files/phpthumbon
имена файлов миниатюр картинок 1
14 января 2026, 15:11
Да особо без разницы куда писать. Я отслеживаю все записи. Но в идеале создавать issue в репозитории github.com/modx-pro/MiniShop3/issues.
MiniShop3 - 1.1.0 - Уже в Modstore.pro 19
14 января 2026, 10:31
Будет еще лучше. mFilter на подходе!
mSearch для MODX3 и MS3 - уже в modstore.pro 7
12 января 2026, 08:59
Ни где не могу найти информацию по настройке импорта изображений «Обновлять данные существующих изображений» — не понять, на что влияет данная настрой...
msImportExport 2.0 127
11 января 2026, 13:08
нет переводов primeVue. То есть если использовать фильтры DataTable или Calendar, то они будут англискими.Вот про это я не подумал. Думаю учтем в буду...
VueTools - универсальный компонент оформления админки в MODX 3 4
08 января 2026, 12:31
Большие сомнения у меня в этом)
resComments — многоуровневые комментарии с пагинацией для ресурсов MODX3 3
Есть проблема — при установке fileMan с Collections при создании ресурса в коллекции получаю такую ошибку:
После удаления fileMan — ошибка исчезает.
Вы делаете классное дополнение. Хочется, чтобы оно получило признание и популярность в сообществе. А для этого нужен интерфейс. Потому что большинство в сообществе MODx не умеют в конфиги, код и т.д. И это не плохо. MODx поэтому обрел популярность. Сейчас наблюдаю тенденцию к уходу от этой концепции. И это не способствует популяризации MODx.
Ваш компонент SendIt хорош. Но он хорош для программистов. А это 5% пользователей MODx.
Вне зависимости от сценария распространения вашего компонента (платный или бесплатный) — если хотите массового принятия и внедрения для своего продукта, то нужен понятный и доступный простому пользователю графический интерфейс.
ИМХО. На истинность не претендую.
Учиться ничего не мешает. Более того, искренне считаю, что учиться — всегда нужно. Так уж получилось, что у меня другая сфера деятельности и компетенций. В этой сфере я и стараюсь всячески развиваться и учиться. :)
Такие скрипты заметно снижают скорость первичной загрузки.
Вы идёте путём, который отсекает 70-80% сообщества. Раньше, человек далёкий от программирования, мог поставить минишоп2, немного подверстать галерею и оно работало. Уже можно было продавать вязаные игрушки или куличи. Теперь такие потенциальные пользователи уйдут на другие CMS.
Дайте возможность отключить не нужную галлерею. Не нужно её выпиливать. А те, кому нужна своя — пусть отключат встроенную галерею в системных настройках или в настройках минишопа. Это уже не сложно продумать.
Есть несколько «сложных проектов» (структурно и функционально) собранных без написания сниппетов и без знания программирования. Использовали только готовые компоненты из modstore.
В остальном — полностью согласен.
Не воспринимайте как критику. Просто мысли вслух. Автору дополнения — искреннее уважение.
ZoomX — штука, безусловно, интересная :)
Но, на мой взгляд, уводит MODx от концепции более-менее простой и универсальной CMF к сложному «недофреймворку». Вместо того, чтобы менять сам MODx и делать его более быстрым, удобным и понятным большинству, я вижу тенденцию к уходу в доработку надстройками. Такие надстройки (так как их делают программисты для себя и других программистов) делают MODx более сложным.
Уникальность MODx как раз в простой и удобной админке, в простом создании ресурсов, отображении их в виде понятного дерева с понятным редактированием этих ресурсов из админки. Доступ к шаблону из самого ресурса. Система сама заботится о создании ссылок, их формировании и т.д. Простые дополнения, позволяют вывести меню, ресурсы, добавить форму, создать простой магазин и проч. Все это просто понять и применять новичкам.
С приходом таких дополнений, как ZoomX, нужно прописывать роуты, а создание ресурса превращается в написание кода. Это вряд ли привлечёт большое количество новичков в MODx (именно эта категория пользователей даёт популярность таким проектам, как Wordpress).
Если же есть задача привлечения опытных программистов — всё ещё не понятно, зачем пользоваться этим в связке с MODx, а не Laravel, Flask и другими адекватными «тру» фреймворками, в которых всё для опытного разработчика уже есть из коробки.
В любом случае — автор молодец, что посвящает этому время.
Самая главная беда — мы видим ошибки в общем логе MODx, но не знаем на какой странице сайта они вылезли. :) Поэтому, чаще всего, выявление ошибок происходит с помощью визуального осмотра сайта. Мы включаем дебаг и ползаем по страницам в поисках этой ошибки.
Приведу один из примеров: есть сложная страница с несколькими «вкладками». Вкладки не разбиты на отдельные страницы, а свёрстаны как вкладки с помощью css-фреймворка. На каждую вкладку выводятся ресурсы с помощью pdoPage со своими отборами для каждой вкладки.
Например, мы видим что страница «поехала» — что-то отображается не правильно.
Как это работало в предыдущих версиях — мы видим дебаг под каждым сниппетом и понимаем, какой из них отрабатывает с ошибкой. Например, я добавил showLog=1 для всех сниппетов и на каждой вкладке (или под каждым местом, где должен быть вывод сниппета) вижу свой дебаг. Сразу понимаю, какой из сниппетов отработал неправильно.
Когда мы можем вывести дебаг только в одном месте — сразу не понятно что и где «сломалось». Ошибка уже не привязана к вызову сниппета в вёрстке сайта и это не всегда удобно.
Возможно, я ошибаюсь и все привыкли действовать по-другому. Можно добавить возможность указать плейсхолдер для вывода дебага, а если он не указан — выводить единым плейсхолдером. Если через пару версий выяснится, что этим никто не пользуется — значит я был не прав и эту возможность можно будет исключить.
Еще раз спасибо, что откликнулись на предложение с позитивом.
Небольшое пожелание.
Если есть такая возможность — сделайте вариативным плейсхолдер для лога. На многих проектах на одной странице может быть, например, несколько pdoMenu. Как я понимаю, в таком варианте все логи сольются в единую портянку и это будет крайне не удобно. Добавьте возможность указать имя плейсхолдера, в который будем выгружать лог.
Заранее благодарен.