50 минут назад
а, то есть, это влияет только на невозможность обновления компонента и отсутствие поддержки? а я думал если развернуть копию сайта с платным пакетом —...
Вопрос по платным пакетам на локальном/тестовом сайте 2
7 часов назад
Возможно это Time-Based Blind SQL Injection через параметры формы оформления заказа miniShop2.
Недавно тоже были проблемы с одним моим интернет-магаз...
136 входящих заказов с пустыми полями в форме и без товаров. Как такое возможно? 4
Вчера в 10:59
Если нет дата-атрибута, в скрипте не доходит даже до preventDefault, так что вроде должно всё нормально работать, но конечно, изменения большие, надо ...
FormIt 5.2: нативный AJAX и reCAPTCHA v3 3
27 мая 2026, 10:50
Спасибо за оперативный ответ!
Уже проверил и пофиксил, плюс скачал пакет с GitHub дополнительно
Кто-то одаренный на основном домене переключил вер...
YaSmartCaptcha - защитите ваши формы от спама умной капчей от Яндекс 37
22 мая 2026, 21:53
Разумно. Все поля подряд не хочу добавлять в чанк. Практика показывает, что полей очень много, содержимое может быть объемным и появление подсказок мо...
mSearch - обновление до версии 1.3.0. 2
22 мая 2026, 18:30
Это changelog разросся. Не помещается в базе данных mariaDB (mysql почему то съедает и не морщится) Выпустил Версию. 1.11.1 с решением этой проблемы.
MiniShop3 1.11.0 8
22 мая 2026, 09:51
Твой бот стримит всё что происходит в терминале? И умеет выполнять слэш команды для агентов типа /status /btw? А ещё нет ли проблемы разрастания входя...
[aiAssist] Я же просто попросил его создать магазин, а он СДЕЛАЛ ЭТО! 16
19 мая 2026, 04:04
Сделал новую версию с табами и возможностью запуска сразу для всех вариантов.
Сначала содержимое для технического ресурса откуда будет запускаться вы...
VersionX переполнил базу данных 8
Всего 125 932 комментария
Короче говоря последнее, что я хочу (и могу) делать на этом этапе, это снова заниматься программированием — разбирать данные из массивов, сверяться с документацией по бекенд-технологиями (таким как 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