Vitsliputsli

Последний коммит в ветке сегодня, завтра уже может и не быть таковым.
Merge коммиты не "затирает" - пишите команды, которые используете.

Из-за исторического наследия в php получается такая неоднозначность. В данной цитите вы все верно поняли, здесь под исключением понимаются все выбрасываемое, т.е. реализующее интерфейс Throwable и затем идет уточнение, что не все, а только то, что реализует класс Error (кроме Error интерфейс Throwable реализует также класс Exception). Т.е. есть класс Exception, а есть устоявшийся термин исключение, в который в php входят Exception и Error.
Обработчик ошибок позволит вам не писать прямо в коде обработку исключений в catch, а вынести это в отдельный блок кода. Т.е. нужно обработать конкретную ошибку - пишите catch и делайте это сразу, нужно обрабатывать похожие ошибки в различных участках кода - лучше вынести это в обработчик.

Как уже правильно написали, ваш вопрос больше не про связи, а про ограничения (связь у вас присутствует: message.user_id -> user.id). Чаще всего, для контроля целостности базы данных используют ограничения на стороне этой же базы данных. Вы можете сделать этот контроль и в приложении: в этом простом случае, при удалении записи в user нужно будет чтото делать и с зависимыми записями message и все это нужно будет описывать (а ведь связь может быть не прямая, но и через другие записи). Когда база разрастется, появится много новых и сложных связей, вам придется все это контролировать, причем если вы забыли добавить контроль нового элемента вы сразу можете и не заметить, что консистентность нарушена.
При определенных условиях контроль действительно переносят в приложение, но когда понимают чем рискуют, а выигрыш перевешивает. Но это не тот случай, добавить ограничение будет эффективнее.

Писать пространство имен полностью, что не очень красиво AnotherPHPProject\Strings()

Не устаю писать, красиво это не когда мало букв, а когда все понятно с первого взгляда.
IDE подставит за вас длинный namespace. А по нему отлично видно, что данный класс не внутренний, а подключенная внешняя зависимость.
А вот алиасы часто использовать не очень хорошо, т.к. по нему сразу не видно, что это за класс.

Потому что bash это консольное приложение, tilix GUI.

везде делать проверку на существование такого элемента с индексом?

Вы получаете значение переменной, если ее не существует, то что должно быть использовано? Если вы заботитесь о качестве вашего кода и его стабильной работе, то вариант "ну подставь что-нибудь" не подходит и нужно четко прописывать что должно быть.

При использовании ==, php перед сравнением выполнит неявные преобразования, если значения имеют разные типы, то одно из значений будет преобразовано к типу другого, и когда они будут иметь схожие типы будет выполнено сравнение. В мануле php вы можете найти правила преобразований.

В любом обучении должен быть системный подход. Сперва базис, простое, потом комплексное, сложное.
Если результат нулевой, скорее всего пытаетесь изучать что-либо не имея представления о базисных вещах.

У Zabbix есть API пользуйтесь им, если почему-то хочется самому строить график по данным.
Либо забирайте картинки и выводите на сайте их, для этого достаточно в url поменять charts.php на chart2.php и он вернет картинку.

regexp_substr

ООП - это больше про объекты и их связи. Да, в какой-то степени боремся и с повторяемостью кода, но это не главное. Т.е. нужно смотреть на то, что это за объекты, если они родственные, то можно сделать абстрактный класс, но быть может больше подойдет инстанцирование в один класс разных объектов и вызов одноименной функции. А где-то вообще будет вызов динамический, а где-то быть может стоит и продублировать код. Все зависит от самих объектов и их связей.

Это называется динамическое свойство, в php 8.2 признано устаревшим. Делать так не рекомендуется по очевидным причинам: мы описываем объекты классами для упорядочивания работы, чтобы точно знать, что и где лежит, когда в объекте свалено невесть что, работать с этим будет проблематично. И, к слову, напрямую в свойства тоже не рекомендуется писать.

Если делать самому, а не через облако в интернете, то самый простой способ - virtualIP для сервера приложений и standby сервер для СУБД.

Можно и float использовать, если вас не напрягает, когда вы добавляете 1 сатоши, а добавится 2. Прочитайте про числа с плавающей точкой.
Как вариант использовать обычный int, decimal выглядит круто в базе, но в php вам придется использовать int и смысл decimal теряется.

1) Цель использования DTO - это передать данные между двумя подсистемами. Причем, либо между ними нельзя передать поведение, либо мы хотим, чтобы они были независимы, а передача поведения увеличит зацепление.
2) DTO - это специфика Java, там, объединить разнородные данные можно только в объекте. Поэтому был введен данный механизм - объект с искусственным ограничением, только данные и никакого поведения. Но, php не Java, здесь разнородные данные можно легко объединить в обычном массиве. Вы можете, конечно, массив завернуть в объект, но смысла в этом нет, т.к. мы передаем данные между независимыми подсистемами, ни одна из них не должна быть зацеплена на объекты другой.
3) Как уже написали, сам DTO и механизм его формирующий - это разные вещи, подсистемы могут вообще на разных языках быть написаны, и все будет прекрасно работать, т.к. мы передаем только данные, а не поведение. Если же хочется туда запихнуть валидацию или иное поведение, стоит задуматься, а зачем здесь DTO? Не проще ли тогда сразу передавать полноценный объект.

empty($var) - это "синтаксический сахар", т.е. это краткая запись следующей конструкции:
!isset($var) || $var == false
т.е. кроме того же самого isset, там еще и сравнение с false, причем с преобразованием типов