ThunderCat

При соединении с БД надо указывать кодировку.
Поскольку на сайте используется юникод, то соответственно указывать надо utf8mb4

А сессии тут вообще не при чем.

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

Основных правил при обработке исключений три:
1. Не использовать исключения там, где они не нужны. Например, при проверке пользовательских данных.
Собственно, эмпирическое правило звучит так: функция должна бросать исключение, если она не может выполнить ту работу, для которой она предназначена.

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

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

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

Пример такого исключения - когда запрос в БД порождает ошибку.

3. Пользовательские исключения, там где они нужны, обычно обрабатываются по месту, но есть нюансы.
Собственно, под обработкой исключений часто понимают два разных действия:
- собственно обработку, когда программа совершает какие-то действия, чтобы нивелировать негативный эффект. Например, если не удалось подключение к какому-то сервису, то либо попробовать подключиться к другому, либо просто подождать и попробовать снова.
- простое информирование пользователя

Для информирования можно действительно ловить исключение через try..catch и писать какое-то свое сообщение.
Но можно и автоматизировать этот процесс, вот две статьи, которые показывают примеры, как это можно сделать:
https://angelovdejan.me/2022/11/24/centralized-exc...
https://habr.com/ru/articles/688202/

ну элементарно вроде:
Клик по кнопке -> Запрос данных -> Вставка данных в модалку -> Отображение модалки.

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

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

С объектами не большая путаница происходит, но только из-за того что многие не думают/забывают что хранится в переменной когда создаётся объект. При создании объекта в саму переменную помещается его идентификатор, по которому php и обращается к этому объекту.
Ну и соответственно при передаче такой переменной в функцию, мы копируем этот идентификатор в новую переменную. Переменная уже другая, независимая от той что была, но идентификатор объекта тот же. Поэтому манипуляции с объектом в функции(обращение к свойствам/методам) отразятся на объекте с этим идентификатором. И со стороны выглядит словно переменная с объектом всегда передаётся по ссылке(словно стоит амперсанд), но это не так. Например внутри функции вы перезапишете переменную(к примеру присвоите null) то оригинальная переменная с объектом не поменяется.

А вот есть если передать её по ссылке, те с амперсандом, то внутри функции будет переменная со ссылкой на переменную вне, и поэтому не только манипуляции с объектом, но и перетирание переменной в целом повлияет.

class A {
    public $foo = 1;
}

//создали переменную
//в ней хранится id объекта, сам объект где-то в памяти оптимизированно лежит
$newObj = new A;

//Вывод 1
echo $newObj->foo;

function foo($obj) {
	//в obj скопирован id объекта
	//тк он тот же, то меняется и оригинальный объект
	$obj->foo = 2;
	//локальная переменная перетёрся, больше id объекта не хранит
	//на внешнюю не повлияло
	$obj = null;
	
}

foo($newObj);
// получили 2
echo $newObj->foo;


function bar(&$obj) {
	//obj ссылается на тоже место в памяти, что и внешняя переменная с id объета
	//тк он тот же, то меняется и оригинальный объект (тут логично, тк по ссылке)
	$obj->foo = 2;
	//локальная переменная перетёрся, больше id объекта не хранит
	//внешняя тоже перетрётся
	$obj = null;
}


bar($newObj);
//ошибка предупреждение, нельзя читать свойства на null
echo $newObj->foo;

Ну и зная всё это, вы можете написать свою простую функцию, по типа прегматча.

function mySum($a, $b, &$result) {
	$result = $a + $b;
}
//первые два параметра по значению, в третий передаём переменную
//она тут же инициализируется (как если бы её до этого написать просто $res;)
// и передаётся её ссылка внутрь функции
mySum(1,2, $res);

//3
echo $res;

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

Но понятие кэша гораздо шире. Кэшироваться может и специфичная для конкретного пользователя или запроса информация. В этом случае никаких .php файлов не напасешься.

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

Еще одна причина, не главная, но все равно важная - масштабирование. Один сервис редиса можно использовать с несколькими инстансами РНР. Плюс сам редис можно масштабировать на несколько физических инстансов.

И так и так.
Чаще всего используется традиционный рендеринг на бэке, но если кто хочет помоднявее, или чтобы не тратиться на отдельные версии для мобильного приложения, то делают рендеринг на фронте.

Как пользователь, я ненавижу рендеринг на фронте, на практике он ВСЕГДА тормозит.
За примером далеко ходить не надо, это новый дизайн Хабра.

Вы, кстати, неправильно понимаете термин "прод".
Продакшен окружение относится не к коду, а к тому, где он выполняется
В локальном окружении разработчик пишет и отлаживает программу
Тестовое (стейдж) окружение полностью имитирует боевой сервер, но доступно только разрабочикам/тестировщикам/заказчикам
И, наконец, продакшен - собственно рабочий сервер, который находится под реальной нагрузкой
А код везде один и тот же.

Конечно IP-адрес удалённого сервера, с которого создалось соединение. Посетитель удалённого сервера к такому соединению имеет отношение только в том, что соединение создаётся для получения данных для этого посетителя.

Этот вопрос не имеет отношения к РНР.
А только к базовым навыкам работы с операционной системой.
В простейшем случае можно написать бат файл, в котором под своей командой пишете любую другую, от проигрывания звукового файла до запуска любой программы. Которая выполнится по завершении первой
Можно то же самое написать в одну строчку php my.php & echo ^G
После амперсанда опять же, пишется все что угодно.

писать set_time_limit(0) в консольоных скриптах кстати не нужно. Там лимита нет по умолчанию

Боюсь, что никак не очистить. Тут свой браузер порой чуть ли не ногами бить приходится, чтобы забыл об уже неактуальном редиректе.
Попробуйте использовать не 301 (постоянный), а 302 (временный) редирект — он не должен вообще кэшироваться. В теории.

SELECT good,                      -- выбрать идентификатор товара
       amount * unit_price AS `sum` -- и потраченную на него сумму
FROM Payments 
ORDER BY `sum` DESC;                -- отсортировать по убыванию суммы

Поменять id.

If the id value is not the empty string, it must be unique in a document.

https://developer.mozilla.org/en-US/docs/Web/API/E...

1. Вы показали невалидный JSON
2. Правильный путь $.Statuses[*].id
3. JSON_SEARCH ищет только строки, а у вас число
4. Раз вам надо искать в JSON, значит вы что-то делаете неправильно.