Daria Motorina

Почему-то все поголовно новички задают не тот вопрос, который им нужно решить.
Вопрос же не в том "Как подключиться", а "почему у меня не работает?". А это совсем другой вопрос.

Но раз уж спрошено, то правильно подключаться вот так:

$host = 'booktst.beget.tech';
$db   = '';
$user = '';
$pass = '';
$charset = 'utf8mb4';

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
try {
    $mysqli = mysqli_connect($host, $user, $pass, $db);
    mysqli_set_charset($mysqli, $charset);
} catch (\mysqli_sql_exception $e) {
     throw new \mysqli_sql_exception($e->getMessage(), $e->getCode());
}
unset($host, $db, $user, $pass, $charset); // we don't need them anymore

Такой вариант подключения снимет сразу целую кучу проблем:

• пропадут все проблемы связанные с кодировками (сохранятся вопросы вместо русских букв, не работает json_encode()...)
  
• пропадут бесполезные сообщения об ошибках как mysqli_fetch_assoc() expects parameter..., место них будет выдаваться нормальное объяснение прочему запрос упал
  
• сайт не будет позориться светя ошибками на весь интернет если упала база данных
  

Нашел в чем проблема. NameSpace должно быть без точек...

Тут данные о праздничных днях: basicdata.ru/api/calend

Остальное - банальное программирование.

На Тостере принято выбирать наиболее конкретный тег. Тег "web-разработка" имеет смысл ставить только если вопрос относится к общим принципам web-разработки и невозможно сузить его до чего-то более конкретного.

в любой операционной системе для этого есть как минимум один планировщик заданий.

Какой смысл от продумывания деплоя на шеред хостинг? Как бы вы это не реализовывали, у вас в любом случае с шередом будет большой простой при каждом "деплое" и в один прекрасный момент вы успешно все сломаете на несколько часов

Мейтененс нужен для того, что бы юзеры во время деплоя видели какое-то информационное окно. Впрочем, с таким "деплоем" как у вас, это не вариант.

Пришлите нам команду которой пользуетесь.
Возможно, вы не указывали username?

function compare($a, $b) use($sort_type) {...

А теперь правильный ответ.

PDO - не единственная библиотека в составе РНР. И не она одна выдает ошибки.
Поэтому искать решение, специфическое для PDO просто глупо. Ошибка при отправке емейла откроет данные для соединения с почтовым сервером - и т.д.

Отключать показ ошибок надо для всего РНР целиком.

И делается это очень просто. Добавляешь всего одну строчку в начало файла:

ini_set('display_errors', 0);

и всё - ни одна ошибка не появляется на экране! Причем это будут любые ошибки, а не одна конкретная.

Но тебе всё равно нужно знать, в чем проблема. Чтобы её исправить. Поэтому сам текст ошибки надо писать в лог на сервере. Это тоже делается одной командой:

ini_set('log_errors', 1);

Всего две команды, и больше ничего менять в коде не надо.
Они скроют текст ошибки от пользователя. но сохранят для того чтобы ты мог понять, в чем проблема.

Итак,

какие конкретно стоит почитать

1. Макконнелл, "Совершенный код". Объемная но не особо сложная книжка, можно прочитать не особо то за большее время чем такую-же книжку из художественной лит-ры.
2. Роберт Мартин, Идеальный программист. Есть ещё "Программист прагматик", вроде тоже о чем то подобном. Книжка небольшая, в принципе можно за пару тройку недель прочитать рассуждения Дяди Боба о работе программиста.
3 Роберт Мартин, Чистый Код. Весьма хорошая книжка, очень широко затрагивает тему написания поддерживаемого кода. Важно - особенно в этой книге, но так же и в любой другой - не зацикливайтесь на догмах аля "3 строчки на функцию", не обожествляйте SOLID, а рассматривайте, какие проблемы решают предложенные решения. Советую в каждом случае рассуждать о том, как описываемые вещи влияют на качество кода и архитектуры программы.
4. Роберт Мартин, Чистая Архитектура - относительно новая книжка о том, что всё новое это хорошо забытое старое. Возможно вещи описываются немножко поверхностно, впрочем, углубляться в любом случае нужно самому. Книжка годная, получше объясняет SOLID, затрагивает другие принципы, затрагивает парадигмы, принципы дизайна, архитектуру, объясняет почему то, что многие горе-разработчики нынче зовут ООП им не является. Думаю эту книжку можно даже перенести на первое место.
Дальше уж по ситуации - паттерны GoF, PoEAA, Рефакторинг Фаулера, Кента Бека про тестирование etc.

подсознательно я продолжаю выбирать именно "правильные" подходы,

Боюсь, что вы просто используете те подходы что знаете, а не выбираете исходя из требований и ситуации.
Хотя бы потому что "правильных" подходов не бывает, есть подходящие в данной ситуации, и плохо подходящие, компромиссные и откровенно вредные.

наследование — это реализовывается само собой.

Вот эта фраза явно даёт понять что у вас есть проблемы в дизайне. Наследование это весьма опасная штука, и делать его просто потому что показалось удобным, не задумываясь об LSP, контрактах и инвариантах.. Кхм.. Плохо.

Упомяну один момент: статейки в интернете и даже(о боги) на всеми нами любимом хабре или тостере, как и любые другие источники информации, книги и доклады любимых нами авторов представляют исключительно субъективное мнение автора, и лишь его понимание описываемой темы, сформировавшееся в силу, обычно, неизвестных нам обстоятельств. Они могут нести за собой скрытую сложность, абсолютно не подходить в ситуациях отличных от ситуации автора, и никогда не стоит принимать из за единственно-верную истину. Скорее, за пищу для размышлений и альтернативные подходы к какому-либо делу.