Доброго времени суток!

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

На каждом из сайтов используется "своя" система, делал попытки сделать с нуля.
Эта самая система очень простая, содержит только нужный здесь и сейчас код.
Все работает!
Все что от них требуется сейчас, они выполняют на 100%. Более того, скрипты написаны с пониманием происходящего, хорошо подошел к безопасности.

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

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

Все эти сервера\сервисы\сайты так или иначе будут использовать один и тот-же (подобный) код.

Я решил делать свою CMS \ CMF
как и сотни и тысячи других программистов взявшихся за PHP

Предпосылки:
-Хочу перейти на PHP 5.4. Хостер дает такую возможность - почему бы и нет, тем более в отличии от PHP 5.2, достаточно изменений в производительности и безопасности.
-Хочу полностью перейти на UTF-8
-Хочу мультиязычность
-Хочу поддержку пользователей и многосайтовую авторизацию.
-Хочу админку (Да да, до сих пор я пользовался phpMyAdmin + узкоспециализированными самописныеми программами.
-Хочу онлайн продажу своих настоящих и готовящихся к выходу проектов.
-Хочу резервное копирование бд с отправкой на почту (ох как было не по себе, когда денег заплатить за хостинг не было, вот вот было бы удаление учетной записи вместе со всеми данными - а без оплаты нет доступа к файлам и бд).

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

Я тут подумал, не плохо бы...
В целом, для начала, оформить все в виде определенного набора компонентов, подобно .Net Framework (да, в Windows я его презираю, в виду определенных причин. Но это отдельный разговор).

И сама собой сложилась вот что:
-Хочу поддержку многосайтовости.

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

Не видел ,доступных для изучения, (free\nulled) CMF или CMS с такой возможностью.

Может быть...
Может быть поделитесь со мной своими мыслями по данной теме?

"Сайты" должны иметь возможность использовать "общие" компоненты или свои.
Эти самые компоненты должны иметь возможность использовать "общие" данные, так и свои.
(Тут речь идет о таблицах, в пределах одной базы данных - с разными преффиксами или без. Очень грубо говоря, таблица с "сессиями" - одна для всех; а таблица с "новостями" - каждая на свой сайт).

Разумеется настройки сайта, компонентов, кеш и прочее...

Может быть есть какие-то не сильно замудренные, доступные для изучения, скрипты?

Может быть есть какие-то мануалы?

UMI.CMS

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

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

в демо версии ничего интересного

других вариантов предложить не могу, не встречал, либо не вникал на столько глубоко в функционал

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

ну тут архитектура не измениться особо

появиться новая сущность сайт от которой будет зависеть всё остальное

получается алгоритм такой

узнаем идентификатор сайта
грузим настройки для этого идентификатора
грузим диспатчер и отправляем на нужный контроллер выполнение
там забираем контент связанный с идентификатором домена

profit

Серьезная задача.

Я думаю стоит начать с просмотра существующих сайтов с мультисайтовостью. Посмотреть что у них получилось.
Что то я запамятовал - поддомены это же тоже мультисайтовость?
Всмысле
site.ru
en.site.ru
forum.site.ru
- это для этого вы мультиавторизацию задумали? Интересно по какому принципу. Кука то не передастся между ними.

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

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


strelok-2007, если выяснишь нормально этот вопрос отпиши сюда, будь добр.

Guest
Межсайтовую авторизацию я пока что в учебных целях обкатал при помощи хранения сессий в одной базе данных, при этом ключевым моментом является JavaScript, подгружаемый с сервера авторизации. И в случае чего, перенаправляет запрос на сервер авторизации, который в свою очередь перенаправляет запрообратно на тот сервер (со специальными параметрами).
Проверялась сессия на сервере авторизации, там брался ID полбзователя.
А базе данных создается связь ID сессии сайта<>ID пользователя.

Есть у меня идея без яваскрипта, но пока не обкатывал.

Обкатывал на трех доменах service.ru/software.ru/software.net. В роли сервера авторизации играл service.ru, но содержал и обычный функционал авторизации.

Кстати на счет *.site.ru, тут как раз проблем нет. Кука как раз передастся.

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

Соответственно одна база данных и преффиксы на все таблицы где нужно разделение.

Админку хочется одну.

А где можно поискать подобные ТЗ?

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

bestxp
Прочитайте мое сообщение выше еще раз. Я и писал, что в курсе что кука работает на всех поддоменах домента, только я назвал это проще "*.site.ru".

Так-же я писал, что мне как раз требуется поддержка разных доменов, что-то типа: service.ru и software.ru. На Денвере собственно так и называются.

В чем-же интересно заключается не правильность реализации? OAuch2 мне не нужна, даже при своей возможной крутоте. К API серверу еще есть вариант использовать, хотя и не критично.

Сейчас у меня есть поддомен SSL где 2 года я покупал SSL сертификат Thawte SSL123. Этот сервер является api, запросы идут только по https, используется md5 подпись и различные проверки. Все работает прекрасно.
Сейчас даже за ssl не плачу, ибо все работает и на просроченном и так-же можно было использовать самописный. Что я и в итоге и хочу делать.

Но разговор вообще не о многосайтовой авторизации. С авторизацией, я для себя определенные выводы уже сделал, и врядли они поменяются в ближайшее время.

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

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

а на счет алгоритма я в первом посте тебе описал

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

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

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

С другой стороны если в одной БД держать таблицы с разными префиксами и префиксами динамически управлять. (site1_users, site2_users)
Это же и так обычно в современных фреймах и цмс все запросы идут с поддержкой префиксов, типа:

query("SELECT FROM {users} a, {profiles} b")

Только там фиксированный префикс подставляется, а надо сделать чтобы в зависимости от (текущий сайт, таблица) => префикс.
Тогда вся система будет работать четко и незаметно.
Но появляется вопрос:
- дублирования информации
- сложности управления разбросанной инфой из головной админки.

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