5 минут назад
И ещё такие ошибки:
[2026-06-20 23:58:37] (ERROR @ /var/www/.../data/www/.../core/cache/includes/elements/modplugin/12.include.cache.php : ...
Странный баг в SendIt (квиз+загрузка файлов) 4
6 часов назад
Только что столкнулся с таким на 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
15 июня 2026, 14:59
Обновил компонент
1.1.0-pl
— добавлена прямая интеграция с официальным MAX Business API;
— добавлен выбор провайдера между MAX Business и ruma...
MaxNotify 1
11 июня 2026, 21:58
Позже, может размещу и на docs.modx.pro, пока времени нет
IskWaf 3.2.0 — большое обновление WAF для MODX 3 2
Всего 125 966 комментариев
Конечно, для пользователя ваше решение намного привлекательней. =)
Помимо этого, разработчик может сначала придумать дополнение A, повторяющее функционал уже имеющего на 30%, а затем дополнение B, повторяющее функционал другого компонента на 60%. В таком случае ему придется с каждым дополнением бежать в поддержку и объяснять на пальцах, в чем он повторяет, а в чем нет.
Это неудобно.
Допускаю, что это мое субъективное мнение, но лично я бы этим заниматься не стал.
Этот список касается на 99% только оформления, кода и вот этого всего, а про пересекающийся функционал там только 1 строчка, которая не вносит никакой ясности.
В общем, мой посыл в том, что было бы хорошо раскрыть этот пункт и внести больше ясности, которая позволила разработчикам меньше ломать голову и больше заниматься разработкой, а не бюрократией и переписками с техподдержкой.
Сейчас есть список требований к дополнению и пограничные случаи обсуждаются на модерации. То есть описанный вами процесс уже есть.
Достаточно сравнить этот вариант с каким-нибудь конкретным списком из N пунктов, где ясно и четко прописано, в каком случае дополнение будет отклонено.
Понятное дело, что все равно будут пограничные спорные случаи, которые придется рассматривать на этапе модерации, но сейчас ясности, на мой взгляд, мало — вопрос выше остался без ответа именно по этой причине.
На мой взгляд, политика в отношении подобных вещей должна быть кристально ясной и четкой, как два пальца, а не «мы рассматриваем каждое дополнение индивидуально».
Поставьте себя на место разработчика, который хочет написать новое дополнение, но оно пересекается с уже существующим по функциональности. Ему что, идти в поддержку и рассказывать о своих еще не реализованных идеях? Политика должна такие вещи однозначно предусматривать заранее, чтобы разработчик уже знал на 100%, пройдет его дополнение или нет.
Иначе зачем ему вообще тратить свое время, если его дополнение может пройти, а может и не пройти? Это же не лотерея какая-то, а магазин дополнений, у которого, еще раз повторюсь, должны быть однозначные, четкие и понятные правила.
Можно скопировать весь код
Доработать
И выложить
Это же open source
наверное условия можно переписать короче, но во первых так нагляднее, а во вторых — я ненавижу тернарный оператор)
Если 0 = нет в наличии, иначе n шт.
2. Там не очень много вакансий. Это корпоративный сайт одной компании. Вакансий 10 будет. И форма вызывается не по кнопке, а просто стоит в тексте. Но я согласен. Если форм много, то лучше что-то придумать без сотен вызовов форм.