Будут использованы сайты 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/*
а их там просто нет.
поднял дамп, первй запуск скрипта наводит еще больше геммороя в БД.
я все конечно разобрал подключил привел в божий вид.
НО. вопрос.
1) нахрен мне надо чтобы на хостинге и на локалхосте оно работало ПО РАЗНОМУ
2) кто мне будет оплачивать время на новое пересоздание симлинков локально, изменение путей в таблице system и запуск скрипта, содержащего menu_rebuild () дабы перестроить меню первым делом(а то бля модули не подхватятся), затем перестроить кеш темы(а то с той стороны тоже будет отсос)
3) зачем рядовому программисту знать столько внутренних кишок друпала с которыми он напрямик практически не работает
4) и наконец. что мне делать, если что-то пойдет не так изза того что пути разные и на боевом серваке встало раком то, что локальном отладку прошло? и так тоже БЫВАЕТ
Все вышеперечисленное - это доп. время к разработке.
Плюс последний клиент сам был не проч поставить сайт локально и поиграться с денвером. а тут оппа. мультисайт. нифффстает.
Короче, когда оно не надо сайт - ОДИН - оно просто не надо.
насчет не умеете готовить - в 6ке оно побеждается при программерских/верстальных работах как я описал выше. это ВРЕМЯ
т.е. ваши проблемы разработки, которые есть только 1 раз важнее чем скорость загрузки, вместо 6 сек получаем 5сек... этим всё сказано... если у вас проект не такой уж и сложный и грузиться 1 сек, то это другое дело, но даже тут вместо 1 сек получить 0.8 очень даже заманчиво...
Вы абсолютно не понимаете зачем это надо, т.е. пользователи одного сайта например админ получит доступ к файлам например через IMCE чужого сайта и поудаляет всё??? вы очень плохо понимаете зачем нужен мультисайтинг...
Это действительно ваше мнение, которое очень далеко находится от реальности...
Кривые руки что тут ещё скажешь... да действительно есть проблемы, НО в базе править не так много надо мин 30 у меня уходит на всё про всё, а в систем лезть не надо, есть замечательная кнопочка, "очистить кеш", учите мат часть...
Так настройте локал хост правильно... Неумение, это ваша личная проблема... почему нельзя подменить хост????? делов на 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 ?
хотя бы потому, что это дилетантство
кстати раз пошла такая пьянка и пошла тема мусора в этом треде
аффтар, я реквестирую описание полей глобальной переменной $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'); например в начале каждого модуля... это конечно изврат, но ничего умнее в голову не приходит...