Danny Arty

никак, т.к. это так и должно быть

но непонятна причина извращенств с direction: rtl, если того же можно добиться менее извращёнными способами с тем самым text-align и justify-items/justify-content

На сайте используется TLS Fingerprint (вероятно, JA3) как один из индикаторов сессии в системе перед веб-сервером, вероятно, это анти-DDoS.
Так как браузер и curl используют разные SSL-библиотеки и передают разные наборы шифров, сервер предлагает вам пройти challenge.

Как только люди не извращаются, лишь бы SQL не изучать. А ведь достаточно сделать уникальный ключ по `word` и использовать запрос INSERT IGNORE.
Перед подключением к базе разрешить выброс исключений, вместо ручной проверки ошибок:

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

В начале скрипта включить отображение ошибок PHP:

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

Ну и использовать подготовленные выражения. Готовить один раз перед циклом, а в цикле только вызывать с разными значениями параметров.

Сделайте плюс не шрифтом, а блоком из горизонтальной и вертикальной линий, потому что у шрифтов полно свойств:

Чему к примеру равна горизонтальная линия вашего шрифтового плюса при размере 35px? Если у вас размер блока 45px, то линия должна быть так же с нечетным размером ровно 1px или 3px, или 5px в любом другом случае (1.2px, 3.6px, 4px) браузер начнет смещать ваш плюс вверх и вниз, что вы и наблюдаете.

Если же блок будет с четным значением, например 44px, тогда, чтобы плюс стал по центру у него должен быть размер 2px,4px и т.д..

Шрифты для такой задачи не подходят, тем более с изменением шрифта изменится и его центр.

select count(*) from product

Это называется не "вывести товары одним числом", а "получить количество строк в таблице". И по корректной формулировке ответ в поисковике находится за два клика. Как говорится - в правильно сформулированном вопросе уже заложена половина ответа. А программирование - дело точное, и формулировки в нём тоже должны быть точные.

Пока на ум приходит получить все категории, потом в цикле пройтись по ним и...

Естественно это не делается так. Такие задачи решаются на стороне бд через джоин таблиц. Не считая ошибки синтаксиса и отсутствия лимита, запрос в ответе Vindicar подойдет. Схема хранения не самая лучшая, так как по сути у вас получается один-ко-многим (одна категория ко многим постам), и если категорий на 1 пост будет больше 1, вся структура идет в мусор. Более качественным решением все же будет многие-ко-многим между постами и категориями.

Ох...

Model View Controller. Да ну его, ему уже 45 лет (придумали в 79-ом году). Давайте лучше про Model View Adapter погокорим. это то что все используют в популярных фреймворках последние лет так 10 так точно.



Вообще в этом всем важно не только то, что каждая буква обозначает, а как они друг с дружкой связаны.

View - это не только HTML, но и вообще представление в целом, а так же логика его формирования. Шаблонизаторы, фильтры, различные функции/объекты помогаютщие нам сформировать view (например форматирование дат, сериализаторы и т.д.) В подавляющем большинстве случаев "представление" наших данных - это HTTP запросы и HTTP ответы. HTML - э то лишь часть HTTP ответа.

Model - Это целый слой, который может быть представлен в виде кучи отдельных объектиков, структур и т.д. Его задача - делать дела и хранить/менять состояние системы. Тут легко запутаться потому что термин "модель" много чего значит. Воспринимайте его как "слой логики" а не конкретные объекты. И да - база данных и прочая чушь - это детали реализации этого слоя. "не важные штуки" словом. Туда же и ActiveRecord, ORM-ки всякие. Это деталь реализации и все остальные чуваки (view и controller) о них знать ничего не должны (хотя иногда могут в целях упрощения).

Controller или адаптер. Это опять же не обязательно один объект. это может быть цепочка адаптеров (еще называют фронт-контроллером, middlewares и т.д.). Его задача весьма простая. Получаем представление данных на входе (HTTP запрос), определяем что надо делать, и просим модель что-то сделать (ни в коем случае не меняем ничего самостоятельно в контроллере, он только просит). Потом мы можем попросить модель вернуть нужный нам кусок состояния, и попросить View сформировать представление (HTTP ответ).

Как-то так. В целом же это я сейчас описал "идеальный мир". Вся суть этого подхода - разделение логики презентационной и логики приложения. Зачем это надо? что бы было проще жить! Обычно UI приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

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

$dt = new DateTime;
$formatter = new IntlDateFormatter(
    'ru_RU',
    IntlDateFormatter::LONG,
    IntlDateFormatter::LONG
);
$formatter->setPattern('d MMMM yyyy');
echo $formatter->format($dt);
// 18 января 2023

Запись пакетом быстрее и менее нагрузочна, но выше вероятность потери при сбоях.

PS. 40 записей в секунду - это в общем-то ни о чём..

Выносите даты в отдельную таблицу:
Название таблицы: location_event_dates
id - идентификатор даты;
location_event_id - идентификатор из таблицы location_event (то, что у вас в вопросе)
event_date - одна из дат события (в формате даты, а не строки!)
Тогда будет нормальный поиск:

select le.id, le.locationid, le.eventid,
          led.event_date
from location_event le
join location_event_dates led on led.location_event_id = le.id
where led.event_date between :begin_date and :end_date

Хорошо бы в какой-то переменной держать состояние, которое бывает одно из двух: true / false

let isExpanded = false; // единственный источник правды

el.addEventListener('click', () => {
  isExpanded = !isExpanded; // переключить

  // показать
  linkusersnew.innerText = isExpanded ? 'Свернуть' : 'Развернуть';
  userwrap.style.height = isExpanded ? '600px' : '400px';
  newdel.style.display = isExpanded ? 'flex' : 'none';
});