cotonti.com : Отделить свои плагины от коробочных

dedushka

Пт, 06 Травень 2011 19:05:54 -0000

Спасибо за ориентировку.

Trustmaster

Пт, 06 Травень 2011 13:32:10 -0000

Основная задача install.php - обновление БД и конфигурации. А именно БД и конфигурацией сателлиты различаются. Вывод: install.php необходимо запускать при установки и обновлении на каждом сателлите.

dedushka

Нд, 01 Травень 2011 18:01:56 -0000

Решение нереканий не вызывает, особенно, если вместо корневых скриптов использовать одноименные с содержанием типа:

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

Есть ли какие-то нюансы в использовании таблиц БД для сателитов?

Добавлено 5 дня спустя:

Если можно, несколько слов о работе install.php на сателитах. Каков вообще порядок развертывания сателита? Требуется ли запускать install.php при его установке? Требуется ли его запускать после обновления файлов основного движка?

Trustmaster

Нд, 01 Травень 2011 15:32:18 -0000

Мультисайтами всерьёз не занимались ещё со времён ветки genesis. Тогда придумали решение с примерно такой структурой.

Движок распаковывается куда-то в доступное для всех хостов место, где хранятся основные файлы, в том числе и общий пул доступных к установке плагинов:

/vhosts/common/images
/vhosts/common/js
/vhosts/common/plugins
/vhosts/common/system

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

/vhosts/example.com/datas
/vhosts/example.com/skins
/vhosts/example.com/admin.php
...

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

system/admin/img явно прописано, насколько показал поиск, в admin.resources.php. Это хорошее замечание, я заменю там литерал на переменную к следующей версии. Правда, будут ли работать изображения, если там будет нечто вроде ../common/system/admin/img?

dedushka

Сб, 30 Кві 2011 09:16:17 -0000

Затык в том, что стандартные плагины обновляются вместе с движком, и для обновления своих плагинов приходится влезать в его каталоги, где стандартные и нестандартные - все в куче. В субдоменах использование includ'ов в корневых файлах (page.php, list.php и пр.) позволяет гарантировать актуальность версии, однако, с плагинами такое организовать не удается или я не могу понять как.

PS Хотелось бы иметь представление о "линии партии" (Trustmaster, спасибо) в организации мультисайта.

Добавлено 1 дня спустя:

Кстати, чтобы нормально работать с admin.php в субдомене, приходится дублировать system/admin/img/*.* Т.е. переменная $cfg['system_dir'] не везде учитывается.

Trustmaster

Сб, 30 Кві 2011 08:02:42 -0000

А можно подробнее, в чём затык? Может, его разрулить получится.

Kort

Сб, 30 Кві 2011 06:51:04 -0000

С путями там затык выходит. Решается или очень изощренно (через размещение "сателлитов" в подкаталогах основного сайта) или никак.

Trustmaster

Сб, 30 Кві 2011 06:38:32 -0000

Для мультисайтов обычно папка плагинов делается одна для всех сайтов, а вот datas и конфиги и БД у всех разные.

esclkm

Пт, 29 Кві 2011 20:42:51 -0000

что за паранойа?

в стандартном комплекте такой возможности нет

dedushka

Пт, 29 Кві 2011 10:58:32 -0000

В другом месте (http://www.cotonti.com/forums.php?m=posts&p=28079) уже описывалась недокументированная возможность отделить файлы ядра от собственных модификаций. Есть ли что-то подобное для плагинов? В идеале, хотелось бы иметь возможность указывать несколько областей поиска плагинов в переменной $cfg['plugins_dir']. Актуально при использовании одного движка для нескольких субдоменов.

Возможно, существует какой-то более ~~изощренный~~ простой способ реализации.