FanatPHP

Это пространство системы, симфони тут ни при чем)
82 это айди юзера www-data в alpine.

Согласен с FanatPHP по поводу того что изменения, по сравнению с предыдущим вариантом, просто колоссальные, поздравляю!

Однако сразу видны те направления движения которые стоит рассматривать в первую очередь:

1. Вам стоит лучше изучить возможности языка. PHP развивается очень динамично и в 7-й версии было добавлено огромное количество вкусных возможностей, про них стоит знать и ими стоит пользоваться
   
2. Необходимо лучше изучить имеющуюся на данный момент экосистему готовых пакетов, это позволит вам использовать готовые, проверенные решения вместо изобретения своих велосипедов. Подключение Twig - первый шаг, но далеко не последний
   
3. Вам обязательно стоит посвятить время изучению кода популярных проектов. Это многое может рассказать вам о подходах к решениям, паттернах и т.п. Конечно, параллельно нужно будет выяснять значения массы используемых терминов чтобы лучше понимать происходящее, это тоже пойдёт вам на пользу.
   
4. Смотрите как развиваются другие технологии, которые вы используете, таблицами сейчас не верстают :)
   
5. Рекомендую рассмотреть вариант использования для написания кода нормальной IDE, к примеру PHPStorm, это существенно улучшит вашу производительность и убережёт от массы ошибок
   

Теперь более предметно:

Оформление кода:

Вы утверждаете что код соответствует PSR-2 (кстати, актуальный - PSR-12), однако есть мелкие огрехи (раздел 2.2).

Оформление composer.json:

Лучше указывать требования к платформе, в вашем случае - как минимум версию PHP т.к. platform requirements проверяются Composer'ом при установке.

Поскольку ваш проект - не библиотека, то composer.lock тоже должен быть частью репозитория.

Про настройки autoload'а вам уже сказали, обращу только внимание на то что сейчас структура репозитория отражает PSR-0, а не актуальный PSR-4, при использовании PSR-4 ваш код проекта лежал бы в src.

Организация репозитория

Код проекта должен лежать за пределами web root, поэтому вам явно не хватает папки public с единственным index.php

Конфигурация

Конфигурирование через константы - весьма устаревший подход. К примеру представьте что вы разворачиваете этот код на production сервере и вам нужно сменить данные для подключения к базе данных не создавая локальных изменений в рабочей копии. Сейчас у вас это не получится. Выход: читаем про
12 factor app и, в частности, раздел config, а затем подключаем в проект, к примеру, vlucas/phpdotenv или symfony/dotenv

Сервисы

Использование bootstrap.php - хорошо, но для организации работы с сервисами сейчас как правило используются dependency injection контейнеры, даже PSR-11 для них есть. В текущем виде ваш подход слабо расширяем, а передача сервисов через глобальные переменные - так себе идея по многим причинам.

Понятно что вворачивать DI container для примера на три файлика - overkill, но с самим подходом вам следует ознакомиться. Из реализаций самая популярная сейчас - symfony/dependency-injection, но есть и альтернативы.

Автолоадер

Про autoload.php вам уже сказали, вместо него стоит корректно конфигурировать автозагрузку в composer.json и полагаться на то что Composer вам сгенерирует. Он ведь умеет всё это и оптимизировать при необходимости.

Внешние пакеты

Для новых проектов рекомендуется выбирать актуальные и поддерживаемые версии пакетов. Хотя Twig 1.x ещё поддерживается, тем не менее актуальная версия - 3.x.

Обработка ошибок

Попробовать сделать это самостоятельно, безусловно, полезно чтобы лучше разобраться как это работает, но для реальной работы лучше полагаться на проверенные решения, к примеру filp/whoops или symfony/error-handler

Типы данных

Важно помнить что PHP с версии 7.0 поддерживает указание скалярных типов для аргументов и
возвращаемых значений, с 7.1 - nullable типы и class constant visibility, а с 7.4 - типизированные свойства. Всё это гораздо надёжнее чем описание типов через аннотации и этим стоит пользоваться.

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

Data Objects

Сейчас Place и PlaceFilter по сути являются data объектами т.е. они не содержат самостоятельной логики, а просто переносят некие данные. При этом оба этих класса имеют пустые конструкторы (которые, кстати, лучше убирать), а загрузка данных организована через setter методы. Это позволяет изменить данные в них в произвольные моменты времени что вряд ли является желаемым поведением. Вместо этого подобные объекты лучше организовывать в виде immutable объектов (статья с примерами) чтобы не позволять ненужного нарушения целостности данных. Альтернативно, к примеру, для PlaceFilter может лучше подходить использование паттерна
Builder, хотя в википедии не самый лучший пример.

Именование

Все мы, надеюсь, помним про две сложные проблемы, здесь как раз проявляется вторая из них. PlaceFactory ну никак не является реализацией одноимённого паттерна.

Оптимизации

Понятно что это мелочи, но явно видно что компиляцию запросов (1, 2) можно кэшировать вместо того чтобы перекомпилировать каждый раз.

References

PDOStatement::bindParam() принимает аргумент $variable как reference, а в коде в этот аргумент передаётся выражение что недопустимо.

Английский язык

Я специально почти везде по тексту давал ссылки на информацию на английском языке т.к. он - основной язык в нашей индустрии и его важно знать и использовать.

$data = '{"1st_half": 55}';
$data = json_decode($data);

var_dump($data->{'1st_half'});

Тем, что в случае использования php вам совершенно ничего не мешает подрубить шаблонизатор, например twig, и делать разбивку страницы более или менее красиво.

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

base.twig

<html>
<head></head>
<body>
  <header>...</header>
  <main>{% block main %}{% endblock %}</main>
  <footer>...</footer>
</body>
</html>

index.twig

{% extend 'base.twig' %}
{% block main %}
  Главная страница
{% endblock %}

about-us.twig

{% extend 'base.twig' %}
{% block main %}
  Интереснейший текст о компании
{% endblock %}

1. НИКОГДА не публикуйте креды к базе!
2. Не используйте подстановку данных в запрос через конкатенацию. Вместо этого используйте плейсхолдеры.
Пример 1 (SQL инъекция):

# Тут заэнкожено: '; DROP TABLE `users`; --
curl -XPOST -H 'Content-type: application/x-www-form-urlencoded' -d'phone=%27%3B%20DROP%20TABLE%20%60users%60%3B%20--'

Пример 2 (phone может содержать массив):

curl -XPOST -H 'Content-type: application/x-www-form-urlencoded' -d'phone[]=+123'

3. Не используйте глобальные переменные. Про это есть множество статтей.
4. Если есть возможность - используйте \PDO, вместо mysqli.
5. Не стоит объявлять функции/классы/трейты/интерфейсы по условию. Вместо этого используйте их по условию, но объявляйте без него.
6. При работе с путями рекомендую пользоваться глобальными, вместо относительных, иначе этот самый путь будет зависеть от скрипта, с которого запустили ваш код, а не от того, где происходит работа с файлами.
7. У вас конкурентно не безопасный код за счет того, что работа с файлами происходит в одном и том же каталоге, с одними и теми же именами файлов. Что будет если запустить два запроса одновременно на вытяжку всех пользователей? В лучшем случае один из запросов просто упадет с ошибкой что не может добавить в архив файл (это второй поток его уже удалил). Если будет запущено 2 запроса например на 1го пользователя и на всех - есть вероятность, что один из них вернет далеко не запрашиваемые данные)).
8. Очень рекомендую разделить вашу обработку на 2 части:
- Первая пусть записывает в файлики данные по пользователям при обновлении данных этих пользователей.
- Вторая - вытягивает вытягивает только id требуемых для архивирования и уже добавляет их в архив. Имя архива стоит делать рэндомным, что бы избежать конкурентного доступа к одному и тому же файлу на запись.
9. getUserses -> getUsers

Конкретно по вашей проблеме: если я праивльно понимаю, вы в один и тот же архив запихиваете файлы на каждый запрос, грубо говоря один раз вытянув всех пользователей - дальше вы только обновляете их в архиве на 10к файлов, а не создаете новый архив.

последний релиз был 2 недели назад – жуткое старье.
пользуются.

Вам это не нужно. Достаточно добавить accessor в модель.

/**
 * Полный адрес поста.
 *
 * @return string
 */
public function getFullAddressAttribute()
{
    return url("/{$this->user_id}/post/{$this->id}");
}

// Использование
$post->full_address;

Как вариант:

const toggleOrder = () => {
  const params = new URLSearchParams(window.location.search);

  params.set('order', params.get('order') === 'DESC' ? 'ASC' : 'DESC');
  window.location.search = params.toString();
};

Пример. Код.

Это будет просто написаная с нуля тема на вордпрессе, которая повторит функционал движка, т.е. тут это сложно назвать переносом, потому что от старого кода ничего не останется

Ошибка в том что return прерывает выполнение цикла так как завершает выполнение функции.
https://www.php.net/return

Вы как-то неправильно отдаете джсон...

$response = [ 'success' => $success, 'status' => $status, 'message' => $message . $addParams ];
echo json_encode($response);

Ну а слеши у вас, как уже сказали до меня - не выводятся. Всё ок