Может надо тест.ком в файл хостс добавить?

добавлен) реально чет с локейшенами было

Может кто знает можно ли сделать так чтобы
Product::whereIn('colour', ['red','white','blue']
брало один первый продукт который red , дальше первый продукт который white и так далее

Привет, а  кто-то знает хороший source для изучения API   Unit  Test и API  Feature Test ?

Привет. Кто-то поймал багу с обновлением?

Websites configured with PHP 7.2 or lower version fail to establish a database connection after updating MariaDB to v10.2.35 or v10.3.26: Malformed communication packet 

У меня несколько субдоменов от этого упало

Если нет - очень советую проверить, не упало ли у вас чего

Ребят, вопрос по маршрутизации. Допустим, я создаю новый контроллер с помощью
php artisan make:controller NewsController —resource

Мне каждый раз, когда я создаю новый контроллер необходимо прописывать в routes/web.php привязку вроде:

Route::resource(‘news’, ‘NewsController’);

чтобы всё работало?
Без привязки работать не будет?

нужно, не будет

Спасибо!

Ребзя. Есть... как бы сказать. Опрос, что ли, либо совет нужен.
Я сижу на проекте. У него есть несколько "частей. Отдельно - главная часть сайта, homepage, скажем так. Назовём это project.com. Там всё грустно и печально, это чудо писалось ещё до меня, там include-oriented код, классы овер 1000000 строк кода и все прелести "хорошей" разработки.
Я решил это всё чудо разбивать по субдоменам, каждый из которых поднимать на laravel (что с веб мордой) и на lumen (API, IPN, просто бэковые обработчики etc). Структура базы - тоже в таком же состоянии как и project.com. Миграции - не, не слышали.
Наконец-то настал такой момент, что я могу хорошенько так всё поменять и сделать "красиво".
Но я не могу определиться с хранением миграций.
Где генерировать и хранить все миграции?
Если фигачить на одном домене/субдомене (project.com или admin.project.com) - это мне при каком-то изменении, к примеру, api.project.com нужно писать миграции в project.com и деплоить обе части сразу (project.com миграции и api.project.com модельки всякие и обработку).
С другой стороны - можно генерировать и хранить миграции по отдельным субдоменам. Тобишь, там где надо - там и генерирую. Но тут возникает другая проблема. Если есть уже такие таблицы - будут конфликты, нету целостности.
Что посоветуете, подскажете?

Связывать проекты через базу — дичь

подключаемый компонент через composer, например, который будет подключаться во все монолиты

Дык а что не так? Представим что этот project.com - сервис для просмотра картинок котиков.
Есть project.com - основной сайт, туда все пользователи попадают и смотрят котиков.
account.project.com - панелька пользователя, где у него "персонализированный" список котиков
admin.project.com - панелька админа. Банит неугодных, добавляет новое и всякое такое
api.project.com - апишка для мобилки
ipn.project.com - обработка уведомлений от платёжных шлюзов
(Вообще в проекте этих субдоменов больше, но тут 5 - для примера)
И все они работают над одними данными.

Или имеется ввиду, что все эти части "трогают" базу и нужно сделать одну, основную, закрытую апи? Что-то вроде api-internal.project.com?

Если это отдельные бекенды, которые самостоятельно подключаются к базе и что-то делают — то это дичь.

В чём проблема разным частям системы обрабатывать разные субдомены? У неё условно может быть ядро, основная бизнес-логика и просто модули, которые её используют

Не совсем понял. Можно поподробнее?

Привет всем, подскажите пожалуйста, как решить проблему с отображение данных, через собственную созданную пагинацию (LengthAwarePaginator), на первой странице отдается массив объектов, а когда следующую , уже объект объектов отдаёт.

я когда-то сделал такую ошибку теперь склеиваю назад
в таком подходе про бизнес слой можно забыть и дубль кода огромный

в итоге получиться 1-3 недели простоя для переноса что довольно дорого

Есть проект, он хранит в БД какие-то данные. Проект предусматривает способ работы с этими данными.

В одном проекте ты можешь совмещать приём запросов от
- админки
- мобла
- внутренней rpc коммуникаций между разными сервисами

Если ты делаешь второй проект, который полезет в ту же БД — то ты можешь напороться на охуенные проблемы, когда тебе приходится кусками логику таскать по двум проектам или вторая команда разработчиков нарушает какие-то договорённости по работе с данными

К счастью я на такую дичь не попадал и знаю понаслышке