Дмитрий

Согласен с 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, а в коде в этот аргумент передаётся выражение что недопустимо.

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

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

стоит посоветовать установить консольный файл менеджер midnight commander
sudo apt install mc
в комплекте будет текстовый редактор mcedit

Фронт это всё, что видит пользователь. В том числе и вёрстка. В принципе не очень ясно, как можно адекватно заниматься фронтом, если не понимаешь, а с чем вообще имеешь дело. Куда вставляются данные, как они будут отображаться и так далее.

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

Как еще один вариант.

$arr = [1, 1, 2, 4, 3, 1, 1, 0, 1, 5, 8, 9, 1, 1, 2];
$direction = null;
$last = null;
$countMonotony = array_reduce(
    $arr,
    function ($total, $item) use (&$direction, &$last) {
        if (is_numeric($last)) {
            if ($item > $last && $direction != 'up') {
                $total++;
                $direction = 'up';
            } elseif ($item < $last && $direction != 'down') {
                $total++;
                $direction = 'down';
            } elseif ($item == $last) {
                $direction = null;
            }
        }

        $last = $item;

        return $total;
    }
);

var_dump($countMonotony); // int(6)

Садись, будем с тобой учиться программированию.

То что у тебя здесь написано - это не программирование.
Написать в столбик несколько операторов можно и обезьяну научить.

Программирование начинается тогда, когда твой код престаёт работать.
Процесс выявления участка, который не работает, и что надо исправить, называется отладкой. И это и есть на самом деле программирование.
Для отладки нужно две вещи:
1. В принципе понимать, что делает твой код. причём не в целом, а каждый оператор в отдельности. Какие данные он должен получать на вход, что с ними делать, что должно быть на выходе.
2. Трассировка. Которая заключается тупо в выводе промежуточных результатов.

поэтому после кода добавляем строчку

var_dump($_SERVER['QUERY_STRING'], $addGet,$config['http_home_url'],$_SERVER['REDIRECT_SCRIPT_URL']);

и смотрим, где чего не хватает.

И только после этого идём на тостер задавать конкретный вопрос, "а почему у меня такая-то переменная пустая"

интернет - магазин. Там много чего интересного есть:
каталог (фильтры, пагинация, скидки, оптимизация запросов), страница товара, чекаут, лк пользователя, авторизация, регистрация, просмотр заказов, загрузка/выгрузка товаров, кабинет менеджера, статистика продаж, оптимизация нагрузки, разбиение заказа на склады и можно еще много чего интересного придумать

https://www.php.net/manual/ru/language.oop5.late-s...

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

Как всегда - вопрос 100% "ниачем"...
Во первых - зачем? Явно вы пытаетесь решить какую-то типичную задачу чисто вашими "воображаемо-оптимальными" способами, вместо того чтобы четко сформулировать реальную задачу.
Во вторых - именно озвученный функционал на php делать глупо. Это не его задача и специфика. Обычно это решают средствами ОС.
В третьих - никак, можно конечно запустить рекурсивно функцию с проверкой наличия файла в папке, но по сути это будет тот же вечный цикл с выходом по условию, только описанный в функциональном стиле.

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

1. выкинуть все локейшены с ошибками. это дикость, ни один нормальный сайт так не делает. ошибки надо показывать либо сразу, либо через сессию. локейшены с ошибками встречаются только у дебилов, которые делают видео на ютубе для других дебилов. не надо так палиться сразу.
2. выкинуть домен из ссылок. ты серьёзно собираешься переписывать все ссылки, когда у тебя сайт с временного домена переедет на постоянный? а потом обратно - когда надо будет потестить локально? header('Location: /AUTH-2/Sign_In/'); достаточно для единственного локейшена, который нужен в этом коде
3. убрать всю эту лестницу иф-ов, делать все проверки на одном уровне. ошибки собирать в массив. перед вставкой в БД проверить массив на пустоту.
4. if ($row->Email != $email) - масло масляное. ты УЖЕ проверил емейл в базе, зачем еще раз проверять?
5. else if($row->Email == $email) { - это уже какой-то совсем адок. Ты УЖЕ проверил, что емейл не совпадает. причем два раза. В else мы попадём, если емейлы совпдают. Ещё раз проверять не надо. Два алкоголика садятся на трамвай, один спрашивает водителя - я этом номере до вокзала доеду? Водитель - нет. Второй алкаш - а я?
6. внизу у тебя ссылка на password_verify, но хэшируешь ты все равно кривым алгоритмом. Не осилил?
7. все эти куличики в песочнице с $client_Code $server_Code - это какой-то адок с точки зрения безопасности. Любой школьник, который не тупее дауна, поломает все твои "сессии" за 5 минут.
8. setcookie("PHPSESSID", $_COOKIE['PHPSESSID'], 0, '/', '.tsecret.net'); - опять совершенно бессмысленная строчка. К чему она? Зачем? Что ты хотел тут сказать? И кому?
9. Разбей это простыню хотя бы на функции. Никакой солид у тебя конечно не получится, как и у Георгий Котов который сам не понимает что это значит. Но хотя бы разделить проверки, запись в бд, и отправку емейла можно.

В целом - из плюсов только нормальная работа с БД, в остальном на троечку, и местами - кол (за дыры в безопасности и отсутствие логики)

Для популярных фреймворков обычно есть демо приложение, нп. Symfony demo app. У Laravel был курс "как был создан Laracasts", т.е. есть живой проект Laracasts и скринкаст по его созданию в целях обучения. В целом на гитхабе есть море готовых приложений разного качества и сложности, главное погуглить основательно)

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