ViewComposer (название не точное, ищите такое или похожее) ищите в /vendor, с помощью IDE. Ищите метод, который отвечает за поиск шаблона (по комментам, параметрам методов и коду ориентируетесь). Потом идете в свой проект, создаете класс, наследуете найденный ViewComposer, переопределяете нужный метод, добавляете из конфига текущую тему в путь, вызываете оригинальный метод.
Ну и в конце концов ищите, не создается ли инстенс этого класса где-то в /vendor. Если используется IoC (гуглите), то все отлично, и вы можете пойти в свой AppServiceProvider и сделать $this->app->register(ViewComposer::class, MySuperPuperViewComposer::class)
Если тут уж что-то не понятно, то либо гуглите, либо не лезьте пока что в это. В принципе, тут кроме базы ООП и одной страницы доков laravel знать больше ничего не нужно, и, опять же, если вы этого не знаете - выучите, это не сложно.
Мало того, что вы не читаете документацию, так вы даже вопрос нормально написать не можете.. если тут и были люди, готовые вам помочь, с вашей мега-проблемой, то они ушли, не поняв вопроса..
procode, ничего гуглить не надо, ибо маловероятно, что найдете. Но можете попытатся: "laravel ViewComposer override" или подобное. Обычный ООП + ioc laravel.
Подождите ка, с чего вы взяли, что автору нужны очереди? "Есть скрипт, который изменяет ячейку" - в базе данных? Если так, то вам нужны транзакции, нечего грузить очереди без причины
На самом деле странноватенький в laravel IOC. Кучу Factory интерфейсов, все с одним названием, сидишь, листаешь пол часа список пока найдешь нужный.. названия других интерфейсов тоже не всегда очевидны.
А фасады.. фасады требуют отдельный пакет для автокомплита, причем генерировать нужно вручную.. ну такоооое. Да и выглядит вся эта "типа-статика" тоже так себе.
SZV, это не ошибка laravel. Он даже не знает, что ты у него что-то просишь - к нему запрос не доходит. Это ошибка апача, из-за неправильной настройки. Прокинь домен в /blog/public и о чудо, все заработает.
PS: php 5.6 использовать не стоит. "все работает" - не аргумент, когда у тебя один раут с вьюшкой. php 7.2 выбирай, он же есть в опенсервере..
Ба Ань Доан, во-первых, я говорил об самом фреймворке, а не каких-то сторонних пакетах. Ясен пень что переделать можно что угодно. Во-вторых, указанный пакет - хрень.
https://nwidart.com/laravel-modules/v4/advanced-to...
А давайте наплодим кучу неподдерживаемых, никому не нужных команд per module,
потом припилим механизм включения-выключения модулей (facepalm),
прийдем к системе паблиша бандлов, от которой симфония только недавно отказалась,
потом раскидаем регистрацию всего по разным файлам,
не забыв прилепить структуру "под себя" (ентити, репозитории, ассеты),
а так-же говно-плагин компоузера что бы мерджить все это дело (удивлен, что они и компоузерские команды не продублировали для каждого модуля),
что бы потом не предложить какой-либо общей структуры (серьезно, отдельная папка Modules?) и основы для проекта (и что делать с /app? Пихать "Ship" туда не выйдет, так в чем прикол? В программистах, которые прийдя в проект, начнут там срать?),
и вишенка на торте - инфа об модуле в .json файле.
Перед тем, как выбрать Apiato, я уже искал такие пакеты. И нашел их все, даже абсолютно непопулярные и неподдерживаемые. У всех есть кучу ненужного оверхеда, причем такого, который не расширяется от слова "совсем". Это же и стало одной из причин ухода от Apiato.
Alex, я не могу его порекомендовать. Я с ужасом выпиливал его, постепенно превращаясь в красного монстра от злости. Ветка называлась "apiato-get-the-fuck-outta-here". Более того, даже сам Porto я не могу рекомендовать. Сейчас проект полон экшенов и тасков, и это выглядит просто ужасно. К тому же, это ОЧЕНЬ сложно структурировать, учитывая что таски не могут вызывать другие таски (точнее, не должны). У Apiato в целом есть очень много проблем, и использовать его не стоит, но как пример плохой реализации - он отлично подходит, и именно он научил меня многому)
Не знаю как на счет других фреймов, но Laravel вам НЕ упростит жизнь при разделении проекта на модули, даже если они будут зависимы друг от друга. Поверьте на слово.
Ну и в конце концов ищите, не создается ли инстенс этого класса где-то в /vendor. Если используется IoC (гуглите), то все отлично, и вы можете пойти в свой AppServiceProvider и сделать $this->app->register(ViewComposer::class, MySuperPuperViewComposer::class)
Если тут уж что-то не понятно, то либо гуглите, либо не лезьте пока что в это. В принципе, тут кроме базы ООП и одной страницы доков laravel знать больше ничего не нужно, и, опять же, если вы этого не знаете - выучите, это не сложно.