AHTUxPK

created() {
      window.addEventListener('click', (e) => {
        if (!this.$el.contains(e.target)){
          this.selectListShow  = false
        }
      })
  },

тут изначально очень не правильный подход. не нужно делать "дефолтную конфигурацию" через глобальные переменные.

class DbConnection
{
    private string $userName;
    private string $password;
    private string $dbname;

    public function __construct(string $userName, string $password, string $dbName)
    {
        $this->userName = $userName;
        $this->password = $password;
        $this->dbname = $dbName;
    }
}


class AuthController
{
    private DbConnection $dbConnection;

    public function __construct(DbConnection $connection)
    {
        $this->dbConnection = $connection;
    }
}

$dbSettings = include('dbconfig.php');
$connection = new DbConnection($dbSettings['login'], $dbSettings['password'], $dbSettings['dbName'] );
$controller = new AuthController($connection);

а в файле dbconfig.php

return [
'login'=>'myLogin',
'password'=>'myPassword',
'dbName'=>'myDbName'
];

Чтобы запрос всегда выполнялся, надо делать так
1. сначала подготавлиавешь запрос, вместо всех переменных ставишь знак вопроса
2. в bind_param пишешь столько букв s, сколько переменных, а дальше - сами переменные
3. выполняешь запрос

Кроме того и в тот и в дргой файл надо добавить разные нужные вещи, и выкинуть ненужные.

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

database.php взять отсюда , только название БД свое подставь

saveOrder.php :

<?php
include "database.php";
$order_number = $_GET["order_id"];

$sql = "UPDATE `orders` SET `order_status`=?,`customer_surname`=?,`customer_name`=?,
`customer_patronymic`=?,`email`=?,`phone_number`=,`second_phone_number`=?,`address`=? 
WHERE `orders`.`order_number` =?";
$stmt = $connection->prepare($sql);
$stmt->bind_param("sssssssss", $_POST['orderStatus'],$_POST['customerSurname'],
    $_POST['customerName'],$_POST['customerPatronymic'],$_POST['email'],
    $_POST['phoneNumber'],$_POST['secondPhoneNumber'],$_POST['address'],$order_number
);
$stmt->execute();

// второй запрос делаешь по тому же принципу
header('Location: crm_order_page.php?order_id='.$order_number);

Как выглядит и работает фильтрация PHP POST & GET?

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

Фильтровать вообще надо не по принципу "откуда", а по принципу "куда".
Данные надо форматировать в зависимости от того, куда они пойдут, а не откуда они пришли. SQL запросу абсолтно фиолетово, откуда взялась кавычка в данных - из GET, файла на диске, или из другой базы данных. Данные для SQL надо правильно форматировать не потому что они пришли из GET, а потому что они идут в SQL.
(При этом надо также понимать, что SQL запрос и база данных - это не одно и тоже. Базе тоже по барабану, что в ней лежит. Любое форматирование мы делаем только для SQL запроса, а в базе данные снова должны быть как есть).

Я думал, что будут удаляться все кавычки и теги,а по факту они остаются.

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

Не использовать же для этого регулярки?

Нет, разумеется.
Использовать регулярки будет так же глупо, как и твою функцию.

Для того, чтобы поместить переменную в SQL запрос, надо использовать подстановки в подготовленных выражениях. Запомни это предложение. Оно важнее всего, что ты до сих пор успел узнать про пхп. Хорошоенько запомни, ты должен это знать лучше, чем зовут маму с папой. И никогда не отступать от этого правила. Не важно - нужна тебе защита от SQL инъекций или не нужна, из POST-а ли пришли данные, или Господь бог тебе их надиктовал на горе Синайской - все равно всегда и везде только через подстановки.

Поэтому.
1. Выкидываешь свою функцию на помойку. Единственное слово, которое там имеет там хоть какой-то смысл - это trim(). Ну так ты можешь вызывать её напрямую.
2. Судя по уровню кода и вопроса, для работы с бд ты используешь убогую mysqli. Поэтому забудь вообще про mysqli_query(), а все запросы, в которых используется хотя бы одна переменная, выполняешь только так

$stmt = $conn->prepare("INSERT INTO tablitsa (login_name,email) VALUES (?,?)");
$stmt->bind_param("ss", $login, $email);
$stmt->execute();

Подробнее можешь почитать в интернете.
3. При выводе пользовательских данных в HTML, используешь функцию htmlspecialchars(). Надеюсь, к этому моменту ты уже понял главную мысль - важно не откуда пришли данные, а куда. Идут в хтмл? Отлично, форматируем их для хтмл.

В магазине нажимают купить -> Редирект в банк -> После оплаты идет направление обратно в магазин с отметкой, что платеж прошел.

На самом деле происходит примерно так:
В магазине нажимают купить -> Редирект в банк -> [после оплаты банк дёргает секретный URL на сервере магазина, в параметрах передаёт информацию о платеже и хэш-сумму с секретной солью, взаимно известной только сайту и банку -> магазин проверяет эту информацию и если хэш совпадает, то считается, что платёж прошёл -> магазин производит операции по добавлению товара пользователю (если он виртуален), либо по уведомлению сотрудников, что такой-то товар оплачен и его нужно доставить такому-то покупателю] -> После оплаты идет направление обратно в магазин с отметкой, что платеж прошел.
То, что в квадратных скобках, происходит на стороне сервера, и пользователь никак не может вмешаться в этот процесс, сколько ни дублируй запросы. Соответственно, доверять тому, что вне скобок, нельзя, и даже если пользователя перенаправило на страницу с уведомлением об успешной оплате - это вовсе не значит, что оплата прошла, эту страницу он может вызвать сам когда захочет.

Парная к password_hash - password_verify

Эти функции - какой-то ужас, летящий на крыльях ночи. mysql_real_escape_string - вообще за гранью добра и зла.

Но главное, что я не могу понять - это какое отношение к mysql и mssql имеет функция xss_clean. Ну то есть я даже представить себе не могу, как можно функцию для защиты от xss применять для любых манипуляций c SQL. Это - я не знаю - как положить деньги в презерватив от грабителей. Он же служит для безопасности. Ну вот деньги и будут в безопасности.

По теме: ради всего святого, используйте PDO с подготовленными выражениями. Это сделает ненужной всю эту мышиную возню с регулярками. PDO поддерживает как mysql, так и mssql, так что разница будет только в синтаксисе запросов, а сам код работы с запросами будет один и тот же

$sql = "SELECT TOP 10 * FROM user where mssql.department_id=?";  
$stmt = $conn->prepare($sql);  
$stmt->execute([$_GET['department_id']]); 
$users = $stmt->fetchAll();

$sql = "SELECT * FROM user where mysql.department_id=? LIMIT 10";  
$stmt = $conn->prepare($sql);  
$stmt->execute([$_GET['department_id']]); 
$users = $stmt->fetchAll();

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

От XSS же надо защищаться совсем в другом месте, и также без всего этого ужаса

Сроки сдачи проекта. Постоянно нужно сделать проект "вчера".

Меняется ТЗ на последнем этапе.

Большая текучка сотрудников. Большой срок проекта.

Отсутствие фреймворка.

Лучше придумать не смог: клик на JSBin

Ну смотри, в OC - "модель" это файл с командами запросов и обработкой результата.
Ты его "подключаешь"...
$this->load->model('catalog/information');
...а потом вызываешь метод оттуда, передавая параметр в функцию

$information_id = 4;
$information_info = $this->model_catalog_information->getInformation($information_id);

Теперь у тебя в $information_info лежат данные в каком-то виде (об этом в самом файле модели - там обработка и запросы).

Эти данные тебе нужно вывести в некоем "шаблоне" - так случилось что в OC шаблоны называются так же, как и файлы действий - "контроллеры". Главную обрабатывает /controllers/common/home.php

В этом файле в самом низу есть вызов шаблона, в который передается переменная $data. В эту $data тебе надо твои данные сохранить, и они будут доступны в файле шаблона, который там вызывается.

В шаблоне уже выводи, хочешь циклом, хочешь другими шаблонами, способов масса.

Например так

open_basedir string
Ограничивает указанным деревом каталогов файлы, которые могут быть доступны для PHP, включая сам файл. Эта директива НЕ подвержена влиянию безопасного режима.

Когда скрипт пытается получить доступ к файлу, например, с помощью функции fopen() или gzopen(), проверяется местонахождение файла. Если файл находится вне указанного дерева каталогов, PHP откажется его открывать. Все символические ссылки будут раскрыты, так что с их помощью не удастся обойти это ограничение. Если файл не существует, то символическая ссылка не сможет быть прочитана и имя файла (прочитанное) будет рассматриваться open_basedir .

Опция open_basedir может распространяться не только на функции для работы с файловой системой; например, если MySQL настроен использовать драйвер mysqlnd, то LOAD DATA INFILE подпадает под опцию open_basedir . Множество функций PHP также использует open_basedir.