Это как? Какой репозиторий будет проверять версию пакета в packagist.org и показывать в админке кнопку «обновить»?

ну явно что не rest.modx.com.

И что будет происходить при нажатии на эту кнопку?

обновление пакета с composer

Нет, я про консоль в админке, где надо будет пальчиками вбивать команды composer и читать ответы. Что-то типа такого интегрировать.

не, не зайдет. Тот кто не пользуется консолью и такой пользоваться не будет. Нужен нормальный всем понятный интерфейс.

Я предлагаю подписываться на релизы в репозитории:

в случае с закрытым репозиторием как подписывать и узнавать об обновлении?

И автоматом загружать в репозитории.

И всё для того, чтобы пользователи не начинали развиваться.

Я эти дополнения сделал с противоположной целью, если что — заставить юзеров MODX пользоваться композером.

из наиболее логичного это инфу должен давать репозиторий на запрос CheckUpdates

Это как? Какой репозиторий будет проверять версию пакета в packagist.org и показывать в админке кнопку «обновить»? И что будет происходить при нажатии на эту кнопку?

Еще раз говорю, что если ты хочешь завязать работу на транспортные пакеты, тебе придётся обновлять их версию в репозиториях MODX.

ну так сейчас ты не про интерфейс управления?

Нет, я про консоль в админке, где надо будет пальчиками вбивать команды composer и читать ответы. Что-то типа такого интегрировать.

И вопрос — а как юзер узнает об обновлении если поставил пакет напрямую через композер?

Я предлагаю подписываться на релизы в репозитории:

Там можно следить за любыми разработками, не только для MODX — очень удобно.

Если уж на то пошло то можно генерировать транспортный автоматом, при появлении новой версии в packagist, там от транспортника то ничего не осталось. Если все лишнее выкинуть то останется в районе 6 файлов.

1. Ты не ответил — как юзер узнает о релизе новой версии, если ты не загрузишь новый транспортник в репозиторий MODX?

из наиболее логичного это инфу должен давать репозиторий на запрос CheckUpdates

Не соглашусь,

У Composer уже есть отличный CLI. Лучше уж сделать пакет с окошком терминала для работы с этим CLI из админки, если так страшно заходить в консоль сервера.

ну так сейчас ты не про интерфейс управления?

И вопрос — а как юзер узнает об обновлении если поставил пакет напрямую через композер?

Крутое обновление, спасибо

1. Ты не ответил — как юзер узнает о релизе новой версии, если ты не загрузишь новый транспортник в репозиторий MODX?

У него же в управлении пакетами не загорится обнова, сам он «переустановить» не догадается нажать, composer пользоваться не умеет. Как обновляться-то?

Но согласись не хватает интерфейса для управления в админке?

Не соглашусь, это примерно то же, что уже произошло с MODX 3 — обновили на полшишечки, чтобы юзеров не распугать, теперь разгребаем.

У Composer уже есть отличный CLI. Лучше уж сделать пакет с окошком терминала для работы с этим CLI из админки, если так страшно заходить в консоль сервера.

1 — тут как бы есть несколько вариантов.
— Если необходимо связать версию транспортного пакета (ТП) с версией packagist то это можно прописать в том же ТП.
— Если в этом нет необходимости то добавить в ТП update пакета с packagist

Ну и откат на предыдущую версию вряд ли будет работать.

если версии ТП и packagist связанны, то можно и реализовать откат.

2 — ну пока черновой вариант такой, мне это тоже не нравится. Там лежит только обертка для композера. Ее можно переместить в другое место и соответственно этот пункт пропадает.

В общем, всё это как-то костыльно

Это да не фен шуй — потому и просил не ругать)
Но согласись не хватает интерфейса для управления в админке? Это пока самый простой способ видеть что установлено и привычно для пользователя.

PS. Василий сильно не ругайся!

Не буду, но у меня два вопроса.

1. У каждого транспортника своя версия, по которой админка отслеживает обновления, и если ты опубликуешь этот транспортник в репозитории MODX или modstore, то получается, тебе же надо будет следить за моими релизами на Github, и каждый раз менять версию этого транспортника?

Потому что иначе пользователи транспортника и не узнают, что есть обновление — они же не умеют делать composer update из консоли. Ну и откат на предыдущую версию вряд ли будет работать.

2. Судя по коду, этот пакет разворачивается в core/components/mmxforms и будет лежать рядом с оригинальным core/components/mmx-forms. То есть, рядом будет 2 похожие директории: одна для транспортника, вторая для оригинального дополнения.

В общем, всё это как-то костыльно, но пусть пользователи нас рассудят. Кто хочет — будет учиться работать с composer, кто не хочет — будет скачивать виртуальные транспортники.

Ну я понял ))

удалил, спасибо! Юмани

именно в случае composer зависимостей как раз и нужен новый тип дополнения. Никто не гарантирует что другой пакет не притащит свои зависимости с другими версиями и сайт перестанет корректно работать.

Эх пошла заруба. Мы с напарником @Наумов Алексей уж задумались, а не сделать ли и MiniShop3 с установкой через Composer, так как там уже появились именно композерные зависимости

Зависимости pdoTools и SendIt

Доброго времени, какие то зависимости у компонента есть?, мин версия modx? Установил на один сайт словил 500, хотел просто посмотреть javascript
Подумал что дело в плагине, отрубил его через БД не помогло по прежднему белый 500, запустил откат базы и файлов

qiwi.me/VGRISH
Умер этот банк. Удалите с сайта.
Как благодарить то теперь?

Огромная благодарность!!! Сколько ж форума пришлось перелопатить )

На первый вопрос я уже ответил

Есть сниппет ffFiltering, аналог mFilter2, в его чанки можно пробросить данные через вызов сниппета, а есть сниппет, который отвечает за рендер результатов, он вызывается каждый раз, когда задаются новые условия в фильтрах и вот в его чанк можно пробросить параметры только через плагин.

К этому могу добавить только, что «сниппет, который отвечает за рендер результатов» задается в параметрах ffFiltering.

По поводу чанков на Fenom. Собственно, я только с ними и работаю. Циклов никаких не нужно, всё разделяется на чанки.

Адаптация под Modx 3 будет позже, мне нужно перезагрузиться, а то фиксация на одной задаче плохо влияет на качество реализации.

Приветствую! Отличная новость про фильтры, впечатляющая скорость, жду релиза с нетерпением, с удовольствием поучаствую в развитии (в документации, и как ещё получится). Потому что развитие системе поиска и фильтров, которые уже есть для MODX, давненько не хватало!

Тоже есть пара вопросов:

Пробрасывать в чанки дополнительные параметры через плагин.

1. @Артур Шевченко, а сниппет(ы) компонента умеет(ют) передавать в чанки все указанные в вызове параметры? На мой вкус при сборке сайта очень частно нужно добавить какие-то параметры сверх тех, что предусмотрены документацией и влияют на логину сниппета, а просто доступна в чанке для проверки или использования значения.

Так, например, умеет делать pdoResources, но не умеет pdoMenu, и это очень не удобно…

2. Чанки на Fenom поддерживаются? И на квадратном modx-синтаксисе тоже? Разделение на row и outer в наличии, или предлагается на Fenom циклы крутить?))

3. Понимаю, что внедрение было на MODX2, но много ли логики в компоненте, которая отличается от MODX3 и какие перспективы по адаптации? На MODX3 переезжают уже многие, и ещё больше тех кто ждёт когда стоп-факторы будут сняты. Фильтрация — один из!

Из коробки компонент может фильтровать обычные ресурсы, товары и пользователей, но есть возможность написать свои обработчики и фильтровать вообще всё что угодно.

Если речь про админку Modx, то нет, там он не работает. А что касается моих кейсов, то да эта закрытая часть сайта, но всё же фронт.

И ко мне можно обращаться на ТЫ)))