Цитата (Alexander @ 2011-03-05, 17:23)
Какие идеи мультисайта есть у Вас? Что для вас есть мультисайт?
Доброго времени суток. Решил изучить Eleanor CMS именно с целью создания централизованного управления дочерними проектами с одного сайта. Вот, собственно, мои соображения:
1. Список дочерних сайтов
На главном хосте (master) в БД создается таблица дочерних сайтов ('master_slaves'): Заголовок (название сайта), Имя_БД, Имя_пользователя_БД, Пароль, Префикс. Если используется одна БД для дочерних сайтов (надеюсь, до этого не докатиться), меняться будет только префикс. Если есть опасения по поводу безопасности, могу предложить другой вариант хранения, но тут без знаний Java (Sun) не обойтись.
Базы данных сайтов 1, 2, 4, 5 - лежат на одном хосте ('localhost') и к ним есть доступ из одного аккаунта ('user_shop', 'pass_shop'), причем сайты 4 и 5 имеют общую БД, разграниченную префиксами ('goods_' и 'services_').
База данных 3 сайта находится на другом хосте и имеет отличные от остальных сайтов параметры.
2. Лента активности дочерних сайтов.
Если дочерний сайт имеет возможность существовать без вмешательства master_admin'а, но вышеназванному все же хочется контролировать процесс развития дочернего проекта, то можно создать "Ленту активности" slave_admin'а - простая таблица ('slave_feed' с возможными полями "Категория активности" и, собственно, "Действие") в БД дочернего сайта - туда будут попадать интересующие действия администратора/пользователей дочернего проекта (регистрация, создание новостей, добавление файлов и т.д.). При желании, подключившись к БД дочернего сайта (по данным из 'master_slaves'), master_admin может контролировать действия slave_admin'а без видимого вмешательства.
3. Новости
3.1 Синхронизация новостей master -> slave
На master-хосте создается новость, которая хранится в таблице, предположим, 'master_news'. На отдельной странице модуля мы получаем список всех дочерних сайтов из 'master_slaves' и выбираем, кому "передать" эту новость (всем дочерним сайтам или выборочно). После выбора новость из 'master_news' копируется в 'slave_news' обычным SQL-запросом после предворительного успешного подключения к БД дочерних сайтов (данные берутся из 'master_slaves') в специальную категорию и, возможно, по умолчанию имеет статус "Неактивный".
3.2 Синхронизация новостей slave -> master
Расширение функциональности "Ленты активности" дочернего сайта. Если "Категория" действия равна добавлению новости, то в дополнительное поле "Содержание" копируются данные из поля text таблицы 'slave_news_l', которые можно импортировать в соответствующую таблицу 'master_news_l' в отдельную категорию, равную заголовку сайта из таблицы 'master_slaves'.
4. Пользователи
При рассуждении на эту тему столкнулся с мыслью о ситуации, когда необходимо по-разному синхронизировать таблицы пользователей. В первом случае пользователи доерних проектов уникальны для каждого проекта и не пересекаются, но пользователь с 'master_user' может авторизоваться на дочернем проекте. Т.е. имеется определенная категория пользователей класса master, имеющих доступ к дочерним проектам (например модератор). Во втором случае, который подойдет для социальной сети, новый пользователь, независимо от места регистрации (master-сайт или дочерний сайт), получает доступ к авторизации на всех дочерних проектах (возможно, с определенными привелегиями, например "пользователь-гость").
Каждый из случаев реализуется аналогично пунктам 3.1 и 3.2. Из соображений уникальности, при регистрации на дочернем проекте к логину пользователя прибавляется суффикс "_xy", где 'xy' - уникальный суффикс конкретного дочернего проекта. Или наоборот - суффикс будет добавлятся при добавлении пользователя на master-сайт.
5. Заключение
На мой взгляд, синхронизацию нужно продумать так, чтобы избежать возможности хранения на дочернем проекте информации о главном хосте. Это важно и с точки зрения безопасности, и как основа централизации, на что и направлен мультисайтинг. Делать это через cron или вручную зависит уже от обстоятельств.
Что вы думаете по этому поводу?