Dmitry Bay

return $this->render('index', $vars, ['dataProvider' => $dataProvider]);

метод render принимает лишь 2 параметра, а у вас их 3 откуда-то, сделайте мерж вашей переменной с провайдером в массив $vars, но лучше вообще от лишней переменной избавиться

$this->layout = 'page';

$user = User::find()->where(['username' => $_GET['username']])->one();
if ($user === null) {
     throw new NotFoundHttpException();
}

$setting = UserSettingHelper::get($user);
        
$dataProvider = (new TicketHead())->dataProviderUser();
       
Url::remember();

return $this->render('index', [
    'user' => $user,
    'setting' => $setting,
    'dataProvider' => $dataProvider
]);

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

А не получится.
Если архитектура вашего сайта на это не рассчитана.

Подробнее:

• Есть вертикальное масштабирование
  
• И горизонтальное масштабирование
  

Вертикальное - это очень просто.

Этап 1. Простой хостинг VPS/VDS.
Меняем тариф на больший - и вуаля - отмасштабировалось.
Как нетрудно догадаться это процесс не вечный. Но простой да.
Тут годится любой хостинг VPS/VDS. Они все это умеют.
Есть нюансы:
1) Иногда требуется перезагрузка, чтобы подействовали новые лимиты.
2) Чаще всего требуется перераспределить пространство на диске вручную, иначе вновь выделенное будет недоступно, но это несложно.
Рекомендую ruweb.net
Там на VPS используется виртуализация KVM

между предыдущим и последующим этапами понадобится переезд

Следующий этап, когда перестало хватать VPS.
"Железный" выделенный сервер. Т.н. хостинг типа dedicated.
Рекомендую OVH, Hetzner
Но на этом простое масштабирование заканчивается.
Понадобится на dedicated более мощное железо - придется переезжать.

В обоих случаях - VPS/dedicated - контейнеры не при чем.
Они тут параллельны.
Просто их зачастую применяют как вспомогательный элемент, в системах рассчитанных на масштабирование. Да и только.
Контейнеры для масштабирования не обязательны:
Всегда ли нужны Docker, микросервисы и реактивное ...
В этой статье помимо прочего рассказывается и о тех технологиях, что используются для масштабирования и главное зачем они используются.

Горизонтальное масштабирование:

Вот его возможности почти безграничны.
Но есть очень важный нюанс - тут вам нужно будет специальным образом написать свой сайт, чтобы он умел это делать.

Для тренировки в горизонтальном масштабировании рекомендую хостинги Heroku, Google AppEngine.

Но они потребуют чтобы ваш сайт был сделан вполне определенным образом.
Для начала читать это: Приложение 12-ти факторов
Затем что такое сервер очередей (MQ server).
И пр. и т.д. и т.п.

PDO никак не преобразовывает данные. Ни большие, ни маленькие. И предопределенная константа PARAM_STR тут тоже не при чем.

У меня сложилось впечатление, что вы изобрели велосипед.
В общем-то в вашем тексте много разумных находок и выводов.
Однако может вам имеет смысл выбрать какой-то фреймворк? Yii, Laravel, Symfony и т.п.
Вы автоматом получите и структуру, и порядок работы, и разделение и кучу всего, что упростило бы вам жизнь. М?

коллаж/collage

В качестве хранилища использовать можно любое s3, смотрите где дешевле. Например вот сравнение. А поиск по имени файла - это поиск не в хранилище, а в обычной базе данных, в которой у вас будет табличка с названиями фотографий и ссылками на сами фотографии, что-то вроде этого Images(id, name, link), где link - ссылка на изображение в хранилище

andFilterWhere вроде как работает, когда указаны данные, помогает проще работать с пустыми полями поиска, в данном случаи уже юзать andWhere

Никакой. Изучайте разработку ПО, языки программирования, построение архитектуры ПО, алгоритмы, математику и т.д и т.п.

UPD
Приведу немного аргументации и очевидных вещей для тех, кто не понимает почему ответ именно такой. На самом деле все очень просто: в IT индустрии всё развивается и меняется очень, очень-очень быстро. И как следствие возникает проблема устаревания знаний и умений. Вот например 15-20 лет назад изучение языка программирования под названием "Дельфи" и популярной тогда его среды разработки для десктопных приложений вполне имело смысл и было популярным явлением, т.к. оно тогда довольно широко использовалось, или например Perl для создания сайтов. А где оно сейчас? Почему сегодня сайты пишутся на джаваскрипте? А как на счет десктопных приложений? А ведь те же десять лет назад попробуй скажи такое — как бы область деятельности не пришлось менять. И вот такое происходит просто с языками программирования за довольно короткое время. А основа любого CMS, фреймворка и иже с ними — это как раз таки язык программирования. И вот за время жизни языка программирования в нём случаются новые стандарты, изменения и прочее, а популярное ПО на нём переписываются десятки и сотни раз. Т.е., изменчивость продуктов какого либо языка зависит как от самого языка так и от его популярности. И чем они выше — тем чаще что-то меняется. Из всего этого вытекает очень логичный вывод: в долгосрочной перспективе выгоднее те знания, которые не устареют как можно дольше. И вот тут как раз таки знания разработки ПО и языков программирования, построения архитектура, алгоритмы и прочее имеют наибольший срок устаревания. А уж сколько тысяч лет математике можно и не вспоминать. А она, кстати именно благодаря стремительному развитию IT тоже развивается очень быстрыми темпами. Так вот, при наличии вот таких фундаментальных знаний можно легко и быстро осваивать любые новые фреймворки, CMS, языки программирования и прочее. А уж при наличии подробных мануалов, гугла, форумов и прочего большинство задач сводится тупо к вбиванию "как сделать YYY в ZZZ" в строке поиска (я вот например никак не могу понять ход мыслей людей, которые задают вопросы на форумах и прочих ресусах, ответ на которые выдается в первых же строчках гугла, складывается впечатление, что они вообще первый раз в интернете и про гугл не знают вообще ничего).
Если есть желание именно в изучении CMS — ставим себе задачу и решаем её используя разные CMS, далее выбираем наиболее понравившуюся и пользуемся пока не надоест или не устареет. А после — повторить.

Немного перефразирую сам вопрос и соседний популярный ответ:
— Каким инструментом учиться пользоваться начинающему строителю?
— Учись использовать молоток и гвозди, леса полно, доски везде используются.
Вот только строительство — это не одни только доски, в которые забиваются гвозди, а еще архитектура, сопромат и иже с ним, экстерьер, интерьер, отопление, освещение, канализация, вентиляция и ещё куча всего. Аналогично и во всех остальных областях, в том числе и web разработке.

На 12 факторов.

Нигде. В парадигме ООП и снежинка и варежка и сцена - описывают только свое поведение методами и свойствами. Введите ещё одну абстракцию - мир(или физика), которая содержит все эти объекты и описывает поведение их взаимодействия.
Сцена детектит столкновение снежинкой и варяжкой - передает миру, а тот в свою очередь удаляет снежинку, запускает анимацию варяжке, запускает в сцене радостный звуковой щелчок.
Таким образом, если в дальнейшем реализовывать дополнение "Грачи прилетели", то легко реализуется логика столкновения варяжки и помета => помёт остается, варяжка замирает, в сцене грустный звук "ооу"

SVG и только SVG.

Ну, можно, конечно, делать всякие абсолютно позиционированные прозрачные блоки на HTML, но там это сложнее позиционировать в силу отсутствия viewBox, как у SVG.

Кроме того, блоки на HTML не могут иметь произвольную форму, а только прямоугольную (clip-path не в счёт, с ним ещё сложнее будет реализовать), что вызовет проблемы при совмещении нескольких объектов произвольной формы вместе. Точнее, будет проблема с зоной взаимодействия этих объектов при наведении мышки из-за наложения прямоугольников.

Все такие интерактивные карты делают с помощью SVG, что как бы намекает.

https://medium.com/@mattcroak718/creating-an-inter...

Я делал такую карту с помощью Boxy SVG:
https://boxy-svg.com

Можно делать в Inkscape, там тоже есть режим просмотр кода разметки.