Ипатьев

Для ответов на подобные вопросы всегда полезно использовать логику.
Например:
Если необходимости в обратном порядке элементов нет, то array_reverse не нужна.
Если array_reverse используется - значит, скорее всего, необходимость есть, но вы её просто не видите.

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

"оставить исходный массив нетронутым" причиной не является.

Лучшие собаководы настоятельно не рекомендуют удалять теги с помощью preg_replace.

Строить dom дерево и обрезать ветки.

Вопрос хороший, характерностью имеющихся в коде ошибок.

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

Плюс мамаша конечно тупит. Данные надо не "экранировать", поскольку почти никто не понимает, что это значит, а отправлять в БД отдельно от запроса.

Но меня здесь больше интресует не безопасность, а осмысленность данного кода.
Если элемент "login" попадает в сессию в результате авторизации, то зачем снова делать все эти 100500 запросов в БД?
Я бы этот код сократил до

<?php
require_once $_SERVER["DOCUMENT_ROOT"] . "/engine/core/session.php";
if (empty($_SESSION["user_id"])) {
    include "login.php";
    die;
}

и поместил в profile.php

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

$stmt = $conn->prepare("SELECT * FROM users_all WHERE name=?");
$stmt->bind_param("s", $_POST['name']);
$stmt->execute();
$user = $stmt->get_result()->fetch_assoc();

if ($user && password_verify($_POST['password'], $user['password']))
{
    $_SESSION['user_id'] = $user['id'];
    header("Location: /profile.php");
    die;
}

Я уже отвечал на этот вопрос

Но самое конечно ужасное - это что этим людям доверяют работу с картами.
При том что все данные карт утекут в тот же момент когда этот "сервис" выйдет в онлайн

Надо добавить метод getImages($num=2) чтобы она принимала аргументом количество картинок и возвращала массив.
И в шаблоне можно будет сделать foreach(). Только дергать базу два раза некрасиво, лучше сначала получить в переменную, а потом ее использовать

<?php if ($images = $product_1->getImages()) : ?>
<?php foreach ($images as $img): ?>
    <img src="/media/uploads/small/small-<?= $img ?>" alt="<?= $product_1->prname ?>" title="Перейти в товар - <?= $product_1->prname ?>" />
<?php endforeach ?>
<?php else : ?>
  <img src="/media/uploads/nofoto.jpg" alt="Нет фото на товаре" title="Нет фото" />
<?php endif; ?>

Во-первых, вместо fetch надо использовать get_result|fetch_assoc.

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

// перед коннектом говорим mysqli чтобы сообщала об ошибках сама, 
// чтобы не проверять каждую команду вручную
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

// и дальше просто
$stmt = $connection->prepare("SELECT * FROM users WHERE email = ?");
$stmt->bind_param("s", $email);
$stmt->execute();
$result = $stmt->get_result();
$row = $result->fetch_assoc();
$hashed_password = $row["password"];
if (password_verify($password, $hashed_password)) 
{            
      echo "Вы успешно залогинились";
}

Правило номер 1: если у вас есть какая-то завиральная идея, типа "а решите мне вот такую-то примитивную стандартную задачу, но только вот с такими, такими и такими ограничениями", необходимо аргументировать свою задачу. То есть объяснять причины, которые привели вас к такой постановке вопроса.

Если при выполнении exec() возникает ошибка, то она выводится в stderr.
Надо просто прочитать её, там будет написано, почему не работает.
В частности, чтобы получать весь вывод кроновских команд на почту, в том числе и ошибки, надо написать в начале крон файла MAILTO=свойемейл

Если есть проблемы с чтением stderr, то можно добавить перенаправление в stdout, записать его в переменную и дальше уже направлять по своему усмотрению

$out = exec('cd /path && mysql -u root < "/path/my-sql.sql" 2>&1');
log_error($out);

Если подумать, то почти все вопросы новичков вида "Как сделать ххх" не несут никакого смысла.
Потому что если открыть сам вопрос, то по коду будет совершенно очевидно, что человек и так прекрасно знает, "как сделать это ххх". А вопрос у него - "как разобраться, почему оно не работает?" или - в более общем виде - "научите меня программировать".

Ну ОК, давайте учиться.

Главное в программировании - это делать всё по порядку.

У вас в текущей задаче участвует примерно миллион разных действий: html форма, код, который получает из неё данные, база данных, код, который ищет данные из формы в базе.
Если вы ещё не освоились со всеми этими элементами, то не надо их писать все подряд.
Надо делать по очереди, проверяя каждый этап.
И вопрос задавать не про весь код целиком, про который вам никто никогда не скажет, почему он не работает, а про конкретный этап.

В данном случае, если у вас база данных не находит пользователя по емейлу, надо сделать что?
Правильно - исключить все посторонние этапы. То есть написать емейл руками в скрипте и проверить - находит ли его запрос.
Если не находит - то здесь же, в скрипте, вывести все емейлы, и посмотреть глазками, а есть ли он вообще в базе данных?
Если нет - то вот она, причина. Найдена самостоятельно за 5 секунд без привлечения мирового сообщества.
Если есть, но всё равно не находит - то ищем непечатные символы и опечатки. например с помощью функции urlencode(). И исправляем то что она нашла. Русскую букву c или лишний пробел.

Если написанный руками емейл находит, а пришедший из формы нет, то надо сделать что?
Правильно - посмотреть на него глазками. А похож ли он на тот который руками написан? Если похож, то снова urlencode. Если не похож - то разбираться со своей формой.

Если всё равно не работает, то надо исключить другие посторонние факторы, например библиотеки, особенно такие кривые, как redbean. И отлаживаться на чистом PDO.

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

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

Нет, с MVC эта поделка в стиле конца прошлого века не имеет ничего общего.

"index.php, который возвращает в браузер разметку (картинки, формы, ссылки и другой HTML)" не имеет ничего общего с View. В клиент-серверной архитектуре в принципе невозможно реализовать десктопный извод MVC (ну кроме разве что SPA, но здесь явно не этот случай).
В данном случае вообще непонятно, как это работает, поскольку в любом веб-приложении "инфа приходит" не только, и не столько от пользователя, сколько наоборот - с сервера.
Вам не приходило в голову, что будет ваша система, если она должна будет по команде отобразить список юзеров? А откуда "view" возьмёт его?

"Всё это передается actions.php, файл который решает, какие функции из файла functions.php" - это винегрет из роутера, контроллеров и модели.
"(действие может быть сложным)" означает, что у вас классический "толстый контроллер". В то время как по определению все сложные действия делаются в модели, а контороллер их только вызывает.

Классический вариант клиент-серверного MVC:

Модель - вся бизнес-логика приложения. Это означает, что приложение должно уметь полностью выполнять свои функции с помощью одной только модели (на уровне вызова РНР кода и возврата структур данных в РНР). То есть возвращать список пользователей, удалять и добавлять пользователей и так далее. Выполнять все "действия, которые могут быть сложными".

Контроллер - тонкий интерфейс между моделью и браузером. Понимать НТТР запросы, принимать данные, приводить их в понятный модели вид и отправлять в модель. Возвращать нужные НТТР коды.
При необходимости что-то вывести - вызывает view и передаёт туда данные, полученные от модели.

Вью - рендерит полученные данные в зависимости от желаемого формата, обычно - HTML

Необязательный роутер - при наличии единой точки входа раскидывает апросы по контроллерам.

Реализация MVC на классическом РНР спагетти-стайл:

Модель - может быть набор функций, как здесь. Но все "сложные действия", которые складываются "из кирпичиков" тоже должны быть в модели.

Контроллер - РНР файл, который принимает запрос, например на отображение списка пользователей, вызывает нужную функцию из модели, и отправляет результат в браузер. Это может быть либо НТТР код, или HTML или JSON. В случае с HTML вызывает примитивный шаблонизатор, передавая в него массив с данными и имя файла - шаблона

Вью - тупо HTML файл с вставками РНР. Делится на две части, общий шаблон сайта и шаблон конкретной страницы/действия.