Ипатьев

Данная ошибка может возникать в двух случаях:
- если вы обращаетесь к этому скрипту напрямую, а не как к обработчику формы
- если в форме были ошибки, и она тупо не передаёт поля login и pass методом POST.

Чтобы исправить первый вариант, и вообще для порядка, надо добавить проверку на метод POST.
Чтобы получить помощь для второго варианта, надо догадаться добавить в свой вопрос код формы.

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

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

Лучше потратьтесь на книжку, Джон Дакетт, PHP&MySQL. Там очень толково, на примерах даётся не только язык, но и все важные аспекты программирования - обработка ошибок, отладка, рефакторинг, структура приложения, SQL, обработка изображений, и куча всего остального. В последних главах весь материал даётся на примере создания простой но рабочей социальной сети.

Почему не работает Cron?

Наверное, вместо бессмысленного /dev/null надо указать путь к файлу, в котором появится ответ на этот вопрос?

Нет, неверно.

character-set-server и collation-server вообще ни на что не влияют. А только задают умолчания, если при создании БД и таблиц ленивый программист не указал кодировку. Поэтому трогать их нет смысла вообще.

Добавлять utf8mb4 в соединение также бессмысленно, если сами данные в utf8. Расширенные символы она всё равно сохранить не сможет.
И наоборот - если таблицы в utf8mb4, то указывать её при соединении надо в обязательном порядке. Не потому что вдруг "конвертация на лету" а потому что если соединение будет utf8, то расширенные символы клиент не получит.

(В теории, всё может работать нормально и без установки utf8mb4 для соединения, поскольку она в пыхе в какой-то момент начала использоваться по умолчанию, но лучше всё-таки задавать явно)

1. Гуглим simplexml_load_string ошибки
2. Открываем страницу https://www.php.net/manual/ru/simplexml.examples-e...
3. Берём с неё код и немного модицифируем

libxml_use_internal_errors(true);

$sXML = download_page($url);
$xml = simplexml_load_string($sXML);

if ($xml === false) {
    throw new RuntimeException(
        "XML parsing errors: ". implode("", array_column(libxml_get_errors(), 'message'))
    );
}

Смотрим ошибки, исправляем.

Выносить имя таблицы и колонки в переменные не нужно. Их надо написать прямо в запросе.
А дату надо подставлять в запрос через подготовленные выражения.

Если в БД хранится только дата, то чтобы получить все строки за определённую дату, код будет такой.

$sql = "SELECT * FROM название таблицы WHERE  DATE = ?";
$result = $conn->execute_query($sql, [$dateNew]);
$usersArray = $result->fetch_all(MYSQLI_ASSOC);

Если же хранится дата и время, то надо подставить начальный и конечный период. То есть запрос будет

SELECT * FROM название таблицы WHERE  DATE BETWEEN ? AND ?

и в него подставлять значения "$dateNew 00:00:00" и "$dateNew 23:23:59"

Чтобы получить одну запись, надо добавить в запрос оператор LIMIT 1, а fetch_all(MYSQLI_ASSOC) поменять на fetch_assoc()
Чтобы получить "последнюю" запись, надо добавить в запрос сортировку по тому полю, по которому считается последовательность добавления. И сделать сортировку в обратном порядке

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

Если говорить про "запросы к БД", то для таких тестов "массив с данными" использовать просто глупо. Это получится какой-то формальный тест: "проверяем, что метод возвращает массив из трех строк - и тут же возвращаем этот самый массив". В чем смысл? Если вы тестируете запрос к БД, то и надо тестировать запрос к БД. По-другому никак.

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

И сюда же использование для тестов БД другой системы. Например основная БД MySQL, а для тестов используется Sqlite. Тут сразу можно сказать, что это профанация. Различие даже в какой-то одной настройке БД может повлиять на результаты запроса (и теста как следствие) - а тут и вовсе используется совсем другая БД.

С другой стороны, работу с БД скорее стоит тестировать не в юнит тестах, а скажем в интеграционных. Но не будем углубляться.

Массив же "с данными, симулирующими ответ из базы данных" используется на следующему уровне, там где требуется "ответ из базы данных". Взьмём метод, который использует данные, полученные из БД. Например авторизация юзера. Этот метод должен не сам лезть в базу, а дёргать отдельный метод, вполне возможно, что совсем другого класса. И вот чтобы протестировать авторизацию, вы и мокаете метод для работы с БД, и из этого мока возвращаете тот самый массив без всякого обращения к бд.

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

Так что разбивайте ваши длинные методы на мелкие, и тогда вопрос, как их тестировать, в большинстве случаев отпадёт сам собой.