Мультисайтинг в Drupal

[nes]

Прямо «с языка» тему сняли. Но у Вас тема более полная чем мой черновик.
Спасибо!

[EzS]

В копилку вам:

Мультисайтинг

Введение в мультисайтинг
Базы данных в мультисайтинге
Модули и темы
Работа с файлами

[Mushtat]

Подобное может быть реализовано простым образом не только на друпале.

[Mushtat]

И добро пожаловать на Хабр! :)

[qindman]

Возможно вы и правы, но в исвестных мне CMS/CMF подобное не может быть реализовано простым образом :)

[pvasili]

бравться — поправьте

Забыли добавить:
— про обновления модулей и тем. Нужно быть внимательным при обновлении модулей в папке /sites/all (обязательно запускать update.php на всех доменах, использующих эту папку).
— что будет вначале браться из /sites/all/modules или /sites/site.ru/modules
— обновления через drush

[andyceo]

А для этого я написал скриптик и теперь проблемы в прошлом.

github.com/andyceo/bash_scripts/blob/master/drushupdb.sh

[qindman]

Спасибо, исправился :)

[qindman]

Предыдущий комментарий, конечно, относился к pvasili.
andyceo, вам за скрипт отдельное спасибо!

[takeit]

Кстати, если сайтов довольно много, можно ли настроить 1 общий крон?
Или на каждый прописывать отдельно?

[qindman]

Cron лучше настраивать для каждого сайта отдельно.

[shuba]

В версии 7 директории уже не нужно называть по именам доменов.
Если в 6 версии нужно было создавать:
sites/example1.com
sites/example2.com
То в семерке:
sites/example1
sites/example2
и в файле sites.php прописать:
<?php
$sites = array(
'example1.com' => 'example1',
'example2.com' => 'example2',
);
?>

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

А для 6 есть патч.

[Schavelev]

У меня вполне отлично 20 сайтов в одной БД (около 250 таблиц) — суммарный трафик не большой, но проблем вообще никаких пока. Когда вырастет нагрузка — всегда можно перенести в отдельную базу.
Опытным путем определил для себя таблицы, которые можно делать общими (Drupal 6):

default, access, actions, actions_aid, authmap, imagecache_action, imagecache_preset, filter_formats, languages, locales_source, locales_target, l10n_update_file, l10n_update_project, permission, role, sessions, term_data, term_hierarchy, term_relation, term_synonym, users, users_roles, vocabulary, watchdog, wysiwyg, wysiwyg_user.

Скорее всего какие-то из них не стоило делать общими (например, модуль Database logging, включенный по-умолчанию, ругается на watchdog — но я его выключаю — чтобы не плодить лишних таблиц). Особенно удобны переводы, настройки wysiwyg и профили imagecache. Но на практике проблем не возникает пока.

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

[azovsky]

Добавлю.
Для управления контентом на мулитисайте удобно пользоваться модулем Domain Access.

[qindman]

Да, модуль интересный. Я правильно понял, что он может использоваться только на одной общей базе с разделением «собственных» таблиц сайтов с помощью префиксов?

[shevgeny]

давно искал внятную статью о мультисайтинге в друпал +1

[brmn]

Если вы используете различные темы для сайтов, то не мешало бы определить их напрямую в settings.php и настроить выполнение регулярных процедур cron.php минимум на раз в сутки.

[qindman]

Вам приходилось сталкиваться с проблемами с этим связанными? Чем обусловлена необходимость выполнения крона раз в сутки?

[brmn]

Именно из-за проблем, связанных с «отваливанием» тем, пришлось искать выход в «кроне».
В деталях не разбирался, ибо другие задачи подгоняют.

[brmn]

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

[scoff]

В мультисайтинге Друпала есть одно неприятное свойство — трудно переименовать «не главные» сайты. Допустим, был сайт на поддомене, надо перенсти на домен 2го уровня (example.com.ru —> example.ru) или из папки на домен (exammple.ru.subsite —>example2.ru). Эти строчки в пути (sites/example.com.ru/...) хранятся в контенте (картинки) в файлах (таблица files) и нет легкого способа их изменить. Это если mysqldump не относить к легким, но и тогда будут проблемы (google/yandex image search, например, потеряют ваши картинки). Основной сайт (default) — никаких проблем, ему вообще все равно какой у него адрес.

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

[brmn]

а если определить хранилище файлов в корне сайта /files?

[scoff]

можно, наверно, но это надо делать заранее, по факту уже поздно метаться.
ну и это нарушает концепцию «весь сайт в одной папке»

[pvasili]

Естественно заранее думать нужно :)
Если вы меняете поддомены то: в любом случае, контент у вас будет для поисковиков на другом сайте([суб]домене). Пока оно там ещё будет отзеркалено, да ещё и правильно, да ещё и будет определено главное зеркало правильно…
При создании нового сайта, лучше менять сразу папку статики и temp на что-нибудь не привязанное к имени или организовывать CDN.

Сейчас можете в папке /sites/example.com.ru убрать settings.php, а всю статику оставить. Ваша старая статика будет видна по своим старым путям. Для нового — сделайте новую и пропишите к ней путь в /admin/settings/file-system.
Можно попробовать оставить 2 домена в мультисайтинге(если нужно старое сохранить) с общими таблицами, только нужно настроить запрет создания материалов из старого поддомена (поиграть с ролями в разных доменах). Тут уж на что фантазии хватит :).

[edhell]

Есть проблема с безопасностью: если взломан один сайт (или там завёлся недобросовестный админ), через него взламываются все остальные.