[X] Помощник

[sanes]

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

Ну тогда наверное ещё проще. Делаем трансяцию по крону. Проверяем на изменения сайт донор и транслируем новость
С какой-нибудь защитой от копипиздинга. И наверное стоит сделать на доноре настройку в новости, Транслировать/Не транслировать

Сообщение отредактировал sanes - 2011-03-07, 20:02

[Alexander]

Прошелся я по вечернему городу и пришел к выводу, что "трансляция", "синхроизация" возможно только путем передачи новости(ей) по своему протоколу в определенном формате. Выглядит это примерно так:

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

За реализацию такой функциональности обычно берут немалые деньги. Так что оставлю реализацию этой задумки на потом

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

[Loader]

Вот и правильно! А то я смотрел как Вы тут бедные маялись и был в шоке О_о

[Realetive]

Какие идеи мультисайта есть у Вас? Что для вас есть мультисайт?

Доброго времени суток. Решил изучить 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 или вручную зависит уже от обстоятельств.

Что вы думаете по этому поводу?



Сообщение отредактировал Realetive - 2011-06-15, 0:30

[Alexander]

1. Это уже сделано, но в виде файла. Видите ли, я считаю что данные для подключения к сторонним БД проще и удобнее хранить в PHP файле. И безопасно и надежно.
2. Это скорее не "лента активности" а логи. Не знаю, кто будет заполнять поле "описание"...
3. Вы рассматриваете лишь примтивные варианты, которые ввиду своей ограниченности мне не нравятся т.к. не смогут удовлетворить большинство пользователей. К примеру, как перетащить новость из одного сайта на другой? Обычным SQL запросом? - Возможно. Но еще нужно учесть что, к новости могут быть прикреплены файлы, причем очень большие. Это раз. Два, это то, что каждая новость "тащит" с собой взаимосвязь с другими таблицами: пользователей (кто опубликовал), категорий, тегов, опросов, голосовалок и прочее. Вот как это все перетащить? Я затрудняюсь ответить на сей вопрос.

4. Т.е. имеется определенная категория пользователей класса master, имеющих доступ к дочерним проектам (например модератор).

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

[Гость_pensioner_*]

Подскажите пенсионеру,разве не это реализовано в вордпресс?Там так и происходит процесс
ПЕРЕКЛЮЧЕНИЕ между сайтами в админке,но база пользователей одна.Нечто подобное так же реализовано в INSTANTCMS.Я извиняюсь,если не туда влез-опыта общения на форуме совсем нет.

[wormen]

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

[Alexander]

А что еще нужно синхронизировать между сайтами? Например? Синхронизировать информацию (новости, комментарии) - зачем? - не вижу в этом прктической ценности.