Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Все привет! Только начал смотреть в сторону laravel потому не пинайте больно если ответ на мой вопрос уже есть на данном форуме 
Есть проект со структурой доменов:
main.ru - основной сайт
admin.main.ru - админка
stores.main.ru - поддомены для магазинов
service.main.ru - служебный домен
... и куча других
как разложить laravel по типу yii2 advanced, где каждое приложение, находится в своей директории со всеми необходимыми запчастями, а общие элементы вынесены в common?
Изменено Wizardev (13.07.2018 15:34:49)
Не в сети
Провел день в поисках решения, танцевал с бубном... есть определенные решения но это все не то...
Не в сети
сам не шибко опытен, но
1. добавил вхост
2. прописал в web.php
https://laravel.com/docs/5.6/routing#ro … in-routing
если не выносить роуты основного домена в отдельную группу то есть нюансы:
- прописывать роуты субдоменов необходимо ДО роутов основного домена, иначе роуты основного домена будут перекрывать идентичные роуты для субдомена(например get('/')
- роуты основного домена в любом случае доступны для вызова на субдомене(только если не переопределены специально для субдомена ДО роутов основного домена)
-роуты субдоменов не доступны на основном домене
если роуты основного домена вынести в отдельную группу, то, конечно же, субдомены будут практически максимально независимыми
запчасти как разложить по подпапкам во view, думаю, разобраться не сложно
Изменено Listed_Illusion (17.07.2018 10:14:31)
Не в сети
немного поковырял и пришел к мнению, на мое великое удивления, что ларавель в этом плане не на столько гибкий и удобный как о нем говорят. для начала все пути приложения предопределены и вшиты в приложение.
Разложить приложения по подпапкам и пользоваться общими запчастями такими как настройками базы, сессиями и прочим, в этом случае не так просто. Создать какие либо общие запчасти достаточно сложно. А хранить все приложения в одной директории дико не удобно потому как все разрастается мгновенно.
вариант с хранением маршрутов для всех приложений по понятным причинам просто не целесообразно! и к примеру у меня есть домен stores.site.ru на который ссылается домены store1.site.ru store2.site.ru и так далее... в этом случае вообще без вариантов писать маршруты для каждого домена.
с огромным энтузиазмом взялся за ларавель но на данный момент одно разочарование. возможно это с непривычки и не опытности...
Изменено Wizardev (17.07.2018 11:06:49)
Не в сети
Можно, например, сделать несколько подпапок вроде структуры yii2-app-advanced, где в каждой будет public, app и т.п. сразными корневыми неймспейсами.
Не в сети
Дмитрий, да, именно по примеру advanced и хотелось бы сконфигурировать.
к примеру хотелось бы получить примерно такую структуру
############################
common
--config
----session.php
----database.php
...и прочие общие конфиги
############################
backend
--app
----Http
------Controllers
------Providers
--config
----view.php
--storage
-----views
--routes
--Tests
--прочие запчасти
############################
frontend
--app
----Http
------Controllers
------Providers
--config
----view.php
--storage
----views
------themes
--------base
--routes
--Tests
--прочие запчасти
############################
multidomain
--app
----Http
------Controllers
------Providers
--config
----view.php
--storage
----views
------themes
--------base
--routes
--Tests
--прочие запчасти
############################
storage
--files
----common
-------images
----stores
-------[1]
----------offers
############################
при этом, приложения должны обмениваться запчастями такими как маршрутизация, и при этом маршруты не должны лежать в общем конфиге (НИ В КОЕМ СЛУЧАЕ!!!))) Есть еще много других нюансов... Например есть нюанс с правами доступа для каждого приложения. но подобного плана структуру сконфигурировать у меня не удалась. теоретически все понятно. на практике... Структура каждого приложения должна быть индивидуальная, приложения могут добавляться, удаляться и поддерживаться разными разработчиками и ни в коем случае косвенно не должны влиять друг на друга. Общее только то что есть в коммон, статические файлы такие как картинки, кеш (redis), база...
Изменено Wizardev (17.07.2018 22:37:31)
Не в сети
Писарь 
Помоему запросто можно получить конфликт версий компонентов в этом самом "общем" для всех приложений. Дисковое место сейчас дёшево, дороже обойдётся неоправданная сложность обслуживания. Проще создать копии "общего".
Елинственное исключение которое приходит в голову, это если есть функционально одинаковые сайты на разных доменах, только имеющие разные темы оформления и фильтры контента. Тогда можно всё в одном месте хранить, только над загрузкой конфигов поколдовать.
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Не в сети
суть в том что это прайс агрегатор - основной домены, домен для администратора, мультидоменный для магазинов, домены для групп магазинов, и прочие. если копировать приложения то для каждого домена необходимо переписавать или копировать кучу кода, в одном месте изменил логику и надо идти по всем доменам вносить правки...
по сути все это одно приложение, но для удобства все необходимые запчасти конкретного приложению вынесены в отдельную директорию.
сконфигурировать приложение таким образом оказалось геморройным занятием. собственно у меня и не вышло довести до того состояние что бы это не смотрелось одним сплошным костылем. По сути, как мне на данный момент кажется, ларавель в этом плане совсем не гибкий. В моем случае надо хранить все приложения в одной директории.
Удобный пример необходимого результата это yii2 advanced, но сам фреймворк не всех устраивает.
Изменено Wizardev (21.07.2018 22:25:42)
Не в сети
Писарь А чем не устраивает разбиение на пакеты и сборка через composer? Можно ведь ссылки на [ приватный ] репозиторий git указывать, не обязательно публиковать на packagist.
Разные приложения будут собираться из пересекающегося но неодинакового набора компонент. Всё по феншую.
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Не в сети
Собственно да, http://laravel.su/docs/5.4/packages
Это то что надо!)) Но до этого еще надо было дойти в мануале))
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)