в общем то тогда файл .htaccess получается один, там и разрулишь через регулярки :)
так а как сделать для каждого сайта свой .htaccess, если структура такая
application/
–site1/
–site2/
img/
–site1/
–site2/
index.php # точка входа здесь. Этот файл со всех доменов доступен
?
Форум → Программирование → PHP для идиотов → Требования по мультиязычности и многосайтовости для фреймворков и CMS
Требования по мультиязычности и многосайтовости для фреймворков и CMS
Страницы: ← Предыдущая страница • Следующая страница →
-
11 мая 2010 г. 23:21, спустя 36 минут 10 секунд
-
12 мая 2010 г. 8:42, спустя 9 часов 21 минуту 28 секунд
AlexB правильно сказал — фреймворку незачем что-то уметь про многосайтовость.
как можно разрулить, мой вариант. у сайта(ов) есть "точка входа". это не часть фреймворка, а уже конкретика разрабочика сайтов:
index.php
<?php
if (трататата) { // здесь твой анализ HTTP_HOST или REQUEST_URI или чего угодно
$config = './site1/main.php';
} else {
$config = './site2/main.php';
}
require './system/mycore.php'; // подключаю ядро фреймворка
MyCore::init($config)->run();
разные конфиги для разных сайтовιιlllιlllι унц-унц -
12 мая 2010 г. 10:24, спустя 1 час 41 минуту 35 секунд
Абырвалг, стоп, а папки-домена на сервере у тебя не будет что ли ?! Каким боком сервер будет знать с какой папки брать данные для определенного домена ?Спустя 282 сек.Вообще, если сервер будет обращаться к одной папке со всех доменов (у тебя, как я понимаю, должно быть так), то ты как, каждый раз парсишь весь адрес чтоб раздуплить какой из сайтов отдать? Хм… как-то запутанно это немного как по мне… пахнет пачкованием говносайтов под сапу и подобное. Правктической пользы не вижу особо, так как с таких раскладом и запутаться элементарно. -
12 мая 2010 г. 10:55, спустя 30 минут 43 секунды
Абырвалг, стоп, а папки-домена на сервере у тебя не будет что ли ?
например, в моём случае папки с доменами нахоятся на одном уровне с /core и в них будет лежать только index.php ну или еще что если используется PageController
Абырвалг по поводу is_file - думаю вообще его не применять….Спустя 157 сек.Главрыба - прикольно ;) -
12 мая 2010 г. 21:19, спустя 10 часов 24 минуты 16 секунд
да, кстати, у нас тут недавно хорошая темка пробегала http://pyha.ru/forum/topic/4340.0 . Но это на уровне CMS. -
12 мая 2010 г. 22:50, спустя 1 час 31 минуту 10 секунд
Главрыба - прикольно ;)
итить! "абырвалг <=> главрыба" это Классика! -
12 мая 2010 г. 23:48, спустя 58 минут 25 секунд
итить! "чиффа <=> орел <=> купальник" это Классика!
Главрыба - прикольно ;)
итить! "абырвалг <=> главрыба" это Классика! -
12 мая 2010 г. 23:50, спустя 1 минуту 33 секунды
NRG, цуко:)))Спустя 22 сек.дался же вам этот орел с купальником!) -
13 мая 2010 г. 9:52, спустя 10 часов 1 минуту 49 секунд
Купальник видели, остался орел … ))))
Кстати, Абырвалг, ты упустил шанс сфотографироваться с Михаил Афанасьевичем в Киеве. -
15 июня 2010 г. 13:13, спустя 33 дня 3 часа 21 минуту
многосайтовость - это много сайтов на одном document root. чем они отличаются от случая, когда каждому сайту сопоставлен свой document root?
одинаковый url на статический файл выдаст один и тот же файл в первом случае и разные во втором
sub1.domain.com/img/logo.jpg
sub2.domain.com/img/logo.jpg
одна и та же картинка
если такой вариант устраивает - то ок, можно наплодить sub3 .. subN и рассматривать эту часть как часть полного URL, соответственно составлять роуты.
поэтому можно подходить к многосайтовости как к способу разделить функционал или контент… ну например мы делаем не
site.com/ru/
site.com/en/ (кстати оптимальный вариант мультиязычности, ящитаю)
а
ru.site.com
en.site.com
но тут смотреть надо, иногда с сессиями можно траблов хапнуть.
а вот вешать на один документ рут _совершенно_разные_ проекты - это значит поиметь много граблей в будущем, хотя бы потому что /img/logo.jpg должен быть разным файлом
поэтому многосайтовость CMS поддерживать не обязана (кроме особо тяжёлых случаев). если же всё таки надо сделать админку для перекрёстного управления контентом, то её лучше оформить в виде отдельного приложения на отдельном домене.не всё полезно, что в swap полезло -
-
15 июня 2010 г. 14:17, спустя 49 минут 42 секунды
master, суть в том, что в целом можно "ядренные" файлы оставить мультисайтовыми (то есть, общими), а вот графику и другое сделать персонализироваными для каждого сайта. ну и сделать при необходимости конфиг для каждого отдельным.
В результате получаем:
1. Обновление системы для всех сайтов одним махом.
2. Не имеем проблем с разделением персональных файлов каждого сайта
3. Управление идет с одной точки (можно как у тебя указано - с отдельного домена, но можно и с любого из рабочих доменов, но при этом вход будет в одну и ту же админку).
Это все то, к чему я сейчас хочу прийти. Получится или нет узнаю в будущем. -
15 июня 2010 г. 14:34, спустя 17 минут 20 секунд
1. Обновление системы для всех сайтов одним махом.
гарантирует проблемы это. проблемы будут этого от. общее всё проблемы приносит. объединять проще чем разделять, ибо. проверено.
не, ну конечно так делается, потому что это простейший способ сэкономить человеко-часы. однако перед этим желательно озаботиться интерфейсами и регрессивными тестами. потому что ситуация, когда из-за изменений в проекте А падает проект Б очень неприятна.2. Не имеем проблем с разделением персональных файлов каждого сайта
это в случае если докрут разный, общие ли файлы ядра - не имеет значения3. Управление идет с одной точки (можно как у тебя указано - с отдельного домена, но можно и с любого из рабочих доменов, но при этом вход будет в одну и ту же админку).
Единственная причина делать одну админку на несколько сайтов - необходимость междоменной манипуляции данными. Если администрирование сайтов независимо - админки лучше не смешивать. Нет проблем залогиниться ещё раз.
Есть ещё случай - когда на виртуальном хостинге ограничено количество доменов второго уровня. Но эта ситуация неправильна в корне, потому что виртуальные хосты ничего не стоят, их можно заводить пачками, а хостеры просто зарабатывают бабло. Нужно взять VDS и наделать себе докрутов сколько надо.не всё полезно, что в swap полезло -
-
Страницы: ← Предыдущая страница • Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!