51 минута назад
Заранее прошу прощение за занудство, но по semver если в релизе фигурирует слово «Добавлено» — то это автоматически минорный релиз (меняем вторую цифр...
Gallery3x 3.0.31 для MODX3 - управление файлами 1
8 часов назад
Всем привет!
Версия модуля 1.4.0
Необходимо обновить наименования товаров.
Выбираем Тип импорта — Обновить данные товаров
Соответствие Столбца Наз...
msImportExport 919
Вчера в 21:26
Настройками нельзя, только написанием своего плагина, который будет проверять необходимые условия. Если сами не справитесь, могу написать его за отдел...
Вопрос по msProductDiscounts 4
25 февраля 2026, 17:49
Добавлен также генератор разнообразных типов опций товара в разном количестве для разных наборов и их заполнение у товаров.
ms3DemoData - компонент для быстрой генерации демо-данных MiniShop3 3
25 февраля 2026, 15:21
Сложно сказать. Впервые про такую проблему слышу. Вы можете написать мне в телеграм доступы — вместе посмотрим
MiniShop3 1.2.0 - 1.3.0 Самое интересное 19
24 февраля 2026, 18:29
это сделал ИИ.
Я взял код из файла /core/components/minishop2/model/minishop2/minishop2.class.php
я скопировал этот метод function getReceiverId(), ...
Кастомизация minishop'a (номер телефона вместо емейла у пользователя при совершении заказа) 13
24 февраля 2026, 13:05
Привет!
Сегодня выложим — была проблема с защитой и ключами + был занят работой над minishop3 и PR к MODX github.com/modxcms/revolution/pulls/Iboch...
ms3RecentlyViewed - Недавно просмотренные товары для MiniShop3 4
23 февраля 2026, 03:33
Вот так отображаются поля довольно красиво! Нужно создать поля: allowed_resources, date_start, date_end в базе данных в таблице modx_user_attributes. ...
Дополнительные поля профиля юзера (не extended) 138
22 февраля 2026, 19:58
Кто реально внедрил MODX с Vue. js — каков опыт?Опыт — реактивные переменные благословение и проклятие Vue. С ними можно делать почти мнгновенно реаги...
Вопрос по будущему MODX и стратегии развития. 4
Всего 125 681 комментарий
Короче говоря последнее, что я хочу (и могу) делать на этом этапе, это снова заниматься программированием — разбирать данные из массивов, сверяться с документацией по бекенд-технологиями (таким как PageBlocks, искать там кастомные модификаторы) — мне хватает того, что для простых преобразования в стиле (:lowercase или :ellipsis) у меня открыта документация по фильтрам вывода (в плюс к тому набору выше).
Поэтому использование в вызове чанка специализированный модификатор (:pbJson) — это прекрасно, что такая возможность в принципе есть, но пока не освоишь инструмент очень глубоко (и не забудешь через год, когда на поддержке вернешься к проекту и надо будет добавить присоединение какой-то таблицы) про это в нужный момент не вспомнишь и встрянешь — это совсем не то же самое, что в сниппет pbResources передать нужные параметры для полноценной подготовки данных для их последующей верстки и оформления. Потому что при любом раскладе, когда работаешь с данными, ты пойдешь в документацию (или код) сниппета и посмотришь возможные параметры, отвечающие за подготовку данных и раскладывание по чанкам. Так почему бы не дать возможность избавиться от программирования в чанке и как альтернативу перенести вызов этого модификатора в подхватывающиеся по шаблону (префиксу) параметры вызова сниппета — тогда вся подготовка данных будет происходить в одном месте (вызове сниппета), а всё оформление — в другом (в чанках). Аналогично тому, как например в mFilter2 можно указывать кастомные чанки row и outer для любых полей, просто добавляя их в параметры вызова прямо по именам, задаваемых в этом же вызове — это почти также красиво и понятно в коде, как твоё @Aleksandr Huz описание содержимого табов в PageBlocks))
А тот момент, что у одной задачи есть несколько вариантов решений, как раз и делает инструмент по-настоящему гибким!
Ну хоть что-то, хоть это и немного не то ;)
Попробую пояснить: Когда я занимаюсь интеграцией макетов с админкой, я включаю «режим разработчика» — открываю документацию (или справку/код других проектов), хожу по шаблонам и расставляю вызовы сниппетов, где в этот момент я полностью работаю с данными — их выводом, преобразованием, разбором массивов и прочим, и раскладываю данные по чанкам. Может даже где-то пишу свои модификаторы вывода для сложных случаев. В этот момент я почти не смотрю на фронтенд, меня мало интересует верстка и стили, главное вытащить нужные данные
из админки(из БД, конечно).Далее, я иду в чанки, и там уже добавляю к данным оформление. В этот момент я «включаю режим
фронтендераверстальщика»: меня в большей тепени беспокоит как выглядят данные, какие отступы, сходится ли с макетами, у меня открыта совсем другая документация (MDN, возможно SASS, дока к моему фронтенд-фреймворку, возможно к каким-тоКогда кнопок мало (одна, две) надписи в центре смотрятся гармонично, а когда много, ищешь глазами название, а они все начинаются на разной вертикальной оси — когнитивная нагрузка возрастает, поиск усложняется и замедляется.
@Aleksandr Huz рассмотри плиз возможность сделать выравнивание надписей!
P.S. Я такое уже встречал, когда занимался пакетом Formalicious — видимо в дизайне админки MODX никто не планировал много кнопок)) На скриншоте в той заметке тоже некрасиво, я позже исправлял…
Уже отправил. Обычно это быстро.
Вместо этого:
можно написать так, если сильно хочется:
Но, чтобы вместо инлайнового чанка использовать реальный нужно доработать сниппет. Сделаю
Чтобы было примерно так:
и в чанке list_item_tpl дополнительно будет доступно {$_idx}, {$_total}, {$_first} и {$_last}
Спасибо за оперативность! Правда парни из modx.com наверное не сразу пакет опубликуют?)
Совершенно верно
Исправлять ошибки тоже нужно.
Нет, просто обновляешь поверх нее — и все. Первая версия сильно ограничена в возможностях, но все равно полезна для легких сайтов, например, для лендинга.
Имя чанка должно автоматически измениться для всех сопутствующих блоков, поэтому это ошибка в бесплатной версии. Исправлю сегодня.
Я сейчас начал работу с бесплатной, если пойму, что её возможностей мало — на 2-ю версию будет трудно уйти?
И еще есть небольшой вопрос: 1) создал блок, указал имя чанка, 2) добавил этот блок к ресурсам, заполнил контентом, 3) переименовал чанк у блока, 4) у ресурса осталось старое имя чанка, всё сломалось, поменять его нельзя?
Из пожеланий, всё-таки не терять MODX-style и дать возможность использовать систему чанков полноценно, не прибегая в foreach циклам в коде шаблонизатора.
Думаю это выглядело бы примерно так:
Зачем это нужно?
Кроме избавления от циклов в коде для лаконичности и сохранения удобного MODX-стиля раздельного оформления повторяющихся элементов, который и так изрядно потреплен частым злоупотреблением гибкостью fenom-а) — ну, как минимум, дополнительно можно получить более глубокое кэширование и переиспользовать чанки где-то ещё в проекте.
А ещё там внутри чанка можно сделать доступным {$idx} и {$total} (его, возможно, и снаружи, с префиксом типа list_total или как-то так) чтобы не городить их опять же в коде чанка, который для разметк (aka верстки) предназначен, а не для логики.
Это конечно не правка бизнес-логики компонента, а больше к Developer Expierence, но вроде всё так красиво реализовано для разработчиков (уже), что такая вишенка на торт возможно придется кому-то (вроде меня :) ) очень кстати!
Классно, теперь могу поставить клиентам. Мне больше нравится темная тема, но клиентам некоторым привычнее работать в светлой. Удобно что можно будет переключаться. Простая вещь, а как удобно.
два знаю
intellect money
pay any way