#32944 Trustmaster:

Совершенно неверно. Кнопка "Обновить" делает следующее:

1. Вычисляет разницу между установленной в базе версией плагина и версией setup-файла.
2. Удаляет текущие хукочасти плагина и устанавливает все заново. Это нужно, если в плагине появились новые части или если старые были удалены / изменилась мета-информация (например, используемые хуки).
3. Обновляет конфигурацию. Добавляет новые опции, если таковые появились. Удаляет опции, которые были удалены из плагина. Изменяет и сбрасывает те опции, для которых изменился тип. Остальные опции оставляет неизменными.
4. То же самое производит с конфигурацией структуры.
5. Обновляет маски Auth/lock для members и guests.
6. Выполняет PHP и SQL патчи из папки setup последовательно, исходя из различий установленной и новой версии.
7. Обновляет версию плагина в базе и очищает кеш.

Надо бы внести это описание в один из разделов документации, например в "администрирование". Я, например, слежу за выходом почти каждого обновления, а таких особенностей не знал.

По поводу предложений.

1. Это не нужно. Это не genoa и переустанавливать каждый раз не надо. Кнопка Update применяет разность между релизами, а не сносит всё и ставит заново. Для более тонких вещей, помимо конфигурации, хуков и авторизации, учитесь писать SQL и PHP патчи для перехода к новым версиям без потери данных. Примеров в стандартных модулях и плагинах предостаточно.

Понял.

2. Речь идёт полном контроле версий для каждого файла или о контроле версий для расширений целиком? Если второе, то это уже работает. Просто нужно добавить отображение обеих версий (установленная и текущая) и уведомление об обновлении в админке.

В таком случае, думаю, достаточно общей версии для расширения. Что касается версий каждого файла, то надо либо их упразднить, либо в "документации для разработчика плагинов" указать, что версии каждого файла существуют "для справки", а системой используется только "главная версия" из setup файла.

См. "Примечание для разработчиков расширений" здесь.

Спасибо. Надо продублировать в одной из файлов раздела: http://www.cotonti.com/ru/docs/ext/extensions/

На сколько понимаю просто сбрасывает настройки плагина к настройкам по умолчанию. Почему ее перевели как "Обновить" не понятно.

Совершенно неверно. Кнопка "Обновить" делает следующее:

1. Вычисляет разницу между установленной в базе версией плагина и версией setup-файла.
2. Удаляет текущие хукочасти плагина и устанавливает все заново. Это нужно, если в плагине появились новые части или если старые были удалены / изменилась мета-информация (например, используемые хуки).
3. Обновляет конфигурацию. Добавляет новые опции, если таковые появились. Удаляет опции, которые были удалены из плагина. Изменяет и сбрасывает те опции, для которых изменился тип. Остальные опции оставляет неизменными.
4. То же самое производит с конфигурацией структуры.
5. Обновляет маски Auth/lock для members и guests.
6. Выполняет PHP и SQL патчи из папки setup последовательно, исходя из различий установленной и новой версии.
7. Обновляет версию плагина в базе и очищает кеш.

Добавлено 9 минут спустя:

По поводу предложений.

1. Это не нужно. Это не genoa и переустанавливать каждый раз не надо. Кнопка Update применяет разность между релизами, а не сносит всё и ставит заново. Для более тонких вещей, помимо конфигурации, хуков и авторизации, учитесь писать SQL и PHP патчи для перехода к новым версиям без потери данных. Примеров в стандартных модулях и плагинах предостаточно.

2. Речь идёт полном контроле версий для каждого файла или о контроле версий для расширений целиком? Если второе, то это уже работает. Просто нужно добавить отображение обеих версий (установленная и текущая) и уведомление об обновлении в админке.

3. См. пункт первый и объяснение работы обновления выше.

 

Думаю в виду планов сделать некий общий репозиторий модулей, есть смысл обсудить и проработать механизм "удобной" установки / управления модулями. 

В идеале некая система типа пакетов в *nix системах, когда каждый пакет имеет версию и зависимости от других.

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

Каждое расширение уже с первых релизов Сиены имеет версию и зависимости от других. Работает это не так удобно, как менеджеры пакетов в *nix системах, но постепенно идёт к этому.

Добавлено 2 минуты спустя:

См. "Примечание для разработчиков расширений" здесь.

На сколько понимаю просто сбрасывает настройки плагина к настройкам по умолчанию. Почему ее перевели как "Обновить" не понятно.

Но это так, преамбула...

Предложения (они все перекликаются между собой поэтому надо выработать единый алгоритм)

1. Изменить функционал кнопки или добавить отдельную кнопку "переустановить/обновить плагин". По нажатию на которую плагин удаляется и устанавливается по новой в один клик.

Что мы получаем:

• при выходе новой версии плагина проще переустановить - для боьлшинства плагинов распаковал и нажал кнопку
• при создании плагинов (внесение изменений в файлы /  хуки / setup переменные плагина) - проще переустановить и протестировать
• в плагине обновилась пара строк и добавился новый хук, тогда достаточно просто заменить 1 файл на новый и нажать обновить. И не надо деинсталировать-инсталировать-настраивать по новой.

2. Доработать алгоритм установки плагинов, чтобы сохранял в базу версии плагинов/модулей, тогда возможно будет проверять эти версии на соответствие текущим файлам (и, например, выводить иконку предупреждение о том, что некоторые файлы добавились или изменили свою версию).

Смысл идеи сделать более простым  добавление / обновление модулей. Закинул измененные файлы в папку плагина,
а система тебе в админке говорит - "! версии таких-то файлов отличаются от последней установки, обновить?", жмем "обновить"

3. При обновлении плагина должна существовать возможность не обнулять данные настроек плагина и (или) данных персональных таблиц БД. Тут думаю понятно из предыдущих пунктов - плагин изменился немоного, чтобы все не сносить просто обновляем...

Написал сумбурно, поэтому подытожу требования:

1. обновление модулей в один клик
2. версионность модулей и ее физический контроль 
3. сохранение настроек/данных модуля при его обновлении
4. контроль зависимостей (уже решен в #768 )

Думаю в виду планов сделать некий общий репозиторий модулей, есть смысл обсудить и проработать механизм "удобной" установки / управления модулями. 

В идеале некая система типа пакетов в *nix системах, когда каждый пакет имеет версию и зависимости от других.