Механизм обновления плагинов
В новой версии мы внедрили функционал миграций (обновлений) для плагинов. Функционал позволит разработчикам удобно выполнять обновления своих плагинов, в особенности, если эти обновления затрагивают изменения базы данных.

Скрипты (классы) для обновления у плагина находятся в каталоге
Файл с обновлением представляет собой класс наследник от базового класса
Как видно из примера, класс содержит два метода
При удалении плагина из админки выполняется автоматический откат всех изменений всех версий (метод down).
Данный поход позволит «разгрузить» у плагинов методы
Как это работает
Пользователь заливает новую версию плагина в каталог/plugins/
. Система сравнивает текущую версию плагина с версией этого плагина в БД. И если версия в БД старее, то в админке появляется кнопка «Применить обновление», которая автоматически запустит необходимые скрипты для обновления.
Скрипты (классы) для обновления у плагина находятся в каталоге
/update/
, который в свою очередь содержит каталоги с номерами версий. Для каждой версии можно создать несколько скриптов с произвольным названием, главное, что нужно помнить — названия файлов должно быть уникальным в рамках всего плагина для всех его версий.Файл с обновлением представляет собой класс наследник от базового класса
ModulePluginManager_EntityUpdate
и название класса является производным от имени файла — Plugin[plugin_name]_Update_[file_name]. Например, для файла /update/1.0/CreateTable.php класс будет таким:<?php class PluginArticle_Update_CreateTable extends ModulePluginManager_EntityUpdate { /** * Выполняется при обновлении версии */ public function up() { if (!$this->isTableExists('prefix_article')) { /** * При активации выполняем SQL дамп */ $this->exportSQL(Plugin::GetPath(__CLASS__).'/dump.sql'); } } /** * Выполняется при откате версии */ public function down() { $this->exportSQLQuery('DROP TABLE prefix_article;'); } }
Как видно из примера, класс содержит два метода
up
и down
. Первый выполняется при обновлении до версии, второй при откате версии. В этих методах может быть не только работа с БД, но и другая необходимая для обновления логика.При удалении плагина из админки выполняется автоматический откат всех изменений всех версий (метод down).
Данный поход позволит «разгрузить» у плагинов методы
Activate
и Deactivate
от лишней логики и дать удобный механизм обновления версий. Для корректной работы данного механизма, необходимо версии плагинов именовать используя вот этот стандарт — ru2.php.net/manual/ru/function.version-compare.php, он позволит правильно сортировать версии.
18 комментариев
Но ведь на практике обновления плагинов не так часто связаны с обновлением таблиц.
Мне кажется неплох был бы такой механизм:
— по крону сравниваем версии установленных плагинов с версиями в каталоге
— вносим в конфиг учетные данные каталога
— «подтягиваем» с каталога новую версию
— предыдущую версию бэкапим (файлы + таблицы БД)
это уже и так есть давно. в данном случае новый функционал нужен для облегчения операции обновления («активации2), когда новая версия плагина уже содержится на сайте, но плагин ещё не активирован.
все последовательно
но извините меня «Пользователь заливает новую версию плагина в каталог» как то это очень сложно, не находите?
Если уж реализовывать такой инструмент сравнения, ПЛУС есть каталог плагинов. Не легче разработчику плагина добавить новую версию плагина в каталог? Сайт пользователя будет проверять есть ли обновления плагина в каталоге, и уже оттуда нажимает обновить, а все остальное, уже как у вас.
Ну в общем, как это реализовано давно в WP или Joomla, что скажите? Или есть какие то не реальные сложности в реализации такого?