Ипатьев

Изучите внимательно документацию по LOAD DATA.

Во-первых, необходимо правильно указывать опции парсинга - разделитель, терминатор, квотирование и пр.

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

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

id у меня auto-increment, пробовала и NULL, и 0, и просто цифрами заполнять - ни в какую.

Пункт "во-вторых" в полный рост.

Ну и любопытно, где именно Вы пробовали и NULL, и 0, и просто цифрами заполнять - в показанном Вами запросе под это просто нет места.

Перефразируя ваш вопрос - как получить несколько строк с одним и тем же пользователем, если в запросе стоит, что для каждого пользователя должна быть только одна строка (GROUP BY users.id).
Ответ - никак.

0) Проверить лог ошибок или добавить в код выше

ini_set('error_reporting',E_ALL);
ini_set('display_errors', 1);

и убедиться что ошибок выполнения нет. Естественно, подключение должно быть настроено на вывод ошибок. Так же убрать бессмысленный биндинг $stmt->execute(['id'=>id]);, где внутри даже не переменная, а какая-то фигня...
1) Проверить запрос в консоли или в phpmyadmin
2) В случае если запрос ничего не выдает - удалить строки INNER JOIN category ON category.id=post.cat_id, выполнить запрос
3) Если выдает что-либо, значит таблица с категориями пострадала, проверить выведенные посты на номер категории, и посмотреть что стало с этими записями в таблице category.
4) Если не выводит - повторить пункт 3 со строкой INNER JOIN users ON post.user_id = users.id, со всеми вытекающими.

mysql !== mysgl

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

<?php
require "includes/config.php";
$articlesx = mysqli_query($connection, "SELECT * FROM `matem` ORDER BY `views` DESC LIMIT 8");
while($artx = mysqli_fetch_assoc($articlesx)) {
    echo '<li><a href="#">'.$artx.'</a></li>';
}

Кроме этого $artx - МАССИВ! Значит:

echo '<li><a href="#">'.$artx['тут какой-то ключ'].'</a></li>';

Я уверен, что необходимо запретить удаление любых вопросов. Необходимо закрывать неподобающие вопросы с баннером причины или ссылкой на дубликат.

p.s.
Каждый день на тостере появляются десятки совершенно глупых тем, причём эти темы повторяются из года в год. Очевидно, что 100500 раз модератор просто удалит тему без объяснения причин. Быть может, если такие темы просто будут закрыты и помечены тегом очень тупой вопрос, то некоторые новые участники форума смогут осилить поиск и не будут каждый день создавать подобные темы.

https://habr.com/berserk-mode-nope

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

ООП очень тяжело заходит потому что совершенно непонятно для чего оно нужно.

Ровно для того же, для чего нужно программирования без ООП. ООП - просто достаточно простая и удобная абстракция для программирования.

Я так понял, что бы в этом всём разобраться нужно писать свою CMS на ООП.

Нет. Достаточно просто решить любую задачу с использованием ООП и без и сравнить для себя. Без ООП, т.е., функциональное программирование - у тебя куча файлов с кучей функций, каждый раз, когда нужно произвести какие-то вычисления над какими-то данными надо импортировать нужную функцию и использовать её для обработки данных. Когда у тебя десять строк кода и три функции - это достаточно просто. А если у тебя тысяча функций и несколько сотен видов данных для обработки, да еще и кучей разных форматов? А десять тысяч? Делать огромную документацию, в которой описывать какая функция с какими видами данных может работать и каждый раз её пересматривать в процессе написания или чтения кода? А вот ООП, говоря простым языком, позволяет группировать функции в отдельные группы, т.е. классы, которые могут работать с определенными типам данных и связывать сами эти группы функций с определенными типами данных, а так же связывать классы друг с другом (иерархия, наследование и прочее). Т.о., это упрощает работу с данными и их обработкой: просто создаем новый экземпляр класса и получаем удобный интерфейс для дальнейшей обработки каких-либо данных, путем использования методов этого класса для обработки данных, хранящихся в полях данного экземпляра или передаваемых в качестве параметров методов и сохраняемых в полях позднее.

Вопрос глупый. RTFM: https://www.php.net/manual/en/function.isset.php

У вас строка ‘SET collation_connection = utf8_unicode_ci’ в неправильных кавычках.
Когда из интернета копипастите, проверяйте.

Убрать static? И создать экземпляр класса start?
Добавить статичное поле с Logger?
Создать экземпляр логгера на 1 раз?
Не понятно, какой результат в итоге хочется достичь.