ThunderCat

https://habr.com/ru/articles/435084/
https://habr.com/ru/articles/490524/

Ошибка детская, она вот в этом: "Есть 2 таблицы, в которых одинаковые поля".
Очень часто новички, которые не понимают, как работает база данных, делают подобное.
И всегда потом приходится переделывать, даже если очень не хочется.
Потому что в БД не должно быть таблиц с одинаковыми полями. Собственно, сообразительные новички уже на этом вопросе, "как выбрать из двух таблиц" начинают понимать, что у них что-то пошло не так.

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

Имя таблицы, кстати, тоже очень странное. Наверняка там внутри тоже треш и угар и вот её-то как раз и надо разделить, только не горизонтально, а вертикально. Судя по составу полей, нужна одна таблица city и одна таблица people, в которой указывается только city id

Никто не подскажет, потому что сам по себе ваш код рабочий.
Скорее всего, вы выводите данные не сразу, а в каком-то другом скрипте, например после редиректа, но почему-то ожидаете, что РНР будет таскать за вами массив $_POST по всему сайту, и при этом помнить, какой именно $_POST вам нужен в данный конкретный момент, среди всех форм, оправленных всеми пользователями на сайте.

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

<form method="POST" action="">	 
  <input type="hidden" name="label" value="<?= htmlspecialchars($_POST["label"]) ?>" />
  <input type="hidden" name="amount" value="<?= htmlspecialchars($_POST["amount"]) ?>" />
  <input type="submit" name="ok" value="" id="button" />
</form>

Идентификаторы должны оставаться неизменны, в этом их суть.

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

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

Я настоятельно рекомендую книгу Святослава Куликова "Реляционные базы данных в примерах", она свободно доступна для скачивания. В ней как раз и даются основы проектирования баз данных.

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

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

Код в итоге будет что-то типа:

index.html:

<div>
  <p>{{text}}</p>
</div>

i8n/ru.json:

{
  "text": "Привет мир!"
}

i18n/en.json:

{
  "text": "Hello world!"
}

i18n/es.json

{
  "text": "Hola mundo!"
}

Но если у тебя появляются динамические данные, нужна поддержка right-to-left языков, и вообще нужна адаптация под разные регионы (типа чтобы условный Американец и условный Китаец получали разный UX), то всё будет немного сложнее. Гугли дальше по словам "Интернационализация" и "Локализация"

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

Что значит "не задаётся бэкграунд"? Всё накидывается и работает в соответствии с тем, что указано в css.
У nav белый фон, у списка внутри - серый, согласно универсальному селектору

* {
    box-sizing: border-box;
    background: #E5E5E5;
}

(без чёткого понимания всех нюансов этого селектора использовать его не рекомендуется).

При соединении с БД надо указывать кодировку.
Поскольку на сайте используется юникод, то соответственно указывать надо utf8mb4

А сессии тут вообще не при чем.

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

Основных правил при обработке исключений три:
1. Не использовать исключения там, где они не нужны. Например, при проверке пользовательских данных.
Собственно, эмпирическое правило звучит так: функция должна бросать исключение, если она не может выполнить ту работу, для которой она предназначена.

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

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

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

Пример такого исключения - когда запрос в БД порождает ошибку.

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

Для информирования можно действительно ловить исключение через try..catch и писать какое-то свое сообщение.
Но можно и автоматизировать этот процесс, вот две статьи, которые показывают примеры, как это можно сделать:
https://angelovdejan.me/2022/11/24/centralized-exc...
https://habr.com/ru/articles/688202/

ну элементарно вроде:
Клик по кнопке -> Запрос данных -> Вставка данных в модалку -> Отображение модалки.