Мультисайтинг (многосайтовость) - это просто


Изображение пользователя Макс Кириленко.
  


Рубрика:

Введение

Студия Razgonka.ru специализируется на мультисайтинге.

Мультисайтинг (многосайтовость) имеет два разных значения. В этой статье я буду говорить в первую очередь об объединении посетительской базы между разными сайтами. Именно оно наиболее интересно с точки зрения наших клиентов.

Необходимость такого объединения очевидна. Любая бабушка знает, что семечками нужно торговать не на углу своего дома, а хотя бы на остановке метро. Еще лучше торговля идет на колхозном рынке. Но там бабушек не видно, другие доходы - другие продавцы.

Мультисайтинг с объединенными посетителями (они же покупатели) это аналог колхозного рынка. Если посетитель не купит у одного торговца, то неизбежно купит у другого. Так или иначе, всякий пришедший на рынок оставляет там больше денег, чем проходя мимо одиноко стоящей бабушки.

Связка сайтов, объединяющая покупателей, работает по этому же принципу. Один сайт из связки продает зимние санки, другой летнюю одежду. Если при одиночном расположении каждый сайт будет работать только половину времени года, то при объединении они в свой сезон будут получат в 2 раза больше покупателей. Своих и покупателей с другого сайта из связки.

Мультисайтинг это способ использовать энергию посетителей (покупателей) до конца. На обычных сайтах посетители (покупатели) уходят на другие сайты Интернета. При мультисайтинге у посетителя (покупателя) есть возможность продолжить серфинг на одном из сайтов связки. Учитывая, что все сайты сделаны на одном движке и устроены примерно одинаково, посетитель (покупатель) испытывает больше комфорта при серфинге/шоппинге и ему легче сделать покупку.

Теперь о технической стороне мультисайтинга. Студия Razgonka.ru специализируется на установке сайтов на CMS Друпал, поэтому рассказывать о мультисайтинге буду на его примере.

 

Теория, виды мультисайтинга

Различают 2 вида мультисайтинга.

1-ый. Мультисайтинг с общим движком. Много независимых сайтов используют один движок. Друпал работать в режиме "один движок, много сайтов".

2-ой. Мультисайтинг с общими таблицами. Много сайтов частично используют одинаковые таблицы в базе, например, данные о юзерах. Друпал поддерживает и такой мультисайтинг.

Общий движок, варианты

Если сайтов немного (2-5), то можно завести отдельную папочку, куда кидать эталонную версию версию Друпала и всех модулей.

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

Мультисайтинг с общим движком на FTP-синхронизаторе. Если мы не собираемся отлаживать локально сайты с использованием последней версии Друпала и модулей, то можно мультисайтинг с общим движком еще проще. Берется FTP-синхронизатор, позволяющий сделать профили. С его помощью заливается содержимое эталонной папки напрямую на сайты.

Мультисайтинг с общим движком средствами сервера. Если часть сайтов расположена на одном хостинге (сервере), то появляется возможность перенести папку с эталонным движком на сервер. Физически папка с Друпалом будет одна для всех сайтов. Сервер сам будет "размножать" эту папку для всех сайтов. Помимо правки настроек сервера потребуется некоторое изменение установок Друпала. Об этой технике уже много писалось на Drupal.ru. Воспользуйтесь поиском или советами Акселя на http://drupal.ru/node/763 , http://drupal.ru/node/1453

Общие таблицы, варианты

Вариант 1. Если каждый сайт хранит таблицы в своей независимой базе, то сайты полностью независимы (с точки зрения посетителей).

Комментарий. И что толку? таких независимых сайтов миллионы. Цивилизация рождалась в городах, а не в отдельных хуторах.

Вариант 2. Сайты объединяют свою базу пользователей, но сохраняют независимость в остальном. Здесь таблицы, отвечающие за пользователей, у сайтов общие, а все остальное разное.

Это самый рабочий вариант. О нем ниже будет подробнее.

Вариант 3. Сайты объединяют пользователей и часть содержимого. Например, у разных сайтов общие пользователи и общий форум. Статьи разные на каждом сайте.

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

Посетителям тоже неудобно иметь дело с частичным зеркалированием сайта. Ссылки на зеркальное содержимое показываются в его браузере еще не просмотренными. Посетитель идет по ним и у него начинается дежа вю. Когда он наконец понимает, что он это уже точно читал, у посетителя сразу падает доверие к цвету посещенных/непосещенных ссылок. И он обзывает любителя зеркалирования разными словами за свое потерянное время. Весь дальнейший просмотр сайтов из мультисайтовой связки проходит под давлением - "Читал это уже или еще не читал?".

Вариант 4. Сайты объединяются полностью. Получаются "зеркала".

Когда-то в прошлом тысячелетии зеркала были распространены как способ борьбы с плохим хостингом. Если не было видно сайта на одном месте, то посетитель мог найти его на другом. Сейчас зеркала выжили только для файловых архивов, да и то в основном на бесплатных хранилищах. В коммерческих сайтах на скачиваемый файл дается одна ссылка и это забота хозяина сайта, найти хороший хостинг и обеспечить круглосуточную доступность файлов.

Коммерческий сайт не должен зеркалироваться. Даже варианты с www и без говорят о неуважении хозяина сайта к посетителю. Поисковики могут показывать одни ссылки на такой сайт и www, а другие без. Посетитель зайдет по ссылке с www, просмотрит сайт и увидит на форуме ссылку без www . Ее дал тот, кто зашел по адресу без www. Но браузер может показать ее как еще не посещенную. И посетителю пойдет второй раз смотреть ту же самую страницу.


Идеальный вариант разделения таблиц

Итак, если проводить границу объединения таблиц, то самое оптимальное объединить зарегистрированных пользователей, но не замахиваться на объединение содержимого,т.е. вариант 2. Сайты сохраняют независимое содержимое с точки зрения поисковиков и посетителей. Но при этом посетители свободно переходят с одного сайта на другой с сохранением своего "лица" и покупательской "истории".



Техника подачи мультисайтинга на сайтах

При мультисайтинге на общих таблицах зарегистрированный на каком-то сайте пользователь автоматически получает возможность воспользоваться тем же логином и паролем при входе на другие сайты из связки мультисайтинга. Имеет также смысл объединить и данные профиля и аватары, чтобы пользователю не приходилось по 10 раз заполнять одно и то же на разных сайтах.

Если сайты в мультисайтовой связке работают независимо, то в таком объединении нет смысла. Пользователи и не знают, что где-то в мире есть другие сайты, на которых можно воспользоваться тем же логином/паролем. Надо в блоке логина на каждом сайте из мультисайтовой связки повесить объявление: "Подходит логин/пароль с любого из следующий сайтов". И дать список сайтов из связки. При наведении мышки на ссылку всплывает надпись, чем занимается соответствующий сайт. Если посетитель уже зарегистрирован на каком-то из сайтов связки, то это побуждает его использовать имеющийся логин/пароль, чтобы обрести лицо при использовании нового сайта. Все остальные с интересом могут пройти по ссылкам, чтобы посмотреть, что там интересного есть.

Кроме объединения пользовательских логинов/паролей можно объединить между сайтами и базу покупателей. Если пользователь сделал покупку на одном из сайтов, то на другом сайте из связки он может сделать покупку в упрощенном варианте. Все его адреса и координаты подставятся из анкеты, которую он заполнял при своей первой покупке на другом сайте.

Объединение другой информации

Часто бывает и информация вне Друпаловских таблиц, которая одинакова для всех сайтов. Например, можно объединить 100-Мбайтную базу почтовых индексов, чтобы все сайты из связки могли работать с одной базой, а не держать ее копии у себя в таблице.


Техника мультисайтинга с общими таблицами

Есть два варианта.

Вариант 1. Объединение на разных префиксах. Здесь держат в одной базе несколько разных версий друпаловских таблиц для разных сайтов. Уникальные таблицы идут с префиксом сайта, общие таблицы идут вообще без префикса.

Этот вариант применим только если хостер дешевый и берет отдельную плату за каждую дополнительную базу MySQL. Если у вас в связке будет болтаться хотя бы с десяток сайтов, то таблиц в базе будет 600, многовато. Также если один из сайтов некорректно проработал с одной из таблиц, то это может подвесить работу со всей базой и вся десятка сайтов замрет.

Вариант 2. Выделение общих таблиц в отдельную базу. Уникальные таблицы каждый сайт держит в своей личной базе (без префиксов). Общие таблицы выделены в отдельную базу.

Здесь вероятность поломки базы с общими таблицами резко снижена, потому что общих таблиц всего 4-6 и они довольно компактные, без кэша, поиска и прочих объемных таблиц.. А уникальных таблиц у каждого сайта остается 50 штук, хранятся они в отдельной базе и если с ней что-то случится, то повиснет только сайт-виновник. Общую базу нужно почаще бэкапить.

Дальше будем рассматривать вариант с выделением общих таблиц в отдельную базу и когда у сайтов отдельные базы для своих уникальных таблиц.


Объединение новых и старых сайтов

Самое простое объединить несколько новых сайтов. Чуть сложнее присоединить в мультисайтинге новый сайт к старому. Присоединять старый сайт к старому можно, но сложно. Потребуется перенести в присоединяемом сайте информацию о пользователях на область свободных UserID. И корректно переименовать многие таблиц, завязанных на UserID.

Дальше рассматриваем вариант стыковки нового сайта к старому. Все последующие новые сайты добавить к мультисайтовой связке можно будет добавить по той же самой методике.


Пусть у нас есть старый сайт site1.ru и новый сайт site2.ru. И есть 3 базы:

base: site1 здесь пока хранятся все таблицы для старого сайта
user: firstuser
password: pasfirstuser

base: site2 здесь будут хранится уникальные таблицы для нового сайта
user: firstuser
password: pasfirstuser

base: common здесь будут хранится общие таблицы для всех сайтов
user: firstuser
password: pasfirstuser


Обратите внимание, что все три базы работают с общим юзером firstuser. Вы не сможете задать для каждой базы отдельного юзера.


Разделение таблиц

Начинаем с того, что разделяем базу site1 на две части. Общие таблицы в мультисайтовой связке перенесем в базу common. А уникальные таблицы для Site1.ru оставим в родной базе site1. После чего старый сайт будет работать на двух базах.

По шагам

Шаг 1. Заходим на Site1.ru как суперюзер.

http://www.site1.ru/admin/settings

Переводим сайт в режим офф-лайн. В качестве объяснения пишем:

"Сайт Site1.ru закрыт на профилактическое обслуживание сегодня, такого-то числа, в субботу в 1:00 по Московскому времени. Через два часа, в 3:00, он откроется снова. Пожалуйста, зайдите позже. Благодарим за терпение."

Шаг 2. Делаем бэкапы базы site1.

Для бэкапа используйте Sypex Dumper Lite http://sypex.net/ . Укажите в скрипте в 38-ой строчке кодировку utf-8 :
define('CHARSET', 'utf-8'); // define('CHARSET', 'cp1251');

При бэкапе можно указать фильтр, отбрасывающий нужные и отбрасывающий ненужные таблицы


Вся база site1 разбивается на 3 части:

а) общие файлы (authmap, profile_fields, profile_values, sequences, sessions, users)

б) ненужные таблицы ^locales*, ^cache, ^search*, которые можно восстановить и без бэкапа

в) остальные таблицы, они уникальны для site1 и не используются в site2

Кладем скрипт dumper.php в директорию tmp, назначаем на нее права 777. Запускаем в браузере

http://www.site1.ru/tmp/dumper.php

Вводим логин/пароль:

user: firstuser
password: pasfirstuser

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

Делаем общий бэкап, в фильтре указываем

^locales*, ^cache, ^search*

чтобы избавится от таблиц, которые можно восстановить без бэкапа.

Скачиваем файл с бэкапом. Смотрим, можем ли мы распаковать его и все ли нормально с кодировкой.

Если все нормально, то делаем бэкап общих таблиц, указав фильтр:

authmap, profile_fields, profile_values, sequences, sessions, users

Скачиваем файл и опять проверяем его.

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

Возвращаемся на страницу бэкапа и переключаем скрипт снова в режим бекапа. Бэкапим базу common, скачиваем ее и смотрим, все ли нормально с кодировкой.

Если все нормально, то продолжаем подготовку к разделению Site1.ru для работы на двух базах, общей и уникальной.

Шаг 3. Меняем в локальной версии Site1.ru файл /sites/default/settings.php :

//$db_url = 'mysql://username:password@localhost/databasename';

$db_url = 'mysql://firstuser:pasfirstuser@localhost/site1';

// $db_prefix = '';

$db_prefix = array(
"default" => "site1.", // эта строчка разная у каждого сайта в мультисайтовой связке
"users" => "common.",
"sessions" => "common.",
"authmap" => "common.",
"sequences" => "common.",
"profile_fields" => "common.",
"profile_values" => "common.",
);

Такая конструкция означает, что Друпал на Site1.ru будет брать по умолчанию таблицы из базы site1, а 6 общих таблиц - из базы common.

Точка на конце будет отделять имя базы от имени таблицы. Повторюсь, для базы site1 и common юзер и его пароль должны быть одинаковыми, иначе не будут видны те таблицы, у которых база не допускает до себя юзера firstuser с паролем pasfirstuser .



Теперь у нас все готово для того, чтобы Site1.ru заработал на двух базах.

Шаг 4. Заливаем файл /sites/default/settings.php на Site1.ru

Шаг 5. Удаляем в базе уникальных таблиц site1 ставшие ненужными общие таблицы
authmap, profile_fields, profile_values, sequences, sessions, users

Шаг 6. Ходим по Site1 как суперюзер и проверяем, все ли в порядке.

Шаг 7. Идем в таблицу sequences (счетчики)

В ней 10 записей:

files_fid
view_view_vid
access_aid
comments_cid
menu_mid
node_nid
node_revisions_vid
term_data_tid
vocabulary_vid

и

users_uid

При добавлении новых нод, меню, комментариев, файлов,... Друпал, бегающий на Site1.ru будет создавать в таблице sequences новые записи, добавляя в качестве префикса дефолтную для него базу site1:

site1.access_aid
site1.comments_cid
site1.files_fid
site1.menu_mid
site1.node_nid
site1.node_revisions_vid
site1.term_data_tid
site1.view_view_vid
site1.vocabulary_vid

И только при создании нового юзера он добавит префикс common к users_uid:

common.users_uid

Если бы Site1.ru поднимался с нуля, то в этом не было бы ничего страшного, каждый бы новый счетчик начал бы работать с 1. Но у нас Site1.ru уже имеет много мастерила и юзеров. Поэтому при попытке создания нового материала, комментария, добавления файла,... и добавления нового юзера Друпал проверит, есть ли в наличии запись с соответствующим счетчиком (site1.node_nid, site1.comments_cid,... и common.users_uid). Если такой счетчик Drupal не обнаружит, то он создаст соответствующую запись, присвоит ей значение 1 и начнет создавать материал (ноду, комментарий,... или юзера) с номером 1. Но при попытке сохранить материал или юзера под номером 1 Друпал обнаружит, что в базе уже есть материал или юзер под таким номером. И тогда он пожалуется на этот факт и откажется добавлять материал или юзера.

Нужно вручную создать в базе common записи:

site1.access_aid
site1.comments_cid
site1.files_fid
site1.menu_mid
site1.node_nid
site1.node_revisions_vid
site1.term_data_tid
site1.view_view_vid
site1.vocabulary_vid
и
common.users_uid

И перенести из них значения старых счетчиков

access_aid
comments_cid
files_fid
menu_mid
node_nid
node_revisions_vid
term_data_tid
view_view_vid
vocabulary_vid
и
users_uid

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

При определенной сноровке можно эту операцию сделать путем правки файла с бэкапом общих таблиц. Нужно в таблице sequences добавить к записи users_uid префикс к 9-ти записям префикс "common.", а к остальным 9-ти записям префикс site1. Снова сжать файл и восстановить его пустую базу common.

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

Шаг 8. Заводим нового пользователя. Проверяем:

а) получилось ли завести нового пользователя
б) в базе common в таблице users должна появится новая запись
в) в таблице sequences запись common.users_uid должна увеличится на 1.

Если все в порядке, то заходите на http://www.site1.ru/admin/settings и переводите сайт в режим он-лайн.

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

 

Присоединение нового сайта к мультисайтовой связке

Шаг 1. Заводим базу для уникальных таблиц второго сайта

base: site2
user: firstuser
password: pasfirstuser

Шаг 2. Бэкапим базу common и site1

Шаг 3. Меняем в локальной версии Site2.ru файл /sites/default/settings.php следующим образом:

//$db_url = 'mysql://username:password@localhost/databasename';

$db_url = 'mysql://firstuser:pasfirstuser@localhost/site2';

// $db_prefix = '';

$db_prefix = array(
"default" => "site2.", // эта строчка разная у каждого сайта в мультисайтовой связке
"users" => "common.",
"sessions" => "common.",
"authmap" => "common.",
"sequences" => "common.",
"profile_fields" => "common.",
"profile_values" => "common.",
);


Шаг 3. Устанавливаем Drupal на Site2.ru как обычно. При запуске скрипта создания таблиц уникальные таблицы будут без префиксов заведены в базе site1, а общие 6 таблиц заводится в базе common не будут, потому что они уже существуют.

Править таблицу sequences нет нужды. По мере работы Site2.ru сайт будет добавлять свои собственные записи:

site2.access_aid
site2.comments_cid
site2.files_fid
site2.menu_mid
site2.node_nid
site2.node_revisions_vid
site2.term_data_tid
site2.view_view_vid
site2.vocabulary_vid

А если придется создавать на Site2.ru нового юзера, то Друпал увеличит на 1 общий счетчик юзеров common.users_uid в котором хранится общее число пользователей в Site1.ru.

 

Вот, собственно, и все добавление нового сайта к готовой связке.

Следующие новые сайты добавляются по такой же схеме.


Замечания

1. Раз база пользователей общая, то попытка во время установки Site2.ru добавить суперюзера окончится ничем. Если на сайте Site1.ru уже было 2000 юзеров, то будет добавлен всего-навсего юзер 2001. Когда после установки Site2.ru видите страницу с приглашением добавить юзера, не поддавайтесь на провокацию. Лучше идите в блок Логин/Пароль и вводите туда данные суперюзера №1 с Site1.ru. Если Site2.ru признал такой логин-пароль как суперюзерский, то значит мультисайтинг начал работать.

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

Сегодня суперюзер это вы. Завтра это другой человек. Послезавтра 10 сайтов объединяются в один и суперюзер становится один на все 10 сайтов. После-после завтра какой-то сайт откалывается от мультисайтовой связки и тут же поменяет название суперюзера, а вместе с ним и авторство статей, написанным суперюзером мультисайтовой связки. Суперюзер лицо техническое, назовите его 999 и никогда ничего не пишите на сайте от его имени. Себе же заведите логин-пароль как юзер-2, дайте ему всевозможные права в роли администратора и пишите в свое удовольствие.

3. Как видим, добавление нового сайта к готовой мультисайтовой связке очень простое. Нужно только поменять несколько строчек в /sites/default/settings.php. Если ставите сайт и есть планы цеплять к нему другие на мультисайтинг, то имеет смысл даже первый сайт в связке с самого начала готовить к мультисайтовой работе. Это потребует создания общей базы common и добавления нескольких строчек в /sites/default/settings.php.

4. Добавление старого сайта к старому требует много дополнительной работы. Поэтому с самого начала стройте все свои сайты как единую мультисайтовую связку. Это намного проще, чем развивать сайты порознь, а потом объединять их.

 

Мое мнение

Мультисайтинг на общих таблицах в отдельной базе делается на Друпале очень просто.

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

Новый сайт присоединил к связке за 10 минут.

А если бы я изначально строил мультисайтовую связку, то дополнительных затрат было бы по 5 минут на каждый сайт.

Не бойтесь мультисайтинга. Друпал прекрасно с ним работает. Чем раньше вы получите опыт мультисайтинга на Друпале, тем быстрее вырастет ваша первая мультисайтовая связка.

 

Модули, полезные при мультисайтинге

  • Shared Sign-Ons. Позволяет пользователям ограничиться залогиниванием на одном лишь сайте сайте. При переходе внутри мультисайтовой связки другие сайты будут узнавать такого пользователя без дополнительной аутентификации. В марте 2007 г. у этого модуля были проблемы из-за которых он работал устойчиво только при отключенном кэширования сайта.
  • Fierce SSO. Альтернатива Single Sign-On. Позволяет узнавать пользователей, залогинившихся даже с сайтов не на Друпале.
  • Registration role. Этот модуль позволяет назначать пользователям при регистрации заранее заданные роли. Можно на каждом сайте из связки завести отдельную роль, названную по имени сайта и присваивать зарегистрировавшимся пользователям роль, названную именем сайта. Такая информация служит для разделения пользователей по месту их исходной регистрации. Эта информация может быть полезна при выплате коммиссионных за приведенных покупателей. Или когда настанет время "выделить" сайт из связки вместе с пользователями, которые зарегистрировались на этом сайте
  • Multisite Manager. Модуль позволяет плодить сайты на основе центрального сайта
  • Multiple Domains. Позовляет создавать частичные клоны основного сайта. Например, можно вынести работу E-commerce или работу с пользовательскими аккаунтами на отдельный протокол https. Требует модуль single sign-on.
  • Robotstxt позволяет создать отдельный robots.txt для каждого сайта в связке.

Обсуждения в тему

Заказ мультисайтинга

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


С вопросом

А как мультисайтинг сказывается на скорости? Вчера свёл 7 сайтов в связку (с общей бд юзеров), и какие-то нехорошие впечатления.


подтверждение прав на владение сай

а как при мультисайтинге, когда используется один экземпляр Друпала, быть с файлами располагаемыми в корне сайта, например файлы подтверждения владения сайтом для поисковых систем? Придется всё свалить в корень основного сайта?

Изображение пользователя Макс Кириленко.
  

Скорость мультисайтинга

Теоретически на скорости мультисайтинг никак не должен сказываться.

Мультисайтинг на общих таблицах основывается на манипуляции префисами ключевых таблиц. Вне зависимости от длины префикса скорость обращения к таблице одна и та же. От того, что к одной таблице обращаются сразу 7 сайтов, она не отдает данные в 7 раз медленнее. Тем более, что выборки на чтение могут идти параллельно.

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

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

По возможности расцепите сайты из связки и дайте каждому из них самостоятельную жизнь. Поддерживать 7 независимых сайтов на порядок проще, чем 7 сайтов, объединивших часть таблиц. В коммуналках на кухне и в местах общего пользования баталии бывают еще те.

Если у всех 7-ми сайтов один и тот же владелец, то вместо 7 сайтов проще держать 1 сайт, на котором объединяется информация из 7 сайтов.

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


Изображение пользователя Макс Кириленко.
  

Мультисайтинг и .htaccess: robots.txt

Гость:
"как при мультисайтинге, когда используется один экземпляр Друпала, быть с файлами располагаемыми в корне сайта, например файлы подтверждения владения сайтом для поисковых систем?"
"Мультисайтинг и .htaccess: robots.txt"

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


Ответ

Ну и зачем же в таком случае огород городить? Что об этом говорит теория? Всё-таки испориться и единая бд может, что тут, что там, лекарство одно- делать копию.

Ещё вопрос: есть заказчик, но не знаю, сколько с него за это удовольствие вять, как Вы считаете?


Мультисайтинг и Денвер

Подскажите пожалуйста: возможен ли мультисайтинг на виндовс платформе (денвер3 + друпал 6)
пытаюсть установить три сайта на денвере (с разными базами)все делаю как описано у Вас в статье, но работают только два сайта. возможно проблема с настройками Апачи, но я не пойму что настроить.
в файл .htaccess, на основном домене, я добавляю директиву #dnwr_host cite2,
это позволяет увидеть второй сайт, а третий выбрасывает в окно приветствия Денвера

Изображение пользователя Макс Кириленко.
  

Чтение мыслей

Гость пишет: "Ну и зачем же в таком случае огород городить? Что об этом говорит теория?"

Теория говорит: "Не нужно плодить лишних сущностей".

 

Гость пишет:
"есть заказчик, но не знаю, сколько с него за это удовольствие взять, как Вы считаете?"

Без техзадания ответить определенно что-либо затруднительно.

Раз заказчик один, то скорее всего хозяин у доменов он тоже один. Мультисайтинг на общих таблицах это недокументированная функция Друпала. Постоянно вылезают какие-то нестыковки. Применять мультисайтинг на общих таблицах на рабочих сайтах нежелательно. Заказчик скорее всего не технарь и не понимает, чем ему может вылится мультисайтинг в поддержке. 

 

Гость пишет:
"Кстати, Вы сомневались - "когда есть необходимость". Взгляните http://toptale.info/"

Взглянул. Ничего не понял. Надо признаться, даже обрадовался.  Улыбка Каждый раз Вы даете информации в 10-30 раз меньше, чем мне нужно для ответа. Раз Вы не считаете нужным выложить всю необходимую информацию, то и мой ответ не обязателен. Чтение чужих невысказанных мыслей отнимает много сил, я этим занимаюсь только с клиентами.Надеюсь, Вы поймете меня.

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

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


Кстати, Вы

Кстати, Вы сомневались - "когда есть необходимость". Взгляните http://toptale.info/

Хорошая статья.

Хорошая статья. Спасибо.

Максу:

Продолжая вашу аналогию с колхозным рынком (и говоря о бизнес сайтах) вы забываете о том что сайты продают товары или услуги. Соответственно информация о услугах каждого сайта должна быть представлена на как можно большем числе сайтов. Отсюда вывод: сайты должны обмениваться не только пользователями, но и контентом. (хотя бы в ограниченных масштабах). Склейка (зеркалирование) одинаковых страниц на сайтах частично решается настройкой файла robot.txt П.С. это Дуболом 8 написал, только не получилось зарегистрироватся.

Изображение пользователя Макс Кириленко.
  

Дублирование информации на сайте

Дуболом 8 пишет:
"Отсюда вывод: сайты должны обмениваться не только пользователями, но и контентом. (хотя бы в ограниченных масштабах)."

Совсем избавиться от дублирования информации конечно не удастся. Если профили пользователей общие и открыты для обозрения посетителями, то и посетители и поисковики быстро заметят, что информация на них одна и та же.

Без мультисайтинга дублирование все равно остается. Если статья короткая, то она может быть показана в разных местах сайта - на главной странице, в дневнике, в рубрике по какой-то категории,...

Меню тоже на каждой странице дублируется.

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

Так что дублирование процветает в мире и независимо от наших желаний.

 

Дуболом 8 пишет:

"Склейка (зеркалирование) одинаковых страниц на сайтах частично решается настройкой файла robot.txt"

Очень частично. Многие поисковики многие ведут себя невежливо и не признают robots.txt. Яндекс раньше показывал страницы, закрытые robots.txt, чтобы расширить выдачу на редких запросах. А в последнее время по форумам идет слух, что Яндекс навострился регистрироваться и старательно обследует закрытые для гостей страницы. Как он такие страницы собирается показывать в выдаче непонятно, но может быть, будет давать ссылки на вариант из своего кэша.

Браузеры вообще не смотрят в robots.txt, когда определяют как им показывать ссылку, потому что формат robots.txt создан для роботов, а не для браузеров.

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


Mультисайтинг и форум

Пример ввв.моя-страница.ру №1 shop.моя-страница.ру №2 форум.моя-страница.ру №3 В друпале есть возможность сделать форумное сообщение на главной странице. Как реализовать так, чтоб форумы обоих сайтов были на третьем как один общий. И сообщения сделанное на одном из них сразу попадало в этот форум на третий сайт. Какие таблицы за это отвечают? как правильно всё реализовать? Надеюсь внятно обьяснил ;)

Изображение пользователя Макс Кириленко.
  

Мультисайтинг через RSS канал

Гость пишет:
Как реализовать, чтобы форумы обеих сайтов были на третьем как общий. И сообщения сделанное на одном из них сразу попадало в этот форум на третий сайт.

Сообщения форума хранятся в таблице forum.

Комментарии к сообщениям форума и другим видам сообщений (дневники, заметки, страницы) хранятся в таблице comments.

Счетчики сообщений на форуме и счетчики комментариев хранятся в таблице sequences (счетчики). В ней Вам понадобятся поля:

comments_cid
node_nid
node_revisions_vid

Объединить таблицы форума и комментариев легко, техника была описана в статье на этой странице. Затруднение будет в объединении отдельных полей в таблице sequences.

В настройках для каждого сайта Вы задаете ведущий префикс, site1, site2, site3. Первый сайт будет использовать счетчики

site1.comments_cid
site1. node_nid
site1. node_revisions_vid

Второй,

site2.comments_cid
site2.node_nid
site2.node_revisions_vid

Третий

site3.comments_cid
site3.node_nid
site3.node_revisions_vid

Вам нужно как-то исхитрится и объединить эти поля в таблице. При этом префиксы site1, site2, site3 Друпал интенсивно используются для разделения остальных полей в таблице sequences и для разделения уникальных таблиц, в которых хранятся данные всех трех сайтов.

Мне что-то не приходит в голову, как можно сделать такое разделение без изменения исходного кода Друпала. Если сумеете найти способ, напишите пожалуйста.

Мультисайтинг через RSS-каналы

Без вмешательства в код Друпала можно обойтись, если Вам достаточно только показывать заголовки с двух форумов на третьем форуме, но нет нужды добавлять сообщения с третьего форума на первые два сайта.

У каждого форума на первых двух сайтах есть свой RSS-канал. Например. у форума посвященному Друпала на Razgonka.ru работает RSS-канал http://www.razgonka.ru/taxonomy/term/5/0/feed .

Можно попробовать использовать на третьем сайте какой-нибудь RSS-агрегатор, который будет показывать новости с форумов первых двух сайтов. За подробностями и обсуждением посетитель будет отправляться на соответствующий форум.

Обратите внимание, что для показа заголовков новостей через RSS-каналы сайты могут быть и не объедены в мультисайтинг. Вытаскивать новости можно практически с любого сайта на Друпале, своего или чужого. И даже с сайтов, где не стоит Друпал, но формируются RSS-каналы.

Обвязка дружественных сайтов агрегаторами RSS-каналов тоже есть некоторая разновидность мультисайтинга. Плюсы RSS-обвязки сайтов:

  • она не плодит "зеркал"
  • допускает разные движки на разных сайтах
  • легко делается и легко удаляется в случае необходимости
  • может применятся с чужими сайтами.

Мое частное мнение.

Максимум, что нужно объединять, это посетителей и всю информацию о них. Все остальное содержимое, лучше держать уникальным. Это приятнее и поисковикам и посетителям, которые не будут видеть по 3 раза одно и то же на разных сайтах. Раздражает, когда видишь ссылку непосещенной, а по ней находится уже просмотренная информация.

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

Поэтому лучше всего объединять в мультисайтовой связке сайты с довольно различной тематикой. Тогда можно будет спокойно держать на каждом сайте его уникальное содержание. А при необходимости показывать на сайтах заголовки некоторых новостей на соседних сайтах.

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


Смысл в том, что

Смысл в том, что форум должен быть один. на ввв.форум.моя-страница.ру. Плодить к каждой субдомене свой форум нет смысла. Будут создаваться и новости на одном, и голосования на другом, и просто товары на третьем. Идея в том, чтобы из существующего форума, в зависимости от контекста прикреплять к главной сообщения. Либо интересные статьи сразу делать как форум. К примеру. Если бы вы сделали эту статью как форумное обсуждение, то в форуме уже набилось бы 10 ответов. Действительно интересных статей мало. И создать новую комьюнити тяжело. Mне кажется, что так как задумано, стандартными средствами и мультисайтингом не добиться

Изображение пользователя Макс Кириленко.
  

Статьи в форум и дневник

Я немного запутался. Вы пишете:

Смысл в том, что форум должен быть один. на ввв.форум.моя-страница.ру.

Зачем вообще форум выносить на отдельный домен? Обычно это делают только когда хотя использовать какой-то навороченный форум, который не удается встроить в Друпал.

Плодить к каждой субдомене свой форум нет смысла. Будут создаваться и новости на одном, и голосования на другом, и просто товары на третьем.

"одном, другом, третьем" - это форуме или сайте? Напишите пожалуйста подробнее о Вашем замысле. Например,

  • есть site1.ru, на нем только новости
  • есть site2.ru на нем только голосования
  • есть site3, на нем только товары
  • есть форум forum1.site1.ru. В зависимости от контекста сообщения на форуме новость должна быть прикреплена к одному из сайтов site1, site2, site3.

Гость пишет:

"К примеру. Если бы вы сделали эту статью как форумное обсуждение, то в форуме уже набилось бы 10 ответов."

Это предложение тоже не понял. В Друпале сообщение на встроенный форум и статья в дневник устроены совершенно одинаково. Сначала идет сообщение (или статья) а после него идут комментарии, если таковые окажутся.

Если гости получили разрешение оставлять комментарии, то они смогут оставить их и для сообщения на форуме и для сообщения в дневнике.

Мне кажется, количество комментариев зависит от того, насколько поднятая тема горячая. И мало зависит от того, статья это или сообщение на форуме. Ведь для посетителей друпаловского сайта и статья и сообщение на форуме выглядят совершенно одинаково.

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


Форум + Mультисайтинг

День добрый ;). Спасибо за живой интерес к моему вопросу. подумалось, что анонимом как то уже неудобно:).

1. Mоё мнение, что продвигая похожие сайты или субдомены одной страницы необязательно иметь несколько форумов. У одного сайта он может быть у другого нет. Если они в связке, то очень удобно было бы иметь один. На некоторых сайтах его показываем, на других нет. Как мастеру хочется.

2. Однако иногда работая над статьёй понимаешь, что будет животрепещущий интерес. пример такой статьи, вот это ваша.

3. форумное обсуждение действительно ничем не отличается от блога или статьи с картинкой. Однако, у него появляется ещё один тег, плюс в форуме индексируется только заголовок.

Плюс (для начинающего форума) просмотры и обсуждения. Если гугл привёл человека сразу на форум, то он видет не 40 сообщений от админа без ответа, а вполне посещаемый форум с обсуждениями.

на этом вводную заканчиваем. и так требуется форум на собственом (суб)домене, с возможностью выставления статьи (не копирывание) как минимум на одном сайте из связки, а ещё лучше в зависимости от категоризации (тегов) на определённом.

пример.

сайт называется

ввв.обовсём.ру

форум

форум.обовсём.ру

тематические разделы субдомены

секс.обовсём.ру

хифи.обовсём.ру

телевизор.обовсём.ру

итд.обовсём.ру

На форуме делаем контейнеры под каждую субдомену.и всё


Изображение пользователя Макс Кириленко.
  

Осторожнее с мультисайтингом

Для показа одного и того же сообщения в разных местах существует несколько способов:

  • Использование встроенный возможностей Друпала
  • Через RSS каналы
  • Объединением таблиц

По пунктам

Использование встроенных возможностей Друпала

Вы можете разместить Ваш единственный форум на каком-нибудь сайте под адресом example1.com/forum. Там завести контейнеры под каждый тип форума. Хитовые сообщения выводить на главную страницу example1.com тем или иным способом. Например, для хитовых сообщений назначить отдельную категорию. Все статьи в этой категории выводить в блок на главной странице.

Использование RSS-каналов

Для хитовых сообщений завести отдельный форум. Если сообщение планируется как хит, то публиковать его на этом форуме. Откуда он через RSS-канал (который есть у каждого форума на Друпале) может выводится на любом сайте через агрегатор новостей.

Использование мультисайтинга с общими таблицами

Объединить форумные таблицы у нескольких сайтов на Друпале. Причем основной форум показывает все форумы, а остальные сайты работают только с одним из основных форумов, на котором публикуются хитовые сообщения. Сплошная головная боль. Даже если сумеете настроить такую связку, получите головную боль при первом же апгрейде движков Друпала на всех Ваших сайтах.

Ошибка

Часто делают ошибку, когда идут от той структуры информации, которая нужна. И под нее пытаются подыскать решение. 

Обычно рекомендуется идти от инструментов к структуре информации на сайте (сайтах). Изучаются инструменты, которыми можно реализовать структуру информации. И исходя из их возможностей строится структура информации. Она получается не совсем такой, как это видится в мечтах, но зато создается легко, работает устойчиво и посетители довольны.

Мультисайтинг с некоторыми общими таблицами это круто. Но если есть возможность все сделать на одном сайте и не распылять ни посетителей ни свое время, то лучше все сделать на одном сайте. На трех сайтах и отдельном форуме сообщество будет создаваться в 10 раз медленнее, чем если бы посетители имели дело с одним сайтом.

Квалификация веб-мастера

Рискну высказать мнение, что чем меньше веб-мастер отходит от базовых возможностей движка, тем выше его квалификация. Тюнингованный 50-ью модулями Друпал раскиданный по 3 сайтам отражает самые тонкие пожелания веб-мастера, но становится крайне тяжелым в поддержке.

Если есть сомнение "добавлять возможность или не добавлять", то лучше не добавляйте. Или на крайний случай добавляйте стандартным способом. Мультисайтинг явно не из их числа.

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


Это не статья, а бомба

Это не статья, а бомба, спасибо БОЛЬШОЕ

нужно чтобы у каждого сайта был уни

Спасибо за статью, сейчас настроил всё, работает просто отлично!

Но появился вопрос, что если мне нужно чтобы у каждого сайта был уникальный юзер админ, и что бы только он мог контентом управлять? Единственный юзер который мне нужен на все сайты это "root". Получается что прийдется использовать полностью независимые базы и как то cron'ом юзера "root" киноровать про создании каждого новог сайта.

Пытался использовать одну user таблицу с такими штуками как taxonomy access и nodeaccess но эти модули ещё какие-то сырые, недоработанные.

Если кто всё же знает как можно использоват общую юзер таблицу, позволяя только отдельным админам управлять соответствующими сайтами, буду рад помощи.

Спасибо огромное за статью!

Уважаемый Макс! Спасибо огромное за статью! Очень и очень подробно и полезно!


Хороша, но с ошибками

Макс, исправьте, пожалуйста, ошибки в тексте статьи, а то они затрудняют понимание.

Изображение пользователя Макс Кириленко.
  

Спилчекер показывает

Спилчекер показывает, что все в норме. В сотый раз мне перечитывать статью нет смысла, глаз давно "замылился".

Укажите пожалуйста на эти ошибки, я их исправлю.

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


Раздел

Раздел Присоединение нового сайта к мультисайтовой связке, Шаг 3

Устанавливаем Drupal на Site2.ru как обычно. При запуске скрипта создания таблиц уникальные таблицы будут без префиксов заведены в базе site1, а общие 6 таблиц заводится в базе common не будут, потому что они уже существуют.

и далее

site1.access_aid site1.comments_cid site1.files_fid site1.menu_mid site1.node_nid site1.node_revisions_vid site1.term_data_tid site1.view_view_vid site1.vocabulary_vid

Разве префикс для второго сайта уже не site2?
ps не мой пост http://www.razgonka.ru/multisiting#comme...

=====

От меня: Спасибо за статью, очень помогла понять озвученную технологию.

Вопросик маленький: как Вы считаете, если организовывать связку 3-5 сайтов на одном движке друпала, данные держать в одной БД, но таблицы будут со своими префиксами - насколько сильно это усложнит жизнь ресурса в будущем?
И еще если в такой связке один из сайтов будет "главным", то возможно не стоит общие таблицы выносить отдельно, а просто подключать остальные сайты к нему?
Заранее спасибо, пошел дальше читать о технологии


Изображение пользователя Макс Кириленко.
  

Мультисайтинг, раскладка по базам

Гость: "Разве префикс для второго сайта уже не site2?"

Да, Вы правы. Исправил описку.

Гость: "как Вы считаете, если организовывать связку 3-5 сайтов на одном движке друпала, данные держать в одной БД, но таблицы будут со своими префиксами - насколько сильно это усложнит жизнь ресурса в будущем?"

В спартанской комплектации Друпал содержит 60-70 таблиц. 2 сайта в одной базе данных создадут в 2 раза больше таблиц. Нагрузка на базу увеличится.

Время от времени какой-то сайт из двух сможет некорректно обойтись с какой-нибудь таблицей, так что подвешенной окажется вся база. А вместе с базой подвесится и второй, невиновный сайт. 

Когда таблицы сайтов разведены по разным базам и общие 6-7 таблиц находятся тоже в отдельной базе, общее хозяйство сайтов сводится только к 10% всех таблиц. Подобные инциденты будут случаться в 10 раз реже.

2-5$ в месяц за дополнительную базу не деньги. Если хотите избавить себя от лишних хлопот, разделяйте сайты по разным базам, общую часть тоже выделяйте в отдельную базу. 

А еще лучше с самого начала ведите сайты по разным базам с разными паролями от баз и без мультисайтинга. Большинство мультисайтовых связок распадается в течение 2-3 лет. Мультисайтниг на общих таблицах недокументированная возможность Друпала, в ней больше проблем чем достоинств.

Гость: "И еще если в такой связке один из сайтов будет "главным", то возможно не стоит общие таблицы выносить отдельно, а просто подключать остальные сайты к нему?"

Две базы не так хороши, как 3, но все же лучше, чем 1 база. Но наличие "главной" базы, где хранятся все данные первого сайта и общие таблицы, все равно содержит потенциальный риск. Если в таблицах первого сайта случится какой сбой, подвешивающий всю базу, то и другой (другие) сайты лягут вместе с ним. Зато если подвесятся укороченные базы других сайтов, то на работе главного сайта это никак не отразится.

В этом случае главный сайтом имеет смысл назначить тот, который должен быть как можно более независимым от других сайтов.

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


А нам на

А нам на проекте надо делать общими и пользователей, и часть контента, и поведение (Organic Groups стоят). Так что установка одна, база одна. Для переписывания ссылок будет использоваться url_alter, для разделения тем - settings.php для каждого сайта.

Single Sign-On

Вопрос Single Sign-On нужно ставить только на главном сайте?

как писать запросы к БД при мультис

а вот как обращаться к главной БД из site2.com ?

добавить в запросе перед таблицами common. (например common.node.nid) ? И могут быть проблемы в мультисайтинге при записи или чтении?


Изображение пользователя Макс Кириленко.
  

Отказ от мультисайтинга

Статья писалась для версии Drupal 5. Опыт использования мультисайтинга на нескольких связках сайтов показывает, что при ближайшей смене версий Друпала все клиенты просят разделить сайты в мультисайтовой связке на отдельные сайты.

Мультисайтинг - недокументированая возможность Друпала. При его использовании есть проблемы как раз вследствие того, что разработчики Друпала при его развитии не ориентируются на нужды мультисайтинга и не проверяют новые возможности Друпала на совместимость при использовании мультисайтинга.

В терминах, изложенных в "Веб-программирование, 7 ступенек в рай" ( http://www.razgonka.ru/rai ), мультисайтинг является "красным", опасным использованием Друпала. Рекомендуется избегать применять мультисайтинг на Drupal до тех пор, пока разработчики Друпала не включат его в число официальных возможностей Друпала.

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


Без мультисайтинга не обойтись

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

например, не редкая задача -  сайту нужны региональные поддомены (для региональности выдачи Яндекса) с одинаковыми пользователями и разным контентом, и выводом некоторого контента на поддомены с главного домена. Вот думаю последнюю задачу можно решить или запросом к БД, если не получиться - jQuery load

 p.s. Мультисайтинг вида:  собственные файлы Drupal у каждого поддомена, обращение к собственным БД и частичное использования общей БД. 


Изображение пользователя Макс Кириленко.
  

Разные случаи

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

Тут спорить сложно, случаи действительно бывают разные. У какого-то заказчика может быть много денег (или они бюджетные) и его не сильно волнует усложненная поддержка мультисайтинга. В таких случаях я объясняю, что:

1. Мультисайтинг отвалится сам собой при попытке через 2-3 года сменить мажорную версию Друпала.

2. Текущая версия Друпала будет поддерживаться 4-5 лет.

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

Гость: "например, не редкая задача - сайту нужны региональные поддомены (для региональности выдачи Яндекса) с одинаковыми пользователями и разным контентом, и выводом некоторого контента на поддомены с главного домена. Вот думаю последнюю задачу можно решить или запросом к БД, если не получиться - jQuery load"

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

А для трансляции с сайта на сайт проще использовать, как Вы предлагаете, запрос к общей базе.

Или можно транслировать RSS-канал с одного сайта в блок другого сайта.

Или сделать через таксономию региональные рубрики и назначать некоторым статьям подходящую региональную рубрику. Через шаблон страницы отслеживать статьи с региональными рубриками и для анонимов и поисковиков:

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

Тогда получится, что на сайте работает единственная версия Друпала, юзеры видят ее на одном сайте и не испытывают никаких неудобств. Администрирование тоже не составит никаких проблем. А региональные статьи для незарегистрированных пользователей и поисковиков будут вынесены на региональные поддомены. При этом останутся во внутреннем поиске по сайту.

При мажорной смене версию Друпала нужно будет лишь переписать шаблон страницы. А если новый веб-мастер не очень квалифицирован, то тоже не беда. Он может лишь сделать лишь переадресацию с любых адресов на региональных поддоменах на аналогичные адреса на основном сайте. Поисковики вскоре проиндексируют региональный контент на основном сайте и дальше все пойдет как надо на одном единственном сайте. На крайний случай можно после мажорной смены версии Друпала ничего не делать - получим нормально работающий сайт без региональных поддоменов, жизнь продолжается.

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

Или, другой вариант, опытный друпальщик тоже не будет браться за поддержку сайтов на мультисайтинге, как раз потому что знает все "прелести" мультисайтинга.

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник


Подскажите а обновляя ядро Drupal все

Вот есть мультисайт  Установлен Drupal в нем  в папке /sites/

Site1.ru

Site2.ru

Site3.ru

Для всех трех сайтов разные БД. Ядро обновляется как обычно и все базы подхватят обновление?


Изображение пользователя Макс Кириленко.
  

Отказ от мультисайтинга на Друпале

Не смогу ответить на Ваш вопрос, поскольку уже не являюсь знатоком мультисайтинга. 

Мультисайтинг для Друпала - недокументированная возможность. При обновлении мажорной версии Друпала клиента ждет головная боль с сайтами на мультисайтинге. После 2-3 лет обкатки мультисайтинга на Друпале принял решение отказаться от него, чтобы не оставлять своих клиентов один на один с мультисайтовой связкой, невозможной для обновления на свежую версию Друпала.

..........................
Макс Кириленко, руководитель студии Razgonka.ru
создание сайтов | подбор названий | мой дневник

Арендуйте или купите сайт Razgonka.ru

Аренда или покупка сайта Razgonka.ru
Подробнее...

Последние комментарии

Новые пользователи

  • 0675551952
  • skylins
  • Neonav
  • iskander
  • katapuls