Интеграция нескольких сайтов в один
09.01.2010Уже скоро выпущу стабильную версию блоголёта и стоит вопрос о полноценном сайте про блоголёт. Планирую на новой версии стартовать сайт litepublisher.ru (и на англ синхронно .com), где хочу сделать следующие разделы: bugtracker, feature requester, source explorer, plugins, themes, faq. Каждая из этих частей тянет и по своей сути является отдельным сайтом - мало будет автоматически сделанных перекрестных ссылок (ну разве что с сырцами). Как же это все реализовать?
Одна из первых идей - по настоящему сделать эти сайты в подпапках как отдельные сайты, и еще отдельный сайт - вариант сверхпродвинутой главной страницы. Ну типа на главной всяческие новости из этих частей - самые свежие ошибки, предложения, плагины, темы. Делать все в одном флаконе в виде одного сайта? Вряд ли получится - задачи слишком разные.
Предположим, что я сделал все эти подсайты. Какие же тогда основные проблемы? Во первых это корневые сайтмап и robots.txt - они должны обслуживать все подсайты, и при этом не конфликтовать. С другой стороны получается дублирование xmlrpc, админок и всего остального. Какое же выберу решение, я пока не знаю - задача сложная и интересная.
Комментарии (19) на запись “Интеграция нескольких сайтов в один”
Оставить комментарий
То инсталл не работал, то еще что-то. Вот сегодня скачал дистрибутив по ссылке с главной страницы - так в нем нет папки admin. Как ты можешь это объяснить? Я честно пытаюсь испробовать твою гениальную разработку, но не могу!
Скорее всего Вы права не везде выставили - у меня локально так тоже не запускается.
Только не CodeIgniter! Если легковесный MVC-фреймворк, то только потомок CI - Kohana (3я dev версия, вторая - недалеко от родителя ушла). В которой нормально именуются контроллеры, которая нормально акселерируется PHP-акселераторами из-за отсутствия eval'ов, в которой используется нормальное ООП.
К слову, с товарищем сейчас ваяем легковесный блог-движок на Кохане. напрямую работающий с вордпрессной базой. Точнее, сейчас пытаемся сделать универсальный View, основанный на Вордпрессовых темах и плагинах.
Еще мне понравился Yii, но там автор страдает той же болезнью, что и автор Блоголета... Там все объекты начинаются с C (видимо, разработчик изначально писал на MSVC++), здесь все объекты начинаются с T (Delphi / Borland C++ Builder)? И Yii тяжеловес, его демонстрационный блог жрет 12 метров без акселерации, против 1 Мб у Блоголета или 2 Мб у нашей поделки на Кохане :)
Саму по себе выдачу разной статики с разных доменов, по-моему, лучше всего реализовать при помощи апача (ну или какой веб-сервер используется).
Создать rewrite rule вида (сам не проверял, - только идея):
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?litepublisher\.ru$
RewriteRule (.(\.js|\.txt|\.css))$ ru/$1 [L,PT]
RewriteCond %{HTTP_HOST} ^(www\.)?litepublisher\.com$
RewriteRule (.(\.js|\.txt|\.css))$ en/$1 [L,PT]
Если не прокатывает PT (500 ошибка) - значит, юзать [L,R=302].
Плюс решения - не нужно программирования, в случае с PT ни роботы, ни пользователи даже не будут знать про то, что физически файл в другой папке. В случае, если блоголет запускается через какой-нибудь сервер с PHP через FastCGI, - не будут тратиться ресурсы на запуск PHP-воркера.
Если блог будет полностью на БД, то опять же можно пойти по простому пути:
if ($_SERVER['HTTP_HOST'] == ....) {
require_once('config.eng.php');
} else {
require_once('config.rus.php');
}
Если не база - то завести 2 дерева (data.rus и data.eng) и соответственно одно из них в конфиге подставлять, в зависимости от HTTP_HOST
То есть например сайтмап генерится из БД. В одном случае травим на английскую БД, в другом на русскую.
Либо (расширяемое решение) сразу делать какой-нибудь плагин, который будет хранить маппинги сайтов, менеджить для них базы и т.п. :) Будет пользоваться популярностью у сателлитоделов. :-D
Я все же размышлял не про сайты на разных языках, а про разный функционал. Вот две части -bugtracker и feature requester, неважно на чем они работают (но будут делаться на бд), каждый из них в своей папке, так как тикеты об ошибках и тикеты с запросами на новые фичи разные сущности (у них разные свойства, и эти свойства управляются по разному). Оба сайта сделаны на блоголёте. На главной из этих сайтов надо получить инфу - 5 открытых багов, 5 новых фич. Каждый сайт в подпапке имеет свойс собственный сайтмап, свои запреты в robots.txt и это все надо объеденитьв один флакон. Получается надо придумать интрфейс взаимодействия между главной и подсайтом и его реализовать. Аналогия - клиент-сервер, где клиент - это подсайт, а сервер это главная. Главная (сервер) опрашивает через одинаковый интрфейс своих клиентов (подсайты). Подсайты идеологически должны быть реализованы как черные ящики, то есть быть абсолютно независимыми от других подсайтов, а иначе эбудет только полный абзац с модификацией в будущем.
Подобная интеграция реализуема и на мой взгляд абсолютно малой кровью, а если более конкретно и приминительно к блоголёту, то: из подсайтов удаляются корневые урлы (sitemap, robots.txt), релаизуется интрфейс доступа. Все. далее можно рассуждать об интрфейсе доступа - как его делать. Быстрое и прямое решение в лоб - php скрипты. ННо проблема в глобальных переменных в подсайтов - они одинаковые, потому что все сделано на одном движке. Требуется организовать канал данных для доступа. Например xmlrpc, но такое решение чревато повышенной нагрузкой - открытие сокета, генерация и парсинг xml, для чего нужно время, память и процессор. Другой путь - сделать блоголёт таким, что можно будет в одном php скрипте получать несколько сайтов. И не факт, что несколько сайтов в одном скрипте будут есть меньше памяти (а скорее всего гораздо больше), но при этом все будет делаться быстрее. Я склоняюсь к xmlrpc, так как более чем вероятна ситуация одинаковых ресурсов (скажем сторонний разработчик написал плагин, который будет обращаться к одним и тем же данным во всех подсайтах), а изоляция через xmlrpc как раз позволить безопасно разрулить. Не обязательно xmlrpc - главное это rpc (remote procedure call). Например на Windows платформе это можно было бы сделать через pipes или com сервер (ах да php не могёт этого). Надо также будет придумать интрфейс обратно связи от клиента к серверу: когда у подсайта случается событие (например новый тикет), то об этом надо сообщить главной странице (серверу), который бы уже и запросил новые данные для своего обновления. Так что получается почти анекдот -за хлебушком сходил...
WPMU привязку к разным доменам без стороннего плагина кстати не умеет. Точно знаю - у нас небольшая социалка на WPMU+BP есть - http://berserki.ru/
Если полноценный мультисайтовый функционал нужен, - то надо видимо специальную версию с хуком, который работает раньше, чем загрузка собственно конфига.
Просто если речь про два сайта всего, проще захардкодить пути для доменов и все. Ну а если делать мультисайтовую CMS для сателлитов - предполагаю, что должно выглядеть примерно так:
В админке выбираются "дополнительные сайты", админ создает/удаляет каталог с конфигами и кэшем (для каждого САЙТА); параллельно при необходимости создается/удаляется база (или же таблицы с другим префиксом в той же базе). При необходимости к САЙТУ в той же админке привязывать и доп. домены.
Хук, который работает раньше чем загрузка конфига, смотрит на HTTP_HOST и подсовывает движку путь к каталогу data для указанного хоста.
Тогда действительно проблема со статикой (robots.txt), но можно решить, например, создав спец. скрипт типа static.php и редиректить все запросы на него. Чтобы в нем тоже отработался упомянутый хук, и из каталога data через readfile просто отдать статику.
Если пойти по стопам WP MU. Там subdomain.domain.ru/files/(.*) редиректится на subdomain.domain.ru/wp-content/blogs.php?file=$1
Соответственно в blogs.php по HTTP_HOST определяется каталог с файлами пользователя и из него делается readfile.
Соответственно для robots.txt в .htaccess можно сделать серверный редирект (PT) на blogs.php?file=robots.txt
Естественно, файлы движка должны быть одними на все сайты. Для сайта должны создаваться новый конфиг, папка data (кэш), и база.
1. бд это низкий уровень доступа к данным, и соответствено изменнение структуры бд, переход на другую бд и так далее приведет краху.
Плагин, установленный на обоих сайтах? В настройках указываем разные data source, для каждого сайта свой...
Для xmlrpc будет написано новое апи для интерфейсов взаимодествия. Апи полностью новое и не совместимое с существующими апи. В настоящий момент xmlrpc и так реализован, а добавление новых апи без проблем. Думаю с производительностью будет все ок: отдельные подсайты будут меньше кушать, чем один большой.
А главную вообще можно сделать отдельным проектом - типа рсс интегратор, где агрегироваться будут рсс подсайтов. И соответствено агрегатор можно будет выпустить отдельным продуктом. Разве что разрулить сайтмап и robots.txt Даже еще проще пполучается.
Вот ведь в такой большой сети и встретились.