24 июня 2007 в 23:41
Импульсом к написанию этой статьи стала потребность в мультисайтинге, идеей чего я озаботился сразу после прочтения статей
Мультисайтинг – как и зачем , автор jerboa7,
Мультисайтинг - это просто, автор Макс Кириленко,
а чуть позже к ним присоединился и Mультисайтинг. В который раз. 
автора andron13
и усвоил мысль, что если хочешь потом сделать мультисайтинг, то лучше его делать сразу.
Базовые вещи, которые необходимо знать для того чтобы организовать мультисайтинг на Друпале, я почерпнул из вышеуказаных статей. Поэтому подробно останавливаться на самом процессе, я не буду. Просто позволю себе написать еще одну статью о мультисайтинге.
1. Установка Друпал
Паркуем на хостинг наш домен сайт1. Этот домен будет указывать на какую-то директорию на Вашем сайте, которая для него будет являться базовой. В эту директорию на хостинге копируем Друпал - распаковываем его из архива.
Заводим новую БД на хостинге. Ее будет использовать Друпал. Завели? Теперь у нас есть База Данных:
Имя БД: БД_сайт1
Пользователь БД: юзер_БД_сайт1
Пароль пользователя: пароль_БД_сайт1
У пользователя юзер_БД_сайт1, само собой, должны быть выставлены привелегии, позволяющие ему полный доступ к базе данных БД_сайт1.
Также у Вас есть файл settings.php, находящийся в подпапке sites/default/settings.php. В нем прописываются все необходимые параметры базы данных, нужные для работы Друпал. Заполните его, в соответствии с инструкциями, расположенными в нем в комментариях, и описанными ниже.
Строка доступа к базе данных, выглядит так:
$db_url = 'mysql://юзер_БД_сайт1:пароль_БД_сайт1@localhost/БД_сайт1';
Еще мы должны задать префикс таблиц. Это означает, в самом простом случае, что к имени таблицы в БД будет приписываться в начале некий префикс:
$db_prefix = 'префикссайт1_';
т.е. таблица с именем, скажем, sequences будет префикссайт1_sequences. Я рекомендую в конце префикса ставить знак подчеркивания "_", чтобы отделять префикс от собственно имени таблицы.
Префикс можно не задавать:
$db_prefix = '';
однако я не рекомендую этого делать. Подумайте о возможной SQL атаке? Или просто о попытках взломать ваш сервер. Хакеру не трудно будет догадаться, что Вы используете Друпал. Ну а с какими именами Друпал создает таблицы, тоже хорошо всем известно. Поэтому Вы затрудните доступ к Вашим таблицам, если вначале каждой пропишите префикс из случайной последовательности символов.
А теперь информация для самых ретивых: задавая префикс таблиц не в виде
$db_prefix = 'префикссайт1_';
а в виде
$db_prefix = 'префикссайт1.';
Вы на самом деле указываете Друпал, что он должен обращаться к базе данных "префикссайт1", вместо БД_сайт1! Поэтому будьте предусмотрительны при выборе разделителя префикса и имени таблицы. Самое удобное, на мой взгляд, использовать "_" - знак подчеркивания.
Однако и это еще не все о префиксах. Друпал позволяет для каждой из таблиц задать отдельный префикс. Выглядит это так:
$db_prefix = array (
'default' => 'main_',
'users' => 'shared_',
'sessions' => 'shared_',
'role' => 'shared_',
'authmap' => 'shared_',
'sequences' => 'shared_',
);
Зачем это надо? Если Вы ставите 1 сайт и уверены, что больше Вам никогда не понадобиться, то не забивайте себе голову. Ну позволяет это Друпал, ну и позволяет, Вам-то что?
Однако если когда-нибудь Вы запланируете поставить еще один сайт, (о чем и пойдет дальше речь), да так, чтобы не копировать еще раз все скрипты (ядро и модули), да чтобы использовать какую-нибудь информацию, которая у Вас уже есть в БД (например, переводы Друпала и модулей) - то эта возможность очень даже пригодится... Но обо всем по порядку.
Итак, сайт1 мы поставили, запустили, работает - все замечательно! И вот в один прекрасный день...
2. Возникает потребность в новом сайте на Друпале, хотим организовать его на том же хостинге. Имя сайта - сайт2.
Паркуем на хостинг наш новый домен сайт2. Домен должен указывать на ту директорию, в которую вы скопировали/поставили Друпал (в нашем примере - на директорию с сайт1).
Если после парковки домена при переходе на него мы попадаем на сайт1. (Так должно быть.)
Создаем директорию sites/сайт2, копируем в него файл settings.php и правим его в соответствии с нуждами нашего сайт2:
задаем параметры доступа к БД,
прописываем другой (не такой как у сайт1) префикс таблиц для сайт2.
Переходим опять по нашему новому адресу сайт2 - и видим, что Друпал сыпется ошибками. И правильно, ведь никаких таблиц в БД сейчас нет. В БД сейчас есть только таблицы для сайт1. Друпал думает, что у нас уже установлен сайт2, и пытается сгенерить главную страницу, но обламывается. Вот так вот, сгенерив страницу с ошибками, Друпал кэширует ее. если вы попробуете перейти опять по новому адресу, то увидите страницу с ошибками опять. Однако нам пока главная страница не нужна.
Перейдем на страницу установки Друпала для сайта2, т.е. перейдем на сайт2/install.php - скрипт установки отработает, создав нужные таблицы и прописав все необходимые свзяи между ними. Если какие-то таблицы уже существуют, они перезаписаны не будут, и никаких повреждений в них не будет, однако Друпал сообщит об ошибке при создании этих таблиц.
Перейдем на главную страницу свежесозданного сайта - сайт2. Видим опять всяческие сообщения об ошибке. Это отображается закэшированная ранее страница. Обновите ее - и о чудо! - видим первую страницу Друпала для сайта2 с инструкциями.
Т.е. у нас получилось два сайта, использующие одни и те же скрипты и одну и ту же БД, но разные таблицы в БД. Очень удобно.
А теперь помните, что если бы в качестве разделителя префикса таблиц указали не знак подчеркивания, "_", а точку - ".", то Друпал обращался бы не к базе данных "БД_сайт1", а к базе "префикссайт2"? Это можно использовать, если вы хотите чтобы для разных сайтов использовалась разная БД, но был один и тот же пользователь БД и пароль (такая задача часто возникает при объединении таблиц, о чем речь пойдет дальше). Конечно можно просто задать разные параметры для БД для сайт2.
Но давайте представим, что у Вас...
3. Возникает понимание, что некоторую информацию сайта1 и сайта2 неплохо бы объединить. Например сделать общих пользователей.
Вот здесь-то и проявляется вся гибкость и мощь Друпала, здесь-то мы и осознаем в полной мере, насколько удобно задавать разным таблицам разные префиксы, и как Друпал умеет работать с разными БД.
Сделать общим можно все! Начиная от пользователей и заканчивая документами (нодами). Но если общих пользователей я еще могу понять и принять, то делать общие документы между сайтами я не вижу смысла - тогда чем будет отличаться один сайт от другого? Только дизайном? Поэтому, после некоторого тестинга, я пришел к выводу, что объединить без ущерба нарушения целостности БД и психики можно:
1) Пользователей,
2) Роли пользователей и права ролей
3) Профили пользователей
4) Переводы ядра и модулей
5) Словари
6) Термины в словарях
7) Фильтры сообщений - насчет этого уже не уверен, т.к. таблица filter_formats привязывается к кэшу (поле cash), а таблица filters использует id фильтра из таблицы filter_formats, таким образом, обе таблицы фильтров привязаны к конкретному сайту.
Т.е. вообще все таблицы и модули, в которых нет жесткой привязки к документам (нодам).
Также сразу скажу, что задача объединения словарей и терминов в них (модуль таксономии) может возникнуть только на очень тесных и близких по тематике сайтах. Я объединил словари и попробовал использовать в таком режиме документы, это оказалось очень неудобным и нецелесообразным. Поэтому мы не будем это рассматривать в этой статье. Остальные же вещи, удалось объединить очень даже удобно.
Итак, чтобы сделать общих пользователей, нам нужно сделать для сайтов общие таблицы пользователей. Допустим, что у нас уже есть сайт1, и новый сайт сайт2, и мы осознали что неплохо было бы, если пользователь зарегистрировался на каком-либо из этих сайтов, имел бы доступ и к другому.
За пользователей у нас в Друпале отвечают следующие таблицы:
'authmap'
'sessions'
'sequences'
'users'
Таблица users - непосредственно хранит данные пользователя.
Таблица sequences - хранит служебную информацию Друпал. Для каждой таблицы, в sequences сохраняется ее имя, и следующее значение первичного ключа. (Если вообще планируете сделать что-то общее для каких-то двух сайтов, таблицу sequences рекомендую делать общей при любом раскладе).
Таблица sessions хранит информацию текущих сессий пользователя.
Таблица authmap я не знаю пока чего хранит.
Помимо вышеперечисленных таблиц, для пользователей существуют роли:
'role'
'users_roles'
При этом в таблице role хранится для каждого сайта информация о ролях пользователей, а в таблице users_roles - информация, какой пользователь к какой группе (роли) принадлежит. Скажу сразу, что если Вы хотите сделать так, чтобы роли для каждого сайта были абсолютно независимы, то Вам не нужно делать общей таблицу role. Таблицу users_roles можно сделать общей, если Вы делаете общих пользователей. Я же, потестив немного, нашел, что очень удоьно когда роли пользователей общие для всех сайтов, т.к. не нужно по 10, или сколько у вас там сайтов, раз заводить одни и те же роли: вот этим пользователям можно то, а этим это.
Profile module. Если у Вас включен модуль профилей для пользователей, тогда его таблицы тоже имеет смысл сделать общими:
'profile_fields' - хранит информацию о полях профиля
'profile_values' - хранит информацию поля.
Locale module. Модуль локализации. Одна из удобнейших возможностей - использовать общую таблицу локализации, т.к. переводы всего и вся можно залить один раз и потом просто выбирать из админки нужного сайта.
'locales_meta'
'locales_source'
'locales_target'
BUEditor Module. Это я привел чисто для примера. Любой модуль, не использующий привязку к документам, может быть объединен. Строго говоря, то же верно и для любого модуля, жекстко привязанного к документам, просто в нем надо найти таблицу связей для модуля и документов, и не делать ее общей. Для модуля BUEditor таких таблиц нет, поэто смело объединяем:
'bueditor_buttons'
'bueditor_editors'
Что нужно, чтобы использовать на сайт2 эти таблицы, которые уже поставлены и работают для сайт1? Ответ очень прост: надо просто прописать префикс сайт1 для этих таблиц: "префикссайт1_", в файле настроек settings.php для сайт2:
$db_prefix = array (
'default' => 'main_',
'authmap' => 'префикссайт1_',
'sessions' => 'префикссайт1_',
'sequences' => 'префикссайт1_',
'users' => 'префикссайт1_' и т.д. если объединять будете что либо кроме пользователей.
Также, сайт1 и сайт2 должны использовать одну и ту же БД.
Теперь из админки сайт2 доступны пользователи (и еще что-нибудь, если еще что-нибудь объединяли) сайт1. И пользователи на сайтах общие.
Все!
Ах да... еще одна деталь. Если Вы будете мультисайтить большое количество сайтов, то для этого может быть целесообразно разделить сайты по разным базам данных. В этом случае схема будет такой: создаем столько баз данных, сколько у нас сайтов, и еще одну общую (shared) и при этом пользователь для всех этих БД должен быть один и тот же. В качестве префиксов указываем префиксы с точкой, например так: "сайт1.". Т.е. в нашем случае можно сделать так:
БД с именем shared (общая для всех сайтов) -
'authmap'
'sessions'
'sequences'
'users'
'role'
'users_roles'
'profile_fields'
'profile_values'
'locales_meta'
'locales_source'
'locales_target'
'bueditor_buttons'
'bueditor_editors'
БД с именем сайт1 (БД для сайт1) -
содержит все таблицы, кроме тех, что в таблице shared
БД с именем сайт2 (БД для сайт2) -
содержит все таблицы, кроме тех, что в таблице shared
В файле settings.php Вы прописываете значения (для сайт1):
------------------------------------------------------
$db_url = 'mysql://юзер_БД:пароль_БДlocalhost/сайт1';
$db_prefix = array (
'default' => 'сайт1.',
'authmap' => 'shared.',
'sessions' => 'shared.',
'sequences' => 'shared.',
'users' => 'shared.',
//Роли общие
'role' => 'shared.',
'users_roles' => 'shared.',
//Profile module
'profile_fields' => 'shared.',
'profile_values' => 'shared.',
//Locale module :
'locales_meta' => 'shared.',
'locales_source' => 'shared.',
'locales_target' => 'shared.',
//BUEditor Module :
'bueditor_buttons' => 'shared.',
'bueditor_editors' => 'shared.'
);
------------------------------------------------------
Комментарии
задумался о списке строк в базе. и за что они отвечают. и о списке модулей и их следы в базе. может уже у кого есть?
задумался о списке строк в базе. и за что они отвечают. и о списке модулей и их следы в базе. может уже у кого есть?
Тоже задумывался. К сожалению, трудно найти именно техническую, программистскую документацию о Друпале или модулях. Если о Друпале еще есть, то о модулях практически ничего не известно. Приходится использовать какой-то reverse engineering
Вот это было очень полезной инфой, если действительно у кого-нибудь она есть.
Если смогу облечь в стройную форму статьи что накопал сам, конечно напишу об этом.
LabelMan пишет: Любой модуль, не использующий привязку к документам, может быть объединен. Строго говоря, то же верно и для любого модуля, жекстко привязанного к документам, просто в нем надо найти таблицу связей для модуля и документов, и не делать ее общей.
Это у Вас смелое заявление. Доводы против.
1. Модули могут хранить данные не только в таблицах, помеченных своим именем.
2. Модули при проектировании не предполагают, что их будут использовать в мультисайтовом варианте. Возможны самые неожиданные побочные эффекты. Например, при назначении синонима на одном сайте мультисайтовой связки может стать невозможным назначить подобный синоним на другом сайте из связки. Или при добавлении аватара на одном из сайтов связки второй сайт обнаружит запись в таблице о том что аватар есть, но самого аватара в своей папке не найдет. Никто не гарантирует, что в будущем в такой ситуации второй сайт просто удалит такую "неправильную" с его точки зрения запись.
Альтернатива
На мой взгляд, чем меньше объединяется таблиц, тем лучше. Самый безопасный и "зеленый" вариант мультисайтинга, это когда все сайты из связки живут порознь на своих собственных базах. А данные и пользователи объединяются через модули Друпала.
Объединять данные можно через RSS-канал (см. сообщение Мультисайтинг через RSS канал) или через модуль Leech.
Посетителей можно объединять через разрешение использовать логины с других друпаловских сайтов. На странице заведения нового пароля можно добавить пометку, что вместо заведения нового пароля допустимо использовать пароли от таких-то сайтов. И подсказать как они должны правильно быть написаны. Другой способ, поддержка авторизации через OpenID.
Клуб
Господа мультисайтеры, не пора ли на Drupal.ru сделать клуб мультисайтеров?
Для начала члены клуба могут поставить в свою подпись ссылку на свое сообщение о теме мультисайтинга. Это поможет пропаганде мультисайтинга в широких рядах друпальщиков.
1. Модули могут хранить данные не только в таблицах, помеченных своим именем.
Не задумывался о такой возможности, если честно. Наблюдая другие модули, я видел, что они стараются использовать только свои таблицы. Если бы я проектировал свой модуль, я бы тоже старался делать так.
Но наверное Вы правы, такие модули есть, и с мультисайтингом тогда будет не очень хорошо.
Здесь у меня просто другой подход... Я программист, и Друпал копаю где-то около месяца, в свободное от работы время. Я понял, что для успешного мультисайтинга, необходимо чтобы пространство первичных ключей в таблицах не перекрывалось. И все. И уж если я считаю, что способен поставить мультисайтинг, то способен разобраться где и что какой модуль делает и "химичит", и найти какое-нибудь решение.
Понятно что для людей-непрограммистов, разбираться нет ни времени, ни квалификации... Но тут уж, как говориться, программисту-программистово )
2. Модули при проектировании не предполагают, что их будут использовать в мультисайтовом варианте. Возможны самые неожиданные побочные эффекты.
На это заявление крыть нечем ) может быть, если у Вас опыта поболее, наверное Вы с этим сталкивались, я - нет. Столкнусь - напишу)
Альтернатива
На мой взгляд, чем меньше объединяется таблиц, тем лучше.
Конечно, для корректной спокойной работы сайтов так было бы лучше всего. И собственной спокойной жизни. Но я... как программист), могу написать какой-нибудь крон, который бы делал что-нибудь с пользователями. И тут мне как раз очень удобно, чтобы все было в одной таблице... так как писать в скрипте что надо пробежаться по еще там 10 таблицам с юзерами и что-то поделать, имхо не очень удобно.
В общем, извечная дилемма о пользователях и программистах.
А альтернативы у Вас хорошие.
LabelMan says: Наблюдая другие модули, я видел, что они стараются использовать только свои таблицы.
Модуль кроме своих таблиц может свободно сохранять результаты своего труда во многих других местах:
К сожалению, нет стандартного информационного файла в поставке модуля, где бы сообщалось обо всех местах, где модуль размещает или изменяет данные.
Впрочем, даже удаление следов своей работы и то большинство авторов модулей не заботится организовать. Обеспечивать информацией или возможность мультисайтинга авторы не будут тем более.
Неустойчивость решений с мультисайтингом
В силу внутренней логичности Друпала на нем просто организовать мультисайтинг. Но называть Друпал полноценным мультисайтовым движком я бы не рискнул. Вопросы мультисайтинга не учитываются ни при разработке Друпала, ни при разработке модулей. В любой момент Друпал может поменять свое API так, что продолжать поддерживать на нем мультисайтинг станет невозможным.
Единственное, что немного смягчает ситуацию с мультисайтингом, это существующая возможность в любой момент разделить сайты из связки и организовать им самостоятельное существование.
Большое спасибо за подробные статьи LabelMan'у, Максу, andron13 и jerboa7. Интересная тема, даже исключительно в учебных целях.
А что скажут уважаемые мультисайтеры о модуле multidomain?
займись:) мы с удовольствием почиатем статью. Я просто вроде свою поставленную задачу решил. и модуль пробовать нет времени.
Попробовал последний вариант с разделенными базами данных:
создал базу данных shared.
прописал префиксы в файле settings.php:
'sessions' => 'shared.',
'sequences' => 'shared.',
'users' => 'shared.',
'profile_fields' => 'shared.',
'profile_values' => 'shared.',
Установил друпал 5.2, он установил все таблицы в одну базу данных базу сайта1, база shared осталась пустая.
Тогда я вручную перетащил таблицы
authmap
sessions
sequences
users
profile_fields
profile_values
из базы сайта1 в базу shared и друпал выдал ошибку
user warning: Table 'site1.users' doesn't exist query: SELECT uid FROM users WHERE uid = 1 in E:\apache\www\site1\includes\database.mysql.inc on line 172.
Почему друпал не ищет в базе shared?
>Вопросы мультисайтинга не учитываются ни при разработке Друпала, ни при разработке модулей. В любой момент Друпал может поменять свое API так, что продолжать поддерживать на нем мультисайтинг станет невозможным.
какая чушь
gorr в комментариях settings.php все написано, то что вы пытаетесь сделать, это префиксы к таблицам. Для того, чтобы иметь отдельную базу для сайта, укажите это в $db_url.
You can optionally set prefixes for some or all database table names
by using the $db_prefix setting. If a prefix is specified, the table
name will be prepended with its value. Be sure to use valid database
characters only, usually alphanumeric and underscore. If no prefixes
are desired, leave it as an empty string ''.
*
To have all database names prefixed, set $db_prefix as a string:
*
$db_prefix = 'main_';
*
To provide prefixes for specific tables, set $db_prefix as an array.
The array's keys are the table names and the values are the prefixes.
The 'default' element holds the prefix for any tables not specified
elsewhere in the array.
Razgonka.ru
>Объединять данные можно через RSS-канал (см. сообщение Мультисайтинг через RSS канал) или через модуль Leech.
И на вашем сайте написано:
>Сообщения форума хранятся в таблице forum.
Да ну?
Вы странные вещи пишите. На пример site1.comments_cid я понимаю как база данных site1 таблица comments_cid.
А кто скажет, сделать мультисайтовость с разными серверами баз данных? Скольки ни пробовал - не получалось. Проблема в том, что у разных серверов разные адреса, а Друпал не позволяет указывать в одном конфиге разные адреса серверов, только разные таблицы.
Например, я хочу таблицу locales поместить вообще на другой сервер баз данных mysql, как мне это сделать? Имеется ввиду, что сайт один и мультисайтинг мне нужен для уменьшения нагрузки на базу данных.
На другом сервере вы не получите выигрыш. В любом случае общая производительность системы определяется самым медленным компонентом.
В вашем случае им будет канал связи, который по любому будет медленнее на пару порядков, чем процессы, крутящиеся на одном сервере.
Как минимум, следует сделать общей таблицу sequences - это даст возможность думать о дальнейшем наращивании использования общих таблиц. Я вопросом мультисайтовости заинтересовался после того, как всю ночь обновлял модули на трех разных своих сайтах. Прочитав это руководство осознал, что объединять бд мне уже поздно...
мне не нужна мультисайтовость в обычном понимании этого слова... мне нужна работа с разными серверами баз данных, аДрупал, по-видимому этого пока не умеет... в стандартной установке, естественно...
все сервера находятся в одном месте, поэтому проигрыша не будет... просто у всех серверов баз данных есть ограничение на количество коннектов к базе данных... хех, а две базы на одном сервере нельзя... только на разных...
zametka.
А что делать, если при переходе по адресу site2.site1.ru/install.php (второй сайт на поддомене, директория общая) Друпал говорит "Drupal already installed" ? т.е. таблицы с префиксом второго сайта не создаются.
Хм. У меня нет префиксов у таблиц сайта 1.
Если сайту 2 задать
, то скрипт install.php создает новые таблицы с этим префиксом и получается сайт 2 с отдельной БД. Но мне нужно только несколько отдельных таблиц для сайта 2, но вариант
'cache' => 'prefix_',
'blocks' => 'prefix_',
'comments' => 'prefix_',
и т.д.,
);
почему-то не работает - скрипт говорит "Drupal already installed" и не создает таблицы. А если зайти на сайт2, то отображается сайт1, но сверху куча ошибок о несуществующих таблицах 'databasename.prefix_cache' и т.д.
Может ли случиться, что 'префикссайт1.' будет обычным префиксом, а не путем к другой базе с этим же именем? PHP и MySQL самых последних версий.
Drupal6. Общие пользователи. Можно ли включить аватары не объединяя папки files?
Здравствуйте.
Прошу помочь разобраться с БД при использовании мультисайтинга Drupal.
У меня 3 сайта на хостенге РБК (C-Panel)
http://site1.ru – основной домен https://sites1.ru/public_html/sites/sites1.ru/settings.php
https://sites2.ru – дополнительный домен https://sites1.ru/public_html/sites/sites2.ru/settings.php
и https://sites3.ru – еще один дополнительный домен https://sites1.ru/public_html/sites/sites3.ru/settings.php
Drupal установлен https://sites1.ru/public_html/
Цель: У каждого сайта независимая БД + БД с именем «shared» общая для всех сайтов (в БД «shared» 'authmap'; 'sessions'; 'sequences'; 'users'; 'role'; 'users_roles'; 'profile_fields'; 'profile_values'; 'locales_meta'; 'locales_source'; 'locales_target'; 'bueditor_buttons'; 'bueditor_editors'). Sites1 и sites2 чистовой вариант, sites 3 – полигон для учебы и тестов (частые откаты БД и https://sites1.ru/public_html/sites/sites3.ru/).
Что происходит: http://sites1.ru + БД1 (sites1ru_sites1) были созданы неделю назад. Сайт запущен, но если сильно понадобиться, то можно переустановить (или откатить). https://sites1.ru/public_html/sites/sites1.ru/settings.php пока без моего вмешательства:
$db_url = 'mysql://sites1ru_юзерБД:парольlocalhost/sites1ru_имяБД';
$db_prefix = '';
Я не знаю какой вид имеют названия БД, юзерыБД и паролиБД на других хостах, но в РБК так:
БД - sites1ru_sites1; sites1ru_sites2; sites1ru_sites3; sites1ru_ shared
ЮзерБД - sites1ru_юзер
парольБД – sites1ru_пароль
Ну да это и не важно, суть не в этом.
Сейчас я создал БД2 (sites1ru_sites2), БД3 (sites1ru_sites3) и БД «shared» (sites1ru_ shared)
Подскажите:
1. Какая последовательность моих действий?
Я должен перевести sites1 в режим обслуживания и изменить https://sites1.ru/public_html/sites/sites1.ru/settings.php на
$db_url = 'mysql://sites1ru_юзерБД:парольlocalhost/sites1ru_имяБД';
$db_prefix = array (
'default' => 'sites1.',
'authmap' => 'sites1ru_ shared.',
'sessions' => 'sites1ru_ shared.',
'sequences' => 'sites1ru_ shared.',
'users' => 'sites1ru_ shared.',
//Роли общие
'role' => 'sites1ru_ shared.',
'users_roles' => 'sites1ru_ shared.',
//Profile module
'profile_fields' => 'sites1ru_ shared.',
'profile_values' => 'sites1ru_ shared.',
//Locale module :
'locales_meta' => 'sites1ru_ shared.',
'locales_source' => 'sites1ru_ shared.',
'locales_target' => 'sites1ru_ shared.',
//BUEditor Module :
'bueditor_buttons' => 'sites1ru_ shared.',
'bueditor_editors' => 'sites1ru_ shared.'
);
Больше ничего менять в settings.php ненужно?
2. Как перенести таблицы 'authmap'; 'sessions'; 'sequences'; 'users'; 'role'; 'users_roles'; 'profile_fields'; 'profile_values'; 'locales_meta'; 'locales_source'; 'locales_target'; 'bueditor_buttons'; 'bueditor_editors' из БД1 (sites1ru_sites1) в БД «shared» (sites1ru_ shared)?
3. Как ставить sites2? C чего начать? После чего (последовательность) править https://sites1.ru/public_html/sites/sites2.ru/settings.php и что именно в нем прописывать? Как в sites1?
Спасибо.
Отвечаю на свои вопросы
1. Переводить сайт в режим обслуживания ненужно.
! перед установкой сайтов, и первого, и последующих, в https://sites1.ru/public_html/sites/sites....ru/settings.php указываем префкс:
$db_url = 'mysql://username:password@localhost/databasename';
$db_prefix = 'ххх_'; <= ххх префикс для устанавливаемого сайта (у каждого свой)
После инсталляции сайта, редактируем – дописываем:
'authmap' => 'sites1ru_ shared.',
'sessions' => 'sites1ru_ shared.',
'sequences' => 'sites1ru_ shared.',
'users' => 'sites1ru_ shared.',
//Роли общие
'role' => 'sites1ru_ shared.',
'users_roles' => 'sites1ru_ shared.',
//Profile module
'profile_fields' => 'sites1ru_ shared.',
'profile_values' => 'sites1ru_ shared.',
//Locale module :
'locales_meta' => 'sites1ru_ shared.',
'locales_source' => 'sites1ru_ shared.',
'locales_target' => 'sites1ru_ shared.',
);
В принципе, больше ничего менять в settings.php ненужно
2. phpMyAdmin делаем экспорт в фаил. А из файла импорт в нужную таблицу.
3. В sites2, 3, и т.д. в settings.php делаем как и в sites1 последовательность та-же. Префикс $db_prefix = 'yyy_'; <= yyy_ у каждого сайта свой.
В общем остался только один вопрос: Как сделать префиксы в самой «base_shared»?
'locales_target' => '111_base_shared.'
'locales_target' => 'base_shared.111_'
или '111_locales_target' => 'base_shared.' у меня не получается
Спасибо
Автору огромное спасибо за статью!
Правда второй сайт не сразу получилось подцепить.... Появлялись ошибки на этапе Установки(что после определения БД).
Помог метод adm503 (огромное спасибо за ответы на свои же вопросы, в частности 1-ый помог лично мне)
===
Вопрос по производительности: можно на одной БД повесить 5-7 сайтов с разными префиксами? Какие у вас есть наблюдения по этому поводу?
Хех...
А вот что делать, когда из другой базьі - не работает?
<?php$db_prefix = array('default' => 'firsttbl.',
'locales_source' => 'secondtbl.',
'locales_target' => 'secondtbl.',
'languages' => 'secondtbl.',
);
?>
У пользователя есть доступ к обеим базам точно, ибо слияние баз в одну - работает, но вот в разньіх - нет...
Ошибка
Warning: You have an error IN your SQL syntax; CHECK the manual that corresponds TO your MySQL server version FOR the RIGHT syntax TO USE near 'firsttbl.access WHERE type = 'host' AND LOWER('my.ip.address.here') LIKE LOWER(ma' at line 1 query: SELECT 1 FROM firsttbl.access WHERE TYPE = 'host' AND LOWER('my.ip.address.here') LIKE LOWER(mask) AND STATUS = 0 LIMIT 0, 1 IN /path/TO/DATABASE.mysql.inc ON line 128«Но если общих пользователей я еще могу понять и принять, то делать общие документы между сайтами я не вижу смысла - тогда чем будет отличаться один сайт от другого? Только дизайном?»
У меня именно такой вариант, для мобильной версии сайта. Как сделать общую авторизацию, чтобы перейдя на поддомен pda.site.ru пользователям не приходилось заново авторизовываться?
все хорошо написано а как сделать безболезненно еще пару сайтов к работающему, в котором нет префикса бд?:)
все это круто работает - общие модули и т.п. а вот imagecache на дефолтном сайте норм работает а на сайте в папке фигу - кто сталкивался с такой проблемой?=(
Люди.......!)
Помогите бедному и несчастному.)
Насколько я понял в каталоге drupal.site\www\sites\sub.drupal.site\ мы создаем субдомен вида //sub.drupal.site/ по отношению к сайту //drupal.site/.
Для этого нам достаточно создать в каталоге drupal.site\www\sites\sub.drupal.site\
аналог drupal.site\www\sites\
с содержанием:
и мы получаем два сайта с одного движка с разными настройками, темами, блоками и модулями, юзерами
Что б объединить юзеров в файле drupal.site\www\sites\sub.drupal.site\settings.php пишем за какими таблицами в какую базу ходить. Вот тут опять вопросы, согласно Максу Кириленко, оптимальным является отдельная база для общих таблиц. Как правильно разобраться с указанием кому куда?
Собственно по Drupal вроде бы все если нет поправьте.)
Но не менее важным является вопрос Денвера (на хостинге под управлением cPanel таких проблем не возникнет - там есть для этого элемент меню который действует если хостер по тарифу дает субдомены) на оф. сайте ответ внятный для себя не нашел (хочется попробовать на локале перед выходом в мир, да и интересно). Теряюсь в догадках, но главная идея это редактирование файла Z:\usr\local\apache\conf\httpd.conf чемто вроде:
<VirtualHost www.mod.phone-line.ru:80>
ServerAdmin admin@phone-line.ru
ServerName www.mod.phone-line.ru
DocumentRoot "D:/sait/home/phone-line.ru/www/mod"
ScriptAlias /cgi/ "D:/sait/home/phone-line.ru/cgi/"
ErrorLog D:/sait/home/phone-line.ru/error.log
CustomLog D:/sait/home/phone-line.ru/access.log common
</VirtualHost>
Под свои требования!
Далее заходим в папку
C:\WINDOWS\system32\drivers\etc\hosts - открыть с помощью блокнота!
127.0.0.1 phone-line.ru
127.0.0.1 mod.phone-line.ru
Перезагрузить Апатч и все!!!
#<VirtualHost *:*>
# DocumentRootMatch "/home/(?!cgi-)(.*)^1/(?!cgi$|cgi-)(.*)"
#
# DocumentRootMatch "/home/(?!cgi-)(.*)^1/domains/(?!cgi$|cgi-)(.*)"
#
# DocumentRoot "$&"
#
# ServerName "%&"
#
# ServerAlias "%&/-www" "%&/-www/www"
#
# ScriptAlias /cgi/ "$^1/cgi/"
# ScriptAlias /cgi-bin/ "$^1/cgi-bin/"
#
# ErrorLog "$^1/error.log"
#</VirtualHost>
#КОНЕЦ ШАБЛОНА.
Всем спасибо за внимание и еще большее за помощь!)
Все твои друпалы могут дружно зить в одной базе.
Да. И не забудь поменять префикс таблиц.
бесполезно
Только если из не должно быть в другиз сайтах. Общие темы и модули в /sites/all
Ни в коем разе!
Дарю фрагмент htpd.conf
<?php<VirtualHost 127.0.0.1:*>DocumentRoot "/home/drupal6/www/"
ServerName "d6"
ServerAlias d6 *.d6
ScriptAlias /cgi/ "/home/drupal6/cgi/"
ScriptAlias /cgi-bin/ "/home/drupal6/cgi-bin/"
ErrorLog "/home/drupal6/error.log"
</VirtualHost>
?>
Теперь для создания "сайта" anything.d6 достаточно создать каталог /home/d6/anything. При этом все сайты *.d6 лежат в /home/drupal6/www/
А, в таком случае, я смогу разные темы для разных сайтов сделать по умолчанию? Или придется настраивать с помощью модуля, это все, на всех сайтах?(
fasdalf@fasdalf.ru, а как тогда инсталлировать сайт? Просто выполнить вышеперечисленные действия + создать наполненную "БД" изменив в ней префикс
Но тут сказано что нужна инсталляция!) Значит скрипт отработает из корня?)
Если объединить пользователей между n сайтами то и все инфа об этих пользователях для всех сайтов будет одинакова:
А как быть с данными с разных сайтов:
они будут отображаться в профиле пользователя с любого сайта, или тут нужно четко отслеживать таблицы?
это если надо сделать тему совсем недоступной для админа другого сайта. сначала положи всё в sites/all
прописать основной префикс талблиц, запустить install.php а потом настроить шаринг.
они будут отображаться в профиле пользователя с любого сайта, или тут нужно четко отслеживать таблицы?
Посмотри таблицы сам. phpmyadmin тебе в помощь.
phpmyadmin штука классная.) Так понимаю просто внимательно посмотреть что за что отвечает(сразу вопрос, в каких файлах, какую строку искать, что б посмотреть на какую "БД" ссылается функция, модуль,....).)
А можно по подробней:
"
Могу ли я сделать следующим образом:
DocumentRoot "/home/drupal.site/www/sites/"
ServerName "drupal.site"
ServerAlias drupal.site *.drupal.site
ScriptAlias /cgi/ "/home/drupal.site/www/cgi/"
ScriptAlias /cgi-bin/ "/home/drupal.site/www/cgi-bin/"
ErrorLog "/home/drupal.site/www/error.log"
</VirtualHost>
?>
Что б получить для создания "сайта" anything.drupal.site достаточно создать каталог /home/drupal.site/anything. При этом все сайты *.drupal.site лежат в /home/drupal.site/www/sites/
"
Глупость сказанул не подумав. (редакция сообщения)
P.S.
Надеюсь это для окон и денвера правильно а то я читал что только UNIX понимают "символические ссылки" или "симлинки", хочу переехать на Linux полностью, а это вроде они?)
Ссылки делать таки можно видео по этому вопросу (редакция сообщения)
Спасибо огромное за внимание, удачного дня и начинаний!)
что такое шарингTable sharing - он же - общие таблицы.
Как запустить install.php по адресу sub.drupal.site/install.phpОткрыть http://sub.drupal.site/install.php не пробовал?
Могу ли я сделать следующим образом:Можешь. Разрешаю.
ПыСы Тут симлинками и не пахнет, а в друпал и линукс без знания английского лучшене лезть.
За терпение и советы спасибо. Нет пока, не пробовал, ковыряю теорию в разных направлениях - какое больше подходит для решения задач.
Но собственно все это в рамках абсолютного, личного, интереса.
Да и главное в программисты я не лезу, тяну максимум на дизайнера. Просто хочу разобраться: что, как и за чем делаю. Понемногу читаю соответствующую литературу, да и посвятил этому пока всего пол года. Так что к английскому, сленгу, и программным языкам пока только привыкаю (образование у меня то архитектурное).
Видео по вопросам мультисайтинга:
Если я правильно понял то суть алиаса в том что запрос по домену вида sub.drupal.site переадресовывался на drupal.site, а там все стандартно ищем папку sites только вместо default идем в sub.drupal.site.
Поскольку шаблон файла httpd.conf отвечает только за поиск директории соответствующей домену. То начиная с каталога www, корня сайта с доменом drupal.site, именно Друпал выбирает в каталоге sites папку которая соответствует домену по которому осуществляется запрос пользователя: sub.drupal.site или drupal.site.
Это значит что объем работ который требуется провести с Друпалом:
Работы которые нужно выполнить с сервером:
панели управления хостингом зарегистрировать поддомен и прописать этот поддомен как алиас.
Для Денвера возможен вариант с ссылками Seo и бульба, либо код в httpd.conf любезно предоставленный fasdalf@fasdalf.ru.
DocumentRoot "/home/drupal6/www/"
ServerName "d6"
ServerAlias d6 *.d6
ScriptAlias /cgi/ "/home/drupal6/cgi/"
ScriptAlias /cgi-bin/ "/home/drupal6/cgi-bin/"
ErrorLog "/home/drupal6/error.log"
</VirtualHost>
Ура-а!
Что могу сказать, мультисайтинг с разных инсталляций получается, и попыток сделал всего ничего. До первой удачи всего 3. Огромное вам спасибо!
Но возникла проблема:
$db_url = 'mysqli://root@localhost/drupal1';
$db_prefix = 'zxcv_';
$db_prefix = array(
'default' => 'drupal1.zxcv_',
'access' => 'drupal.zxcv_',
'authmap' => 'drupal.zxcv_',
'filter_formats' => 'drupal.zxcv_',
'filters' => 'drupal.zxcv_',
'locales_meta' => 'drupal.zxcv_',
'locales_source' => 'drupal.zxcv_',
'locales_target' => 'drupal.zxcv_',
'permission' => 'drupal.zxcv_',
'role' => 'drupal.zxcv_',
'sessions' => 'drupal.zxcv_',
'users' => 'drupal.zxcv_',
'users_roles' => 'drupal.zxcv_',
'profile_fields' => 'drupal.zxcv_',
'profile_values' => 'drupal.zxcv_',
);
/**
таблицы создаются без префикса. есть какие-то нюансы? (Таблица уже отредактирована вопрос не актуален)
Потому что писать надо "drupal.zxcv_"
Спасибо!
Но тогда префикс поставиться и в drupal1, и в drupal?
Или только в бд "drupal"?
Или для создания таблиц с префиксами в двух базах есть какая-то премудрость?
Просто когда пишете "." - это разделитель названия БД и таблицы... Если после названия БД вы не написали ничего - то и получаете без префикса. Тем более вы же переменную переопределили - имя то одно и тоже что у первой строки , что у второго массива
Спасибо, будем вникать!
Получилось запустить и с одной группой скриптов. Так что все работает, Все коды приведенные в моем предыдущем посте правильны.
Для создания префикса нужно только указывать переменную "имя_бд.префикс_" во всех пунктах (за столь полезный совет огромное спасибо Softovick).
nginx надо как-то особенно настраивать под мультисайтинг, кто знает?
Главное правильно воспроизвести Rewrite-правила и указать верные алиасы основного домена.
это да