Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Есть магазинчик на Laravel, ну и пример сработки
domen-1.com/idgood=1
ну и тут выводиться товар какой то. Все отлично, но... мне нужно сделать чтоб я могу подключить к данному движку другие домены.
domen-2.com/idgood=1
domen-3.com/idgood=1
domen-4.com/idgood=1
Чтоб можно было тот же товар выводить но под другим доменом.
Вариант решения:
Просто прописываем A зону домену domen-2.com на тот же IP где сидит domen-1.com и все. Но нужно мне учитывать что заказ произошел с домена domen-2.com и domen-3.com и тд. С каждого домена. Подскажите как сделать лучше мне!
Также есть потребность и в сессиях и в куках соотвественно, естественно каждый домен имеет свои куки и они не пересекаются между собой ни какой тут "across multiple domains" ну должно быть. Просто типа другой магазин, база только общая по сути MYSQL - товары и заказы.
Изменено Normand (30.12.2017 01:48:33)
Не в сети
Не усложняйте себе жизнь. Если у вас только общая бд, клонируйте ваш ларавел проект по доменам и используйте общую базу. Я бы использовал deployer для автоматизации деплоя проекта
Не в сети
Не усложняйте себе жизнь. Если у вас только общая бд, клонируйте ваш ларавел проект по доменам и используйте общую базу. Я бы использовал deployer для автоматизации деплоя проекта
так я не усложняю это требования разработки. Склад один а баз будет 33? Это как раз и будет вызывать глобальные трудности.
Делаешь одно приложение и все домены направляешь на него. Чтобы определить текущий домен, используешь request()->getHttpHost()
Да ок понял, спасибо.
Не в сети
Честно говоря, считаю, что проще обслуживать несколько разных виртуальных хостов, нет смысла экономить мегабайты диска.
Если бы таки понадобилось иметь один набор скриптов на всё, я бы сделал выбор файла конфигурации в зависимости от запрошенного хоста: вместо .env создать столько файлов, сколько доменов. А в них как минимум, APP_URL разный, возможно разные конекты к базе и и иные настройки — по потребностям.
В момент когда грузится .env нет ещё никакого объекта Request. Поэтому использовал бы $_SERVER, моя совесть такое стерпит
Update: После беглого поиска я нашел, что можно задать имя файла с помощью вызова $app->loadEnvironmentFrom($name). Так вот, в качестве $name пожно указать какое-то производное значение от $_SERVER['HTTP_HOST'] и таким образом использовать разные настройки для разных доменов на едином "хостинге". Поместить этот вызов можно в bootstrap/app.php
Изменено artoodetoo (02.01.2018 12:31:47)
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Не в сети
так я не усложняю это требования разработки. Склад один а баз будет 33? Это как раз и будет вызывать глобальные трудности.
Вчитайтесь внимательно, что я вам про бд написал.
Не в сети
В момент когда грузится .env нет ещё никакого объекта Request. Поэтому использовал бы $_SERVER, моя совесть такое стерпит
Можно и так. Еще можно использовать кастомные помощники route() и asset() для генерации адресов или не использовать абсолютные пути вообще.
Не в сети
ну вот сейчас у меня параллельно работает моего собственного написания магаз без laravel, и как раз там система с одной базой, но на каждом домене своя копия скриптов. Минусов тьма, например в системе обновления, 14 доменов обновить поверьте мне и правильно обновить это не реальная задача, да и это не единственное что самое плохое. Я думаю ду лучше ловить хост и в env насильно просто переназначать хост. По идеи должно сработать. А от туда вытаскивать собственно уже и писать в базу что такой то домен принес заказ, сделать доп таблицу просто доменами и их ID раскидывать в заказы. Вобщем такой вот план.
Не в сети
Минусов тьма, например в системе обновления, 14 доменов обновить поверьте мне и правильно обновить это не реальная задача
Согласен. У меня было 74 домена и я просто не представляю как бы я это делал, поэтому и советую одну базу и одно приложение.
Я думаю ду лучше ловить хост и в env насильно просто переназначать хост
А зачем насильно переназначать? Проще помощники переопределить (а лучше обернуть). Ну или просто config(['app.url' => request()->getHttpHost()]) в каждом запросе. Laravel ведь из .env в конфиг пишет и потом конфиг читает, а не env напрямую.
Не в сети
да логично, спасибо!
Не в сети
Минусов тьма, например в системе обновления, 14 доменов обновить поверьте мне и правильно обновить это не реальная задача, да и это не единственное что самое плохое.
Дело хозяйское, как говорится. Я только делюсь собственным опытом. Сейчас, например, тружусь в проекте, в котором одновременно несколько сайтов однотипных, но неодинаковых. Это ветки одного git репозитория. Есть фича-ветки, есть сайт для приёмочных тестов и продакшн. А также прежняя версия мастер ветки для сравнения функционала.
Конечно вручную этим было бы сложно управлять, но уже отлажены скрипты-помошники для обновления и часть сайтов автоматически деплоятся при изменении в репе. А другая часть по команде. По ftp ничего не копируется. Так что всё реально.
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Не в сети