26 минут назад
Не знал. попробую реализовать
16 июня 2026, 15:00
Последний FormIt + последний FetchIt = белый экран
Последний pdoTools + последний MODx v3 = белый экран
16 июня 2026, 10:40
Есть внешняя ссылка на сайт посмотреть?
15 июня 2026, 19:12
Благодарю) сижу ломаю голову, все сайты положил
15 июня 2026, 14:59
Обновил компонент
1.1.0-pl
— добавлена прямая интеграция с официальным MAX Business API;
— добавлен выбор провайдера между MAX Business и ruma...
11 июня 2026, 21:58
Позже, может размещу и на docs.modx.pro, пока времени нет
Всего 125 961 комментарий
ну так сейчас ты не про интерфейс управления?
И вопрос — а как юзер узнает об обновлении если поставил пакет напрямую через композер?
У него же в управлении пакетами не загорится обнова, сам он «переустановить» не догадается нажать, composer пользоваться не умеет. Как обновляться-то?
Не соглашусь, это примерно то же, что уже произошло с MODX 3 — обновили на полшишечки, чтобы юзеров не распугать, теперь разгребаем.
У Composer уже есть отличный CLI. Лучше уж сделать пакет с окошком терминала для работы с этим CLI из админки, если так страшно заходить в консоль сервера.
— Если необходимо связать версию транспортного пакета (ТП) с версией packagist то это можно прописать в том же ТП.
— Если в этом нет необходимости то добавить в ТП update пакета с packagist
если версии ТП и packagist связанны, то можно и реализовать откат.
2 — ну пока черновой вариант такой, мне это тоже не нравится. Там лежит только обертка для композера. Ее можно переместить в другое место и соответственно этот пункт пропадает.
Это да не фен шуй — потому и просил не ругать)
Но согласись не хватает интерфейса для управления в админке? Это пока самый простой способ видеть что установлено и привычно для пользователя.
1. У каждого транспортника своя версия, по которой админка отслеживает обновления, и если ты опубликуешь этот транспортник в репозитории MODX или modstore, то получается, тебе же надо будет следить за моими релизами на Github, и каждый раз менять версию этого транспортника?
Потому что иначе пользователи транспортника и не узнают, что есть обновление — они же не умеют делать composer update из консоли. Ну и откат на предыдущую версию вряд ли будет работать.
2. Судя по коду, этот пакет разворачивается в core/components/mmxforms и будет лежать рядом с оригинальным core/components/mmx-forms. То есть, рядом будет 2 похожие директории: одна для транспортника, вторая для оригинального дополнения.
В общем, всё это как-то костыльно, но пусть пользователи нас рассудят. Кто хочет — будет учиться работать с composer, кто не хочет — будет скачивать виртуальные транспортники.
Подумал что дело в плагине, отрубил его через БД не помогло по прежднему белый 500, запустил откат базы и файлов
Умер этот банк. Удалите с сайта.
Как благодарить то теперь?
К этому могу добавить только, что «сниппет, который отвечает за рендер результатов» задается в параметрах ffFiltering.
По поводу чанков на Fenom. Собственно, я только с ними и работаю. Циклов никаких не нужно, всё разделяется на чанки.
Адаптация под Modx 3 будет позже, мне нужно перезагрузиться, а то фиксация на одной задаче плохо влияет на качество реализации.
Тоже есть пара вопросов:
1. @Артур Шевченко, а сниппет(ы) компонента умеет(ют) передавать в чанки все указанные в вызове параметры? На мой вкус при сборке сайта очень частно нужно добавить какие-то параметры сверх тех, что предусмотрены документацией и влияют на логину сниппета, а просто доступна в чанке для проверки или использования значения.
Так, например, умеет делать pdoResources, но не умеет pdoMenu, и это очень не удобно…
2. Чанки на Fenom поддерживаются? И на квадратном modx-синтаксисе тоже? Разделение на row и outer в наличии, или предлагается на Fenom циклы крутить?))
3. Понимаю, что внедрение было на MODX2, но много ли логики в компоненте, которая отличается от MODX3 и какие перспективы по адаптации? На MODX3 переезжают уже многие, и ещё больше тех кто ждёт когда стоп-факторы будут сняты. Фильтрация — один из!
Если речь про админку Modx, то нет, там он не работает. А что касается моих кейсов, то да эта закрытая часть сайта, но всё же фронт.
И ко мне можно обращаться на ТЫ)))
Тогда можно будет получить (или использовать) актуальные знания, вместо ненужного древнего ExtJS 3.4.1.1, которому уже 11 лет.
Из ваших ответов я делаю два вывода.
1) Ваш компонент это не только фильтр для товаров минишопа (которым я его считал). Это фильтр для любых ресурсов modx. например modUser.
2) Ваш компонент предназначен не только для работы на публичной части, но и в админке. Потому что просто представить не могу, зачем кому то на публичной части давать возможность искать пользователей, фильтровать их и модерировать, такие вещи должны происходить в закрытых от публичного доступа местах.
Оба мои утверждения справедливы?
1. Опции и ТВ не используются конкретно на этих сайта, которые я взял для сравнения. Так-то сам компонент умеет работать и с ТВ, даже miigx, и с опциями.
2. Фильтрация пользователей нужна, когда имеет место ручная их модерация. В моём случае, нужно проверять паспортные данные присланные в виде фото.
3. Схожесть с SimpleSearch в том, что поиск происходит с помощью оператора LIKE. Никакой формы и сниппета нет. Суть кейса в том, что мне нужно было сделать поиск по определенным полям в уже отфильтрованных данных. Условно есть фильтр Статус и нужно найти все товары в статусе 1, которые загрузили пользователи с фамилией Иванов. Вот фамилия и есть произвольный параметр. Можно было бы и Фамилию сделать фильтром, но список был бы длинным и неудобным.
4. Есть сниппет ffFiltering, аналог mFilter2, в его чанки можно пробросить данные через вызов сниппета, а есть сниппет, который отвечает за рендер результатов, он вызывается каждый раз, когда задаются новые условия в фильтрах и вот в его чанк можно пробросить параметры только через плагин.