Ипатьев

Безотносительно к проблеме с неизвестно откуда берущимся кодированием, чем не устроил вариант
simplexml_load_file($url);

Мысль совершенно правильная.

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

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

Поэтому я бы рекомендовал их все равно изучать, но в качестве не основного, а факультативного материала.

Чтобы решить проблему, её надо сначала сформулировать.
В данном случае никакой проблемы нет, есть невнятные страдания.
Ни кода, ни внятного описания проблемы, ни даже пояснения, что имеется в виду под "добавлением" в вопросе нет.

В простейшем случае либо делать один множественный запрос insert, либо заключить отдельные запросы insert в транзакцию

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

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

И в ваших примерах для PHP тоже просто переводы. Причем не очень удачные.
link - звено - не слишком подходит по смыслу, и почти не используется.
connect - это глагол, а в качестве имен переменных обычно используются существительные. connection подойдет лучше, но совсем длинно.
con - хоть и является сокращением от connection, само по себе означает жульничество. Тоже так себе слово. Поэтому если уж сокращают, то обычно до conn.
Но само по себе "соединение" малоинформативно. Соединение с чем?
Поэтому я обычно рекомендую писать $db - сокращение от database. Тут и коротко, и сразу понятно, о чем речь.

Причем если речь идет об объектах, то всегда можно использовать имя класса в качестве имени объекта.
Например, если вы используете mysqli, то и называйте переменную $mysqli.
Если используете PDO, то называйте переменную $pdo.

$result - подходящее имя, от объекта mysqli_result.
$response обычно употребляется в контексте НТТР., для базы данных не очень подходит.

Причем от использования $result в коде надо уходить. Это промежуточная переменная, которая сама по себе вам не нужна, а требуется для получения реального результата запроса. Ну так вы вполне в состоянии написать функцию, которая сразу возвращает нужный результат, без колупания в промежуточных результатах.

$user = db_get_row($mysqli, "SELECT * FROM users WHERE email=?", [$email]);

и никаких мусорных $result, не говоря уже о том что кода в 5 раз меньше

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

В целом, я считаю что основная причина здесь - это отборный говнокод в переменной $Functions. Я прямо на 100% уверен что каждую строчку оттуда можно помещать в палату мер и весов с пометками "вредные советы" и "дети, никогда так не делайте, за это вам нехороший дядя сделает а-та-та!" Уже за одно только наличие функций redirect() и getString() в одном классе надо автора возить лицом по клавиатуре, желательно механической.

Но если говорить о записи в БД, то причин может быть две.
1. Код вставки вообще не вызывается. Например, $Functions->redirect(); вызывается в случае, если $openid->validate() возвращает false. Хотя понять это можно, только скопировав это адово форматирование в нормальный редактор.
2. Если при выполнении запроса произошла ошибка. Чтобы видеть ошибки mysqli в устаревших версиях РНР, надо добавлять при коннекте строчку

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

и, чтобы два раза не вставать, заодно убрать бессмысленный говнокод try{ }catch(ErrorException $e){ echo $e->getMessage(); }

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

Не должно у вас изменение сущности в одном приложении влиять на сущность в другом.

Весь мир с ума сходит по микросервисам, убивается на распилке монолитов.
А у вас они уже есть, но вы хотите слепить из них обратно монолит.
У вас сейчас низкая связанность, а вы хотите ее повысить на пустом месте.

Какая проблема, чтобы Client сходил в Order, получил идентификатор созданного заказа и дернул Billing?
Зачем во всех этих трех сервисах делать тройное дублирование сущностей?

Если вы считаете, что данные не заносятся в БД, то на это может быть две причины
1. Ошибка при занесении.
2. Все заносится, но вы просто не там смотрите.

Чтобы исключить первый пункт, надо убедиться в том, что вы можете видеть все ошибки. Для этого на локальном сервере надо включить отображение ошибок на экран. Плюс настроить РНР, чтобы он не скрывал никакие ошибки

<?php
# Ошибки
# Для локального сервера
ini_set('display_errors', 1);
# Всегда
error_reporting(E_ALL);
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

# дальше пишем сам код
$login = trim(filter_input(INPUT_POST, 'login'));
$password = filter_input(INPUT_POST, 'password');

if (mb_strlen($login) < 4 || mb_strlen($login) > 15) {
  exit("Логин не должен быть короче 4 символов и больше 15");
} else if (mb_strlen($password) < 8 || mb_strlen($password) > 100) {
  exit("Пароль не может быть короче 8 символов и больше 100");
}
$password = password_hash($password, PASSWORD_DEFAULT);

$mysql = new mysqli('176.107.160.36', 'limbo', 'Fear333M', 'vanilla');

$stmt = $mysql->prepare("INSERT INTO `sait` (`login`, `password`) VALUES (?, ?)");
$stmt->bind_param("ss", $login, $password);
$stmt->execute();

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

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

Проверять надо не на "пустую строку", а на наличие ошибок. Для чего в массиве $_FILES есть специальный элемент. Который и надо проверять всегда при загрузке файлов.

При этом надо определиться - зачем загружается несколько файлов. Если речь об одном файле, то зачем делать 4 поля ввода? Если нужно несколько файлов, то почему проверяется только один? Проверять тогда надо все, в цикле.

Вообще всегда полезно читать инструкцию перед тем как садиться что-то делать. Или хотя бы после того как ничего не заработало.

include.
РНР файлы в РНР подключаются с помощью конструкции include.

Потому что одинарные кавычки имеют в программировании определенный смысл, и их надо писать только там, где надо, а не просто добавлять от балды в код?

В цикле.
Все операции над массивами производятся в цикле.

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

insert into odna (col1, col2) select col1, col2 from drugaya;
insert into odna (col1, col2) select col1, col2 from tretya;

Главная проблема музыки в России начинающих программистов в том, что они "перерывают интернет" в поисках решения своей задачи. А надо - в поисках того, как разобраться, в чем проблема.
Потому что само решение и так уже есть.

Как минимум - в начало пхп скрипта и смотреть на ошибки

ini_set('display_errors',1);
error_reporting(E_ALL);