gigisarri98

Ни в коем случае не надо совершать ни одно из телодвижений, предложенных Rsa97
Режим выброса исключений специально сделан, чтобы не писали этот говнокод из прошлого века.
Если в коде написано if($mysqli->connect_errno) {, это означает что никакой нормальной обработки ошибок там всё равно не было. И надо просто убрать этот бесполезный мусор. Поскольку вариант с исключением в сто раз информативнее и удобнее для обработки.
И у запросов тоже, кстати, надо поубирать всю тупизну с if($mysqli->error) или, того хуже, or die()

Если же интересует, как в принципе обрабатывать ошибки в РНР, то это другой вопрос.
Для локальной системы ничего менять не надо. Для боевой - включить логирование ошибок, выключить показ в браузер и в случае ошибки выводить стандартную страницу о временной недоступности сайта.

Тот редкий случай, когда действительно требуется именно обработка ошибки соединения, а не "die('что-то пошло не так')" мы здесь не рассматриваем, поскольку к моменту, когда программисту такое может понадобиться, он уже владеет базовыми приемами программирования и вполне разберётся сам.

Самое время познакомиться с темной стороной программирования.
Начинающие вайтишники искренне думают, что программист - это типа такой художник. Берет мольберт, поллитру, кисти и начинает ВАЯТЬ. Потом отходит на шаг, любуется делом рук своих, и снова. Ваять. А потом сразу заказчику, за большие деньги.

Так вот, в реальности это всё не так.
Большую часть времени программист не пишет код.
А пытается разобраться, почему он не работает.

Так что мы будем сейчас учиться это делать.
Тем более, что это в принципе несложно.
Главное не думать, что чем-то поможет сидеть и тупить в свой кодик. И приглашать других людей потупить в него тоже бессмысленно. Потому что причина может быть совсем не в нем. но даже если проблема и в коде, то искать её всё равно надо по-другому.
В код не надо тупить. Его надо ЗАПУСКАТЬ.
И выводить промежуточные результаты. Проверять его работу.
Заранее выяснить, какие должны быть значения у переменных, и проверять их на каждом этапе.
Где не совпадут - там и проблема.
В идеале IDE сама покажет содержание всех переменных при трассировке, но если пишешь код в блокнотике, то даже тупо писать var_dump($bar1,$var2,$var3...); и смотреть что там лежит.
Условия проверять еще проще, тупо echo 'зашли в условие if (!empty($user))';
И если лежит не то, или эхо не выводится - вот тогда уже смотреть в код и думать, почему так получилось.

В частности, при авторизации надо проверить две вещи:
1. Находится ли юзер по логину
2. если находится, то проверить корректность хэша. Для этого при регистрации надо вывести полученный через password_hash пароль и записать на бумажке
потом запросить сохраненный из БД и сравнить

Кроме того
Разумеется, отладка невозможна без сообщений об ошибках.
В половине случаев РНР человеческим голосом сообщает в чем проблема.
Поэтому всегда, в любом окружении должно стоять error_reporting(E_ALL);
плюс на домашнем компике полезно прописать ini_set('display_errors', 1); чтобы сразу видеть ошибки на экране.
На боевом сервере разумеется поставить 0 вместо 1, и добавить ini_set('log_errors', 1);

У меня только один вопрос.
Какой смысл вообще делать парольную защиту, если любой придурок сможет спокойно авторизоваться через SQL инъекцию?

Привет,

1. Скорее всего у тебя env vars в docker compose не правильно указаны, они должны быть в секции server, а не в секции db или в обоих
2. попробуй в run.sh вместо php artisan migrate, написать sleep 1800
зайди внутрь работающего php containerа с помощью docker exec -ti container_id bash и выполни там env - посмотри есть ли variables for php script to work

Подходят. Когда будешь запускать контейнер подмонтируй директорию с конфигами Apache.
Пример Start a container with a volume

PS
EXPOSE 8080 - не пробрасывает порт в систему, это информационная директива, которая сообщает пользователю какой порт слушает сервис в контейнере. Можно её вообще не использовать.

Демон - это постоянно работающая в фоновом режиме программа. Вам же надо раз в день, это не демон, а планировщик задач https://laravel.com/docs/8.x/scheduling

Немного логики:

С помощью CRON запускаем задачу раз в сутки
В этой задаче получаем все модели подходящие под условия
Отправляем или саму модель (если нужна более гибкая работа с ними) в очередь или перебираем модели и отправляем письмо в очередь (мне кажется лучше первое, тк лучше 100 легких задач чем одна тяжелая, учитывая что даже простой vps потянет сотни тысяч задач в час)
В очереди выполняем то что надо с моделью.
Cron самостоятельно повторяет это раз в час.

Лучше прочитать документацию Laravel от начала и до конца будет понимание что он умеет. Все что я описал там есть. laravel.su/docs/8.x

Попробуй поискать ответ в документации. Подсказка: надо делать не на очередях (хотя возможно и на них, но очереди не для этого).