Вот к примеру, подписался на новые релиз в твоем репозитории, пришло оповещение, я зашел на сайт и просто переустановил пакет.

/home/s33859/www/composer.json has been updated
Running composer update mmx/database mmx/forms
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 2 updates, 0 removals
- Upgrading mmx/database (1.0.0 => 1.0.1)
- Upgrading mmx/forms (dev-main 9a6f320 => 1.0.1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 2 updates, 0 removals
As there is no 'unzip' nor '7z' command installed zip files are being unpacked using the PHP zip extension.
This may cause invalid reports of corrupted archives. Besides, any UNIX permissions (e.g. executable) defined in the archives will be lost.
Installing 'unzip' or '7z' (21.01+) may remediate them.
- Downloading mmx/database (1.0.1)
- Downloading mmx/forms (1.0.1)
0/2 [>---------------------------] 0%
1/2 [==============>-------------] 50%
2/2 [============================] 100%
- Upgrading mmx/database (1.0.0 => 1.0.1): Extracting archive
- Upgrading mmx/forms (dev-main 9a6f320 => 1.0.1): Extracting archive
0/2 [>---------------------------] 0%
2/2 [============================] 100%
Generating autoload files
61 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found.
Using version ^1.0 for mmx/database
Using version ^1.0 for mmx/forms

Cleared MODX cache

Added event "OnSiteRefresh" to plugin "mmxForms"
Run Phinx migrations
Phinx by CakePHP - https://phinx.org.

using config file core/vendor/mmx/forms/core/phinx.php
using config parser php
using migration paths
- /home/s33859/www/core/vendor/mmx/forms/core/db
using environment local
using database s33859
ordering by creation time

== 20240325145843 FormSnippet: migrating
== 20240325145843 FormSnippet: migrated 0.2726s

== 20240326132457 Files: migrating
== 20240326132457 Files: migrated 0.6260s

All Done. Took 0.9163s

Cleared MODX cache

Готово, у меня новая версия дополнения. Теперь и на русском языке, отлично.

ps. там сортировка не работает, выдает ошибку joxi.ru/zANQW4qiv4KyQ2

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

Пользователи MODX — они же все разные, нельзя всех под одну гребенку. Одно дело если речь про разработчиков то да, тут я с тобой солидарен, composer удобно и тд и тп.

Но большая часть это обычные люди, вообще не разрабы и они тоже хотят что-то сделать на MODX, им нужен понятный интерфейс с кнопочками и окошечками.

Это как? Какой репозиторий будет проверять версию пакета в 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 будет позже, мне нужно перезагрузиться, а то фиксация на одной задаче плохо влияет на качество реализации.