1.1.x Автоинсталлятор плагинов и языков

Автоинсталлятор плагинов (языки в перспективе).

Тема на оффоруме:

Код:

http://xenforo.com/community/threads/infisjsc-auto-installer.25545

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

Предполагаемая структура папок в пакете (архиве):

Код:

/ - корень пакета (архива)
/upload - папка с файлами для закачивания на сервер
/addon.xml - инсталлятор адд-она
/lang.xml - язык для адд-она

Предполагаемая структура папок в мультипакете (архиве)

Код:

/ - корень мультипакета (архива)
/addon1 - папка с адд-оном №1
/addon1/upload - папка для копирования в корень форума
/addon1/addon.xml - инсталлятор адд-она №1
/addon1/lang.xml - язык для адд-она №1
/addon2 - папка с адд-оном №2
/addon2/upload - папка для копирования в корень форума
/addon2/addon.xml - инсталлятор адд-она №2
/addon2/lang.xml - язык для адд-она №2

Примечание: названия папок addon1 и addon2, а также xml-файлов не имеют значения. Автоинсталлятор просто находит папку upload и считает, что она является корневой для форума и копирует из нее, а xml-файлы берет из того же уровня, что и папка upload. При этом каждый найденный xml-файл в этом случае проверяется на принадлежность к инсталлятору адд-она или к языку. Если xml-файлов одного типа окажется более, чем один, то берется последний обработанный. Обработка происходит вне зависимости от сортировки, так как чтение каталогов и файлов производится по физическому положению. Если произойдет ошибка при установке плагина, то остановка инсталляции других плагинов не происходит, но перестройка кеша также не производится. При этом ошибки отобразятся пользователю. При необходимости кеш можно перестроить штатными средствами.

С языком я еще не разбирался, но думаю, что можно будет без особых проблем правильно сопоставить его с нужным языком.

Непосредственно загрузка архива производится штатно через загрузку нового инсталлятора плагина. Т.е. на стороне сервера просто проверяется, что пришло - архив или xml, а затем обрабатывается уже в зависимости от этого. Таким образом не изменяется общая логика инсталляции плагинов, а лишь расширяется.



Еще пара скриншотов с демонстрацией апгрейда:


Теперь ссумирую то, что уже есть (с версии 1.1):
1. Инсталляция производится через штатный установщик плагинов.
2. Если был загружен архив, то проверяется его структура и в зависимости от структуры (см. выше) происходит обработка одного или сразу нескольких плагинов.
3. При необходимости будет произведен апгрейд плагина. Т.е. проверяется наличие плагина и, если он уже есть, выводится информация о том, из какой версии в какую будет произведен апгрейд (справа от id адд-она). Если апгрейд не нужен, то указывается версия, которая присутствует в инсталляторе.
4. После загрузки пакета обработчик проверяет возможность записи файлов на сервер. Эта информация выводится перед непосредственной установкой (см. скриншот).
5. Также сверяются файлы из пакета и на сервере. Если файл новый, то об это будет отображено. Если файл присутствует и совпадает с тем, который инсталлируется, то это также будет отображено. В случае, когда инсталлируемый файл отличается от находящегося на сервере, он сравнивается с ним, а результат сравнения можно посмотреть в виде diff, щелкнув по нему (см. скриншот).
6. Информация из пунктов 4 и 5 носит справочный характер и позволяет лишь удостовериться в отсутствии проблем или их незначительности (например, невозможность записи одинаковых файлов не критична). Также можно отказаться от инсталляции всего.
7. Непосредственно инсталляция происходит после просмотра вносимых изменений (вышеуказанные пункты) и только тех файлов, которые различаются или новые.
8. В случае ошибок при инсталляции, они будут отображены, но перестройка кеша не производится. При необходимости кеш перестраивается вручную штатными средствами позднее в соответствующем разделе административной панели.
9. Инсталляция обычного xml-файла происходит штатной процедурой инсталляции. Таким образом не нарушена штатная логика работы установщика.

Теперь TODO:
1. Обработка языковых файлов и совместная их установка. Если можете помочь с подсказкой, как лучше информацию о языковом файле отобразить в форме изменений перед инсталляцией, с радостью выслушаю Ваши предложения.
2. Инсталляция стилей (пока до этого далеко, но, думаю, вполне реально).
3. Удаление устаревших файлов (т.е. отсутствующих в upload пакета, но присутствующих на сервере).
4. Причесать код.

Установка: как любого плагина. Русский язык в архиве с плагином.

 

Может имеет смысл сделать аплоадер на флеше или html5, с выбором нескольких файлов одновременно?

 

Это уже будет довольно большая переделка. Я не силен во флеше вообще и в html5 в частности.
А определить, прилетел ли архив или xml могу из php без проблем. Да и пользователь не будет заморачиваться, что и как туда загружать.
Я вот еще что подумал. Для непродвинутых достаточно сделать защиту от дурака, чтобы он просто не смог загрузить непонятный файл. А для продвинутых появляется возможность делать мультипакеты под себя с нужным набором плагинов и языков. Можно будет быстро разворачивать весь свой набор.
Кстати, можно еще поизвращаться и сохранять где-нибудь в отдельной таблице в базе пути к устанавливаемым файлам, что позволит затем еще и при деинсталлировании удалять файлы с сервера.

А относительно загрузки сразу нескольких файлов - никто ведь не мешает слить все тупо в один архив. Главное, чтобы каждый плагин был в отдельной папке внутри архива. Для большинства админов, думаю, это проблемы не составит. Да и есть слабая надежда, что разработчики, если появится такой плагин, сделают все же свой нормальный инсталлятор. Но есть и один нюанс. Они могут это сделать в рамках своего менеджера ресурсов, коий обещают уже достаточно давно. Поэтому не хочу делать какой-то масштабный плагин, а хочу довольно простой без особых наворотов. Кому нужно, сможет и под себя его дописать. Там код простейший: тот же декомпрессор используется от зенда (а тот берет в свою очередь с пыха).

 

Можно же просто использовать стандартный флеш-загрузчик от XenForo. Я правда не знаю можно его как-то красиво вынуть

 

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

Я вот еще не хотел бы трогать шаблоны. Хотя... Там можно будет просто другой шаблон сделать и его вызывать.

 

Собственно за флеш-загрузчик и за обычный отвечает шаблон attachment_upload_button
Можно просто оттуда взят код.

 

Хорошо. Я тогда сначала сделаю простой плагин, а потом попробую уже сделать версию с загрузкой нескольких файлов.

 

Первая версия плагина. Может только закачивать архив. При этом структура должна быть в виде:

Код:

/
/upload
install.xml

Папка upload обязана быть (да, я знаю, что есть плагины и без этой папки, но пока так). Файл xml может иметь любое имя, но обязательно с расширением xml.
Файлы из upload копируются без подтверждения и с перезаписью (поэтому будьте внимательны!) в корень форума. Т.е. нужно обязательно соблюдать структуру форума.

Версия очень альфа даже. Поэтому минимум обработок ошибок. Языковый файл пока тоже не инсталлируется. Управление и интерфейс как таковой отсутствует. Работает бесшумно, просто позволяя указывать архив (zip), а не только xml. Весь процесс происходит в фоне и незаметно.

Права на запись в папки, естественно, должны позволять в них записывать.

 

В связи с новой версией плагина обновлен первый пост.

P.S. Интересно, а нужен ли будет этот плагин, если появится Resource Manager или что-то такое от разработчиков XenForo?

 

Ну так а кто мешает в итоге вообще из этого сделать менеджер? Более того, я склоняюсь к таким функциям, как:
1. Контроль исходных файлов, инсталлируемых через инсталлятор, сохраняя историю изменений в базе данных.
2. Контроль установки шаблонов, сохраняя историю изменений в базе данных.
3. При наличии пункта 1 и 2 возможно делать откат на предыдущие версии, а также в случае некорректной инсталляции плагина, откатывать все изменения, включая исходные файлы, фразы и шаблоны.
4. Если найти способ перехвата всех запросов SQL из инстал-файла плагина, то можно в том числе учитывать и какие таблицы создаются.
5. Если соблюсти все пункты, то можно смело еще и свой деинсталлятор делать, который корректно подчистит все, что инсталлировал плагин.
6. Ну а коли мы получаем полный контроль над установкой и деинсталляцией плагинов, то можно еще и хранилище плагинов дописать. Причем, можно это хранилище делать как внутренним, так и внешним. Внешнее хранилище можно формировать, скачивая с того же офа, а можно написать свой парсер для раздела релизов офа, который будет использовать аккаунт офа каждого владельца форума, чтобы потом не было косых взглядов со стороны офа. В общем - раздолье Попутно можно получить полную версифиционность а-ля svn или гит.

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

 

Этот пункт имхо нереально будет нормально реализовать. А если что-то подобное и будет, то я базу своего форума и близко не подпущу к такому скрипту.
Если же у инталла вообще не будет своего php инсталлятора, а некий уровень абстракции без прямого вызова каких либо sql запросов, то тогда будет иметь смысл.

 

Я имел ввиду только extend класса, отвечающего за работу с базой данных. Но вот как там подсмотреть, откуда сделан вызов и т.д., я еще не смотрел. Так, только догадки. Поэтому что-то такое сделать, возможно, и получится.
Плагины на самом деле редко используют свои таблицы или запись в служебные таблицы, поэтому это достаточно редкая функция. Можно, конечно, тупо просто делать "слепок" таблиц без данных перед запуском инсталляции, а потом делать "слепок" повторно. Ну и сверять затем. Но в таком случае можно будет обнаружить лишь создание или изменение структуры таблиц. Сами данные при этом останутся неизвестными.
А что конкретно пугает в перехвате запросов из инстал-файла плагина? Что может случиться с базой? Честно говоря, я даже не думал, что это хоть как-то может быть опасно. По моему, это может просто временно (на время инсталляции) снизить производительность. Или я что-то упустил?

 

Т.е. Вас не пугает написать свой парсер SQL языка (Mysql версии) на пхп? Лично меня пугало бы.
А если даже и сделать, то в результате этот парсер по объему будет минимум в раз в 10 больше всего кода плагина. Логичный вопрос - а надо ли?

 

Нет, конечно, я не имел ввиду писать свой парсер SQL. Речь была лишь о перехвате вызовов $db = XenForo_Application::get('db') и $db->query, которые обычно используется
Иначе можно было бы вообще смело писать парсер PHP файла installer.php, например

 

Вот из-за этого я и подумал что понадобится парсер sql запросов, ведь тогда зачем перехватывать из вызов???

 

Ну из самого запроса не сложно получить, к каким таблицам происходит обращение. Также можно попробовать использовать дебаггер самого ксена или зенда. Ведь они могут профилировать в том числе и запросы.

 

Как поставить русский язык?

 

Через импорт языка с перезаписью.