Ипатьев

К созданию таблиц это не имеет никакого отношения.
проблема вызвана незнанием элементарного синтаксиса SQL

insert into product (name, quantity) values ('test4','10');

A magic!

Если сделать var_dump с переменными и var_dump с числами, то вернутся одинаковые данные:

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

Вам надо обязательно научиться проверять свои догадки. Причем проверять надёжно, а не как сейчас - тяп-ляп.

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

Это не нужно делать.
"Переменная", имя которой может меняться в цикле - это индекс массива. Списка или коллекции.
В данном случае a - это список, и обращаться к его элементам можно по индексам, a[1], a[2], и так далее

Соответственно, код будет

a = []
i = 1
while i <= 5:
  a[i] = i
  i += 1

Указать правильный путь к файлу

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

Я даже не представляю, сколько раз на этот запрос здесь уже отвечали. Но разве ж тут что найдёшь...

WHERE date BETWEEN '2021-10-01 00:00:00' and '2021-10-30 23:59:59'

Не нужно искать решение специфической задачи "как писать в колонку".
Это всё равно что отдельно искать в гугле ответы на вопросы "как есть борщ", "как есть солянку", "как есть щи".
Надо освоить несколько базовых понятий, и уже применять их для решения неограниченного круга задач.
В данном случае надо просто подумать - что такое файл, что такое csv файл, как можно организовать работу с несколькими колонками. А главное - понять, что файл всегда перезаписывается ЦЕЛИКОМ. То есть каждый скрипт должен писать все колонки, а не только свои.
И всё получится сделать, самыми простыми средствами.

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

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

Надо забыть про mysqli_query и освоить функции prepare(), bind_param(), и execute(). Причём не только для insert, но и для select тоже. Потому что через него можно будет повытаскивать все пароли. Поскольку они ещё и не захэшированы.

Надо хотя бы что-то делать самому.
Обычный inner join выберет только те продукты, который относятся к выбранной стране, и только те подкатегории, которые относятся к этим продуктам (при условии, что подкатегории как-то связаны с продукатми). Ничего "сложного" или каких-то хитрых запросов здесь не нужно.
Вывести родительские категории чуть сложнее, но тоже надо сначала самому попытаться, а не просить чтобы написали целиком запрос.

"В F12" надо смотреть не Cookie, а вкладку Network. Все куки, которые ставит сервер, пишутся в ответе сервера на запрос.
Именно там надо смотреть, что за куки приходят.
И там же, в запросах браузера, смотреть - какие куки он отправляет.

В целом код какой-то странный, в части проверок под длинным комментарием.
получается, что при первом логине, когда $result['hash'] пустой, он должен стирать все куки.
при этом код удаления ставит куку id, а код проверки использует куку ID

Для начала я бы проверил работу кук без всякой авторизации, просто выставлял и проверял наличие. А потом постепенно добавлял бы код. В общем, обычная отладка.

503 - это не блокировка, а ошибка. Надо смотреть в логах - какая именно, и исправлять

Решение очевидное - выдавать каждому клиенту свой токен.