Powered by CodeIgniter

Разработка

(21)
17
17 голосов
Разработка новой версии cogear. Прямой эфир с места событий.
Мультисайтовость Поскольку достаточно много запросов было адресовано именно мультисайтовости, давайте обсудим ее реализацию. Для начала определимся, что это такое — мультисайтовость?
Мультисайтовость — это возможность на одной физической установке движка (одном наборе файлов) обслуживать сразу несколько сайтов. Чем это удобно?
  • Единовременное обновления движка/компонентов для всех сайтов.
  • Единовременная загрузка расширений для работы на всех сайтах.
На мой взгляд, единственным модульными движком с нормально реализованной мультисайтовостью является Drupal, поэтому рассмотрим мультисайтовость на примере этой системы.
Итак, все модули ядра в Drupal расположены в папке /modules. Да, конечно, вы можете дополнить папку сторонними модулями, и они будут работать, как полагается, но это скорее всего вызовет некоторые неудобства во время обновления системы, поэтому обратимся к папке /sites и посмотрим на ее содержимое (квадратными скобками отмечены необязательные элементы):
  • all — папка, содержащая элементы для всех сайтов.
    • [all/modules] — модули для всех сайтов.
    • [all/themes] — темы для всех сайтов.
    • [all/libraries] — библиотеки для всех сайтов.

  • default — папка сайта по-умолчанию (если не создана папка, названная доменом сайта).
    • [default/modules] — модули сайта по-умолчанию.
    • [default/themes] — темы сайта по-умолчанию.
    • files — файлы сайта по-умолчанию.
    • settings.php — файл настроек сайта по-умолчанию.
  • [first.ru]
  • [sub.first.ru]
  • [second.ru]
  • [sub.second.ru]

Логика работы следующая — если папка, название которой совпадает с названием вызываемого домена, не существует, то используется сайт по-умолчанию (default). Соответственно, также существует папка, где хранятся модули, библиотеки и темы, которые могут использоваться на всех сайтах.
Папки конкретных сайтов по структуре аналогичны папке default.

Идея без сомнения отличная, не даром у Drupal сотни тысяч последователей, однако, на мой взгляд, она избыточна.
Вся информация об активированных для того или иного сайта модулях хранится в базе/кеше.
Если мы уберем папки конкретных сайтов, а также сайта по-умолчанию и оставим одну папку «для всех», то по-сути (если вынести хранение основных настроек сайта за пределы данной конструкции) измениться лишь то, что все сайты будут в админке видеть все расширения без своих особенных тем и модулей, которые могли находится в их папке.
Сейчас более понятно на пальцах.
После установки сайта first.ru в админке можно было наблюдать модули и темы из подпапок all и first.ru. По-сути, мы ничего не теряем, кроме возможности иметь отдельные дистрибутивы модулей/тем для каждого сайта.
То есть все сайты будут видеть у нас все модули и темы, а вот какие из них будут активированы — это будет зафиксировано в настройках сайта.

Прошу заметить, что в данной ипостаси движка сделал ход несовместимый с мультисайтингом — хранение настроек в info-файле.

Здесь два варианта развития событий.
  • Шестеренки хранятся в папке /gears, а темы — в /themes. Активируя шестеренку для конкретного сайта, мы просто делаем об этом заметку в базе и сохраняем настройки. Файлы сайтов будут храниться в указанных при их создании папках. Например, /uploads/somesite.ru.
  • Шестеренки и темы для каждого домена дополнительно могут храниться в подпапках /sites/site.ru/(gears и themes). Файлы сайтов хранятся также как в Drupal в папках вида /sites/site.ru/files.


С одной стороны первый путь более понятный и простой, с другой — у второго пути больше возможностей, хотя это вопрос спорный.

Хочу услышать мнение тех, кто некогда спрашивал, будет ли мультисайтинг в cogear?
16:34 ← 07 января 2010 Отправить в Твиттер adminadmin  RSS comments 24

Комментарии (24) ↓

inetlover inetlover time 00:58 ← 08 января 2010 #
Закладывать фундамент в новую версию движка, на которой можно построить мультисайтовость — это правильно. Если оно того стоит, то значит надо ее делать. К сожалению, не могу сказать большего в силу своей не компетенции :-(.
Freem Freem time 06:45 ← 08 января 2010 #
>> Прошу заметить, что в данной ипостаси движка сделал ход несовместимый с мультисайтингом — хранение настроек в info-файле.

Если я правильно проснулся то имеется ввиду что мы сейчас дошли до момента, где нужно определиться как хранить настройки шестеренок для каждого сайта?

Опять же, если, я правильно понял, то как вариант хранить настройки можно так.

Если шестеренка «user_group» лежит в «all/gears» то настройка для сайта лежит в "/site.ru/gears/user_group.info"
Это как Unix и WIndows, есть папка с программой c:\program files\ а настройки лежат в user\application data\.

Если же шестеренка лежит site.ru/gears/ то и хранить настройки внутри шестеренки как положено.

Но это так, скорее, мысли в слух.
Freem Freem time 06:48 ← 08 января 2010 #
Кстати, когда публикуешь коммент символ "''" двойная ковычка превращается в угловую скобку. А когда редактируешь комментарий, двойные ковычки не превращаются в угловые ковычки. Посмотрите на примере: «all/gears» то настройка для сайта лежит в "/site.ru/gears/user_group.info"

чортъ. в каком случае они превращаются в угловые?
dqpb dqpb time 08:36 ← 08 января 2010 #
Думаю и мультиязычность тут же необходимо учесть, а ещё меня беспокоит вопрос поддоменов. Как они себя поведуть при подобной структуре? Повлияет?
Автор
admin admin time 13:13 ← 08 января 2010 #
Нет, не повлияет. Мультиязычность — это уже сложнее. Надо все продумать до мелочей.
Wave Wave time 02:41 ← 18 июня 2010 #
А можно вопрос, есть какие-то подвижки с мультиязычностью? Мне то и дело она бывает нужна.
Автор
admin admin time 02:43 ← 18 июня 2010 #
Для каких целей нужна? Работа в этом направлении пока не велась. Если говорить об интернационализации, движок переведен на Украинский.
Wave Wave time 02:56 ← 18 июня 2010 #
Конкретно сейчас меня обрадовали, что сайт, который вот-вот буду делать, требуется на двух языках: русский и украинский. Ещё один сайт требуется переложить на рельсы «русский + украинский + немецкий (которого я не знаю) + (опционально, но желательно) английский». Ещё один сайт закончил с месяц или два назад — русский плюс английский. И ещё один, который не стал делать, аналогично, русский плюс английский.
Детект предпочитаемого языка по кукам и\или урлу. Чтоб на предпочитаемом языке был и интерфейс, и собственно посты. Первое делал силами того, что движок (не когир) имеет локализацию. Второе за счёт непересекающихся навигационных веток информации (в случае одного языка навигация по русскоязычной ветке, в случае другого…) В моём случае языковые ветки информации могли и не совпадать (а совпадение делал вручную, дублируя ноды на нужных языках).
Ildar Ildar time 10:40 ← 08 января 2010 #
Мультисайтовость это очень хорошо.
А база юзеров будет общая или для каждого сайта свои юзеры?
Автор
admin admin time 13:13 ← 08 января 2010 #
Думаю, что можно вопрос решить любым способом.
JiLiZART JiLiZART time 12:29 ← 09 января 2010 #
Одна небольшая проблема которая постоянно возникает у меня при запуске нескольких проектов на Drupal:
1. Бывает такое что нужно для каждого сайта свой robots.txt ( Решаемо модулем )
2. Иногда требуют форум, конечно можно сделать forum.sitename.ru, но иногда хочется и sitename.ru/forum, но в случае с Drupal такое невозможно если имеем более 2х сайтов с форумом
3. Бывает что на 1 сайт ссылается 2 домена ( Эта проблема будет решена в 7 версии, путём добавления алиасов )
Можно рассмотреть ещё один вариант, довольно гибкий, часто встречающийся в фраемворках.
Имеем в root сервера
  • drupal — базовые файлы движка
    • includes — файлы ядра
    • modules — модули и тд
  • sitename.ru — файлы сайта
    • includes — если искомый фаил существует в этой папке движок подключит его вместо системного
    • modules — если искомый фаил существует в этой папке движок подключит его вместо системного
    • index.php — отправная точка которая инклудит системный bootstrap фаил из папки drupal и запускает движок
Работает довольно просто, системный лоадер индексирует все пути и файлы движка, после кеширует их. Что происходит далее?
При иницилизации системы для sitename.ru и запросе файла ( инклуда, как хотите так и называйте ), фаил сначала ищится в директории sitename.ru, если он отсутствует то подключается из папки drupal.
Какой гибкости можно добиться таким способом?
Фактически можно будет хакать любой фаил движка, просто создав его в папке sitename.ru
Решается проблема с добавлением форумов и всякого рода подобных скриптов.
Добавляется возможность иметь для каждого сайта свои robots.txt и .htaccess
При рассмотрении данного способа на шаред хостинге возникает одна проблема, если на хостинге отключена поддержка создания папок для доменов и всё адресуется в одну конкретную папку
Автор
admin admin time 17:43 ← 09 января 2010 #
Спасибо, отличная информация к размышлению.
JiLiZART JiLiZART time 19:28 ← 09 января 2010 #
реализацию инклудера можно сделать подтипа Yii — system.core, module.global и тд =)
Freem Freem time 07:56 ← 10 января 2010 #
А проблему 1, 2, 3 разве нельзя решить с помощью rewrite в .htaccess, перенаправляя запросы в заранее определенное направление?
JiLiZART JiLiZART time 15:27 ← 11 января 2010 #
Безусловно можно, но как быть если рассматривать ситуацию с рядовым пользователем?
brown_medved brown_medved time 13:33 ← 12 января 2010 #
Придётся ли для поддержки мультисайтовости вносить какие-либо (даже минимальные) изменения в уже существующие шестерёнки или же этим займётся сам движок?
Насколько вообще нужен мультисайтинг? Не проще ли ставить отдельный движок для каждого сайта? С одной стороны, если на одном движке будет работать сразу несколько сайтов, то их немного проще будет администрировать, но с другой, если на движке с поддержкой мултисайтинга ставить только один сайт, то будут происходить лишние запросы в БД, и какие-то иные действия с файлами и папками, по сути не нужные для одного сайта. Или я не прав?
Автор
admin admin time 14:03 ← 12 января 2010 #
Не правы, потому что на производительности это не скажется точно.
Кому-то он может и не понадобиться как таковой, но вот преимущества — налицо.
По поводу изменений — речь идет о новом движке, о второй версии cogear.
dqpb dqpb time 14:48 ← 12 января 2010 #
Стоп, стоп, стоп. Хорошо вторя версия движка, а то что мы нарабатываем сейчас? Я так понял из диалога нынешние шестеренки прикурят в сторонке? :) Это очень и очень плохо! Дайте надежду что шестеренки будут подстраиваться или незначительно переделываьтся — адаптироваться!
Автор
admin admin time 17:18 ← 12 января 2010 #
Если говорить о расширении возможностей, то структуру по-любому следует менять на более прогрессивную.
Можно отдельно развивать текущую ветку движка.
JiLiZART JiLiZART time 19:10 ← 12 января 2010 #
Как никрути но насколько мне известно если даже сделают адаптацию, то JS составляющую всёравно придётся переписывать.
dqpb dqpb time 04:54 ← 13 января 2010 #
Это понятно, главное минимум переделок!
JiLiZART JiLiZART time 14:59 ← 13 января 2010 #
Что лучше?
Cделать Лексус или Сделать похожую на Ладу Калину тачку, чтобы запчасти с Калины подходили на новую тачку?

ЗЫ
Ничего не имею против Отеч. Производителя.
budulay budulay time 22:23 ← 20 января 2010 #
На мой взгляд, единственным модульными движком с нормально реализованной мультисайтовостью является Drupal, поэтому рассмотрим мультисайтовость на примере этой системы.

а как же ExpressionEngine от разработчиков CI (новая бета ЕЕ2.0 сделана как раз на CI)? у них настройки сайтов храняться в БД, все модули-плагины расширения для всех сайтов в одном каталоге и не нужно ничего распихивать по каталогам… жаль только что система платная ((
Автор
admin admin time 22:25 ← 20 января 2010 #
Верно, у нас речь идет об OpenSource.