Будут использованы сайты aaa.ru и bbb.ru находящиеся в мультисайтинговой связке. А так же адреса на которых сайты разрабатывались zzz.ru, т.е. aaa.zzz.ru и bbb.zzz.ru Первое отличие от D6 это возможность задать название папки не по домену. Копируем файл sites/example.sites.php в sites/sites.php и прописываем соответствия.
$sites['aaa.zzz.ru'] = 'aaa.ru';
$sites['bbb.ru'] = 'bbb.ru';
$sites['bbb.zzz.ru'] = 'bbb.ru';
Как видим, теперь не надо будет менять пути при переносе сайта, а также рыться в базе чтобы поправить все ссылки. По сравнению с D6 очень удобно, то что может быть у каждого сайта своя база, и даже не одна, например, один из вариантов, вынести все переводы в отдельную базу. Так же перенос и отделение от мультисайтинга значительно облегчится.
'default' =>
array (
'default' =>
array (
'database' => 'd7_aaa',
'username' => 'd7_aaa_u',
'password' => '<ваш-пароль>',
'host' => 'localhost',
'port' => '',
'driver' => 'mysql',
'prefix' => array(
'default' => '',
'locales_source' => 'd7_shared_locales.',
'locales_target' => 'd7_shared_locales.',
),
),
),
);
Комментарии
Кто мешает на D6 разные базы для сайтов сделать. в каталог каждого отдельного сайта в мультисайтинге помещаем свой settings.php и все. Точно также можно таблицы объединять с разными базами. Разница косметическая, а не принципиальная.
б
вай. вкусна. не знал. спасибо полезно.
тут пришлось изза идиотов любящих мультисайтинг править system чтобы проект отлаживать локально, а ведь могло обойтись без этого. правда это в Д6
Вообще-то мультисайтинг нужен на 90% сайтов, даже если сайт только 1, т.к. технический сайт облегчает основной на 20% примерно, это важно понимать. «Вы не любете кошек, вы просто не умеете их готовить!»
to Master of Tragedy
Я что то не знал что можно задать разные базы для одного сайта... можно подробнее... Я писал только об обноруженных мною изменениях, и насколько я знаю и как я делаю это 2 сайта с одной базой... а в семёрке по данной схеме у меня 2 сайта с 3-мя базами... Может это с какой-то версии пошло например 6.14? Если есть линк на орг сайт то можно линк в студию? Уж очень интересно... т.к. на текущий момент на одной из связок в базе таблицы измеряются тысячами...
зачем? вот brainstorm.name и brainstormblogger.org в мультисайте сидят.
да. на то есть причина - один сервер + один и тот же код пхп не кеширует дважды.
а если сайт ОДИН? нахрена этот паровоз?
+в 6ке локальная отладка на локалхосте превращается в пляски с бубном - когда в либо делаются доп. симлинки, переброс файлов. либо правка таблицы system + написание скрипта который выполняет затем menu_rebuild()
Охренительные преимущества епта.
хотя в 7ке соответсвие папок даст возможность этих плясок избежать - прописать их в локальном конфиге.
- для 6ки - нет.
и кстати насчет 7ки я тоже не уверен. таблица system с путями пуд своего гавна внесет скорее всего. в общем если проект сложный и сайт один - мультисайтинг - зло.
этот ваш мультисайтинг часто дает ситуации, когда локально нельзя тупо поднять свежий дамп и надо трахаться. а я предпочитаю моделировать проблемы с сайтом локально и посему оно часто время жрет.
а для говносайтов с готовыми модулями - я не возражаю.
как программисту мне эта "фича" чаще мешает чем помогает.
+ например мне не нравится files закопаный хуй знает куда в каталоге сайтов. приходится каждый раз для мультисайта прописывать его в переменную чтобы файлы легли в корень. site1.files site2.files а не sites/хуйзнаитгдетотам/files
разница наверное есть, да?
В общем в случае односайтовых ситуаций - мое мнение - не нужно.
есть ситуация. берем сайт. скидываем на локалхост. скармливаем дамп mysql
прописав settings.php получаем вставшую враскоряку хуйню, пока не разберемся с модулями сваленными "в отдельную папку данного домена".
пути туда прописываются железобетонно в таблице system но при этом drupal пытается подхватить модули из sites/all/modules/*
а их там просто нет.
поднял дамп, первй запуск скрипта наводит еще больше геммороя в БД.![Smile](https://drupal.ru/sites/all/modules/contrib/smiley/packs/kolobok/smile.gif)
я все конечно разобрал подключил привел в божий вид.
НО. вопрос.
1) нахрен мне надо чтобы на хостинге и на локалхосте оно работало ПО РАЗНОМУ
2) кто мне будет оплачивать время на новое пересоздание симлинков локально, изменение путей в таблице system и запуск скрипта, содержащего menu_rebuild () дабы перестроить меню первым делом(а то бля модули не подхватятся), затем перестроить кеш темы(а то с той стороны тоже будет отсос)
3) зачем рядовому программисту знать столько внутренних кишок друпала с которыми он напрямик практически не работает
4) и наконец. что мне делать, если что-то пойдет не так изза того что пути разные и на боевом серваке встало раком то, что локальном отладку прошло? и так тоже БЫВАЕТ
Все вышеперечисленное - это доп. время к разработке.
Плюс последний клиент сам был не проч поставить сайт локально и поиграться с денвером. а тут оппа. мультисайт. нифффстает.
Короче, когда оно не надо сайт - ОДИН - оно просто не надо.
насчет не умеете готовить - в 6ке оно побеждается при программерских/верстальных работах как я описал выше. это ВРЕМЯ
т.е. ваши проблемы разработки, которые есть только 1 раз важнее чем скорость загрузки, вместо 6 сек получаем 5сек... этим всё сказано... если у вас проект не такой уж и сложный и грузиться 1 сек, то это другое дело, но даже тут вместо 1 сек получить 0.8 очень даже заманчиво...
Вы абсолютно не понимаете зачем это надо, т.е. пользователи одного сайта например админ получит доступ к файлам например через IMCE чужого сайта и поудаляет всё??? вы очень плохо понимаете зачем нужен мультисайтинг...
Это действительно ваше мнение, которое очень далеко находится от реальности...
Кривые руки
Так настройте локал хост правильно... Неумение, это ваша личная проблема... почему нельзя подменить хост????? делов на 1 мин...
Учите мат часть, 1 мин времени, можете её в смету включить ни один заказчик не откажется её оплатить
to Ильич Рамирес Санчес
это даже не описание а чисто разница D6 и D7 увиденная мною при переходе...
Вы превращаете мою тему в мусорку, не знаете мат части не пишите, заголовок про мультисайтнг, значит для тех кто знает что это такое
если у меня будет админский доступ к мультисайтингу - полагаю imce будет не нужен вообще.
и похрен где будут files.
у меня для каждого сайта files - РАЗНЫЕ каталоги но они в корне. а не закопаны в sites/all
опять же вопрос удобства
для одного:
$conf = array(
'maintenance_theme' => 'brainstorm', 'file_directory_path' =>'b.n.files',
);
Для другого:
$conf = array(
'file_directory_path'=>'bb.org_files',
);
я то ее знаю.
для односайтовой схемы в этом смысла нет.
для мультисайтовой - возможно есть - если группы сайтов - "свои".
ЗАЧЕМ?
sitename в 127.0.0.1 ?
хотя бы потому, что это дилетантство
кстати раз пошла такая пьянка и пошла тема мусора в этом треде![Smile](https://drupal.ru/sites/all/modules/contrib/smiley/packs/kolobok/smile.gif)
аффтар, я реквестирую описание полей глобальной переменной $conf
Полная памятка была бы пользительна.
Очень надо порой при мультисайтинге и не только.
http://brainstorm.name/blog/drupal-global-conf.html это та малость что я накопал для себя и применяю.
лень не позволяет двигацо дальше в познании других штуковин
В общим реквестирую статью о содержимом $conf
Вообще затею поддерживаю. будет место куда всех можно будет посылать.
И этого вы не знаете, тогда не нужно будет пути менять они остануться темиже что и на серваке, ещё раз повторюсь настройка локал хоста это мат часть... Вот изучайте, иначе и будете дальше жить в неведении, что всё легко делается...
Админский не означает доступ супер пользователя!!!
135 раз повторю, разница в скорости... Видимо не повезло вашим заказчикам, или вы делаете ну очень простые сайты... то что сайт 1 не означает что он будет быстро работать...
Я как раз попрошу этого не делать, всё ещё хочу услышать ответ от Master of Tragedy, т.к. это мне интересно, в отличии от разжевывания мат части для 1 человека, который не хочет слушать...
для одного сайта будет влиять на скорость то что его модули и темы переложили в другую папку?
LOL
может мы имеем в виду разное?
я имею ввиду ситуацию когда сайт один на сервере.
короче спор ни о чем. насчет
фаллометрииквалификации - вот мой акк на д.орг. http://drupal.org/user/204617И я все же реквестирую от вас хорошую годную статью по содержимому $conf
Пойду спать.
он либо имел ввиду то что можно также их вместе с префиксами таблиц проставлять в рамках одного сервака, если общий пароль логин. а вот для случая разных акков в СУБД и разных серверов - простого решения нет
Понял. умолкаю.
Тут уж совсем непонятно, кто чего имел ввиду. Я имел ввиду, что в мультисайтинге на одной копии дистрибутива в подкаталогах sites/site1, sites/site2 можно завести отдельный конфиг для каждого сайта в мультисайтинге. В чем проблема при установке второго сайта указать разные бд? Или я чего-то не понимаю? Естественно, я имел ввиду, что все находится на одном сервере. Как у меня, но опять же достаточно в конфиге слейва прописать настройки для подключения к бд с логином и паролем. Проблема разве что в расшаривании таблиц на разных серверах.
Это к чему и зачем? У меня на девелоперском сервере DNS стоит и рулит всеми вирт.хостам апача. Я его ставил как раз для того, чтобы не было гемороя с /etc/hosts для каждого сайта. Нафига там что-то трогать опять?
to Master of Tragedy
Если сейчас не брать во внимание разговор с Ильич Рамирес Санчес, где обсуждались другие вещи, а не то что написано в топике...
То я имел ввиду следующее, у меня в связке n сайтов, и число n увеличивается не быстро но всё же...
Теперь можно сделать у каждого сайта свою бд (имеется ввиду со своим юзером и паролем, вариант входить из под рута сразу в топку), но при этом как сделать чтобы все сайты брали переводы из другой бд (не относящейся к установкам)... Я описывал именно это отличие D6 и D7 в D7 теперь это просто и понятно... а для D6 я не знаю решения чтобы было именно просто... Это не значит что его нет, возможно я о нём просто не знаю.
to Ильич Рамирес Санчес
Сначала сделайте стресс тесты и вы поймёте как разделение влияет... всё что нагружает основной сайт должно быть вынесено на технический сайт, вы просто говорите о сайте который самодостаточен, сделаете технический который будет дублировать функции... О да тогда только медленнее всё станет... Разговор о разгрузке, т.е. часть функционала не будет на основном сайте, что уменьшит время выполнения скриптов. Вы просто не работали с высоко нагруженными системами, и системами заведомо большими требованиями чем 1 машина...
ну вам виднее с чем я работал
Аффтар я все еще реквестирую описание нутра $conf. Как раз для мультисайтинга бывает иногда очень надо.
На сколько я понимаю, метод предложенный автором будет работать при условиях:
А. Обе базы находятся на одном хосте
Б. Пользователь у этих баз один и тот же
В связи с этим продолжу обсуждение вопросом.
Как связать два автономных сайта Drupal 7 с базой пользователей находящейся на другом хосте?
Имеем:
Хост Калининград - отдельный сайт/портал/хост
Хост Новосибирск - просто база с пользователями/отдельный хост
Хост Владивосток - отдельный сайт/портал/хост
База Калининград - kg_base, отдельный хост/пользователь
База Новосибирск - ns_base, отдельный хост/пользователь
База Владивосток - ww_base, отдельный хост/пользователь
В базе Новосибирск лежат таблицы ns_users и ns_sessions
В базах Калининград и Владивосток лежат таблицы с автономными данными, префикс которых kg_ и ww_ соответственно.
Просьба, разжуйте мне запись, которую надо внести в settings.php сайтов Калининград и Владивосток, чтобы они могли работать с пользователями из базы Новосибирск.
Уже вся задница в мыле, от поисков в международном хаосе друповодов. Не принимайте правду за критику.
Ну вообще-то пользователи разные, но действительно всё на 1 машине.
По вашей проблеме, так сделать нельзя, но можно немного сложнее...
<?php
$databases = array (
'default' =>
array (
'default' =>
array (
'database' => 'drupal7',
'username' => 'root',
'password' => '<your-password>',
'host' => 'localhost',
'port' => '',
'driver' => 'mysql',
'prefix' => '',
),
),'custom' =>
array (
'default' =>
array (
'database' => 'custom',
'username' => 'root',
'password' => '<your-password>',
'host' => 'localhost',
'port' => '',
'driver' => 'mysql',
'prefix' => '',
)
)
);
?>
Но нужно прописывать db_set_active('custom'); или db_set_active('default'); например в начале каждого модуля... это конечно изврат, но ничего умнее в голову не приходит...