Предусмотрена ли такая возможность?
| dedushka |
|
|---|---|
|
В другом месте (http://www.cotonti.com/forums.php?m=posts&p=28079) уже описывалась недокументированная возможность отделить файлы ядра от собственных модификаций. Есть ли что-то подобное для плагинов? В идеале, хотелось бы иметь возможность указывать несколько областей поиска плагинов в переменной $cfg['plugins_dir']. Актуально при использовании одного движка для нескольких субдоменов.
Возможно, существует какой-то более |
|
Dit bericht is bewerkt door dedushka (2011-04-29 11:00, 14 jaren ago) |
| esclkm |
|
|---|---|
|
что за паранойа? в стандартном комплекте такой возможности нет littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
| Trustmaster |
|
|---|---|
|
Для мультисайтов обычно папка плагинов делается одна для всех сайтов, а вот datas и конфиги и БД у всех разные. May the Source be with you!
|
| Kort |
|
|---|---|
|
С путями там затык выходит. Решается или очень изощренно (через размещение "сателлитов" в подкаталогах основного сайта) или никак. SED.by - создание сайтов, разработка плагинов и тем для Котонти
|
| Trustmaster |
|
|---|---|
|
А можно подробнее, в чём затык? Может, его разрулить получится. May the Source be with you!
|
| dedushka |
|
|---|---|
|
Затык в том, что стандартные плагины обновляются вместе с движком, и для обновления своих плагинов приходится влезать в его каталоги, где стандартные и нестандартные - все в куче. В субдоменах использование includ'ов в корневых файлах (page.php, list.php и пр.) позволяет гарантировать актуальность версии, однако, с плагинами такое организовать не удается или я не могу понять как. PS Хотелось бы иметь представление о "линии партии" (Trustmaster, спасибо) в организации мультисайта. Добавлено 1 дня спустя: Кстати, чтобы нормально работать с admin.php в субдомене, приходится дублировать system/admin/img/*.* Т.е. переменная $cfg['system_dir'] не везде учитывается. |
|
Dit bericht is bewerkt door dedushka (2011-05-01 14:47, 14 jaren ago) |
| Trustmaster |
|
|---|---|
|
Мультисайтами всерьёз не занимались ещё со времён ветки genesis. Тогда придумали решение с примерно такой структурой. Движок распаковывается куда-то в доступное для всех хостов место, где хранятся основные файлы, в том числе и общий пул доступных к установке плагинов:
Далее добавляются сателлиты, каждый из которых имеет корневые скрипты и индивидуальные папки, т.е.:
То есть подразумевалось, что скины, базы, конфиги и пользовательские файлы у сателлитов разные, а вот системные файлы и набор доступных плагинов един. system/admin/img явно прописано, насколько показал поиск, в admin.resources.php. Это хорошее замечание, я заменю там литерал на переменную к следующей версии. Правда, будут ли работать изображения, если там будет нечто вроде ../common/system/admin/img? May the Source be with you!
|
|
Dit bericht is bewerkt door Trustmaster (2011-05-01 15:34, 14 jaren ago) |
| dedushka |
|
||
|---|---|---|---|
|
Решение нереканий не вызывает, особенно, если вместо корневых скриптов использовать одноименные с содержанием типа:
Если движок и сателиты лежат в публичной области, то проблем с изображениями быть не должно. Есть ли какие-то нюансы в использовании таблиц БД для сателитов? Добавлено 5 дня спустя: Если можно, несколько слов о работе install.php на сателитах. Каков вообще порядок развертывания сателита? Требуется ли запускать install.php при его установке? Требуется ли его запускать после обновления файлов основного движка? |
|||
Dit bericht is bewerkt door dedushka (2011-05-06 10:17, 14 jaren ago) |
| Trustmaster |
|
|---|---|
|
Основная задача install.php - обновление БД и конфигурации. А именно БД и конфигурацией сателлиты различаются. Вывод: install.php необходимо запускать при установки и обновлении на каждом сателлите. May the Source be with you!
|
| dedushka |
|
|---|---|
|
Спасибо за ориентировку. |
