ThunderCat

Ээ... и что? Если пропустить маты по поводу процедурщины, в коде ничего нет что бы наводило на мысль о возможных причинах. Ни ошибок из логов, ни данных в базе, ни даже вывода хтмл этого куска. То есть в данном случае это вопрос к экстрасенсам.

Так как нормально отладить это нереально, идите по шагам.
1) Для начала - что выдается в сырец хтмл в поле img?
2) var_dump и print_r - полезнейшие функции в вашем случае. Проверьте что лежит в ваших переменных на всех этапах этой вакханалии.
3) как вы проверили что файл физически присутствует на сервере и доступен снаружи по хттп? пробовали руками в браузере прописать до него путь? Открывается? В базу точно попали хоть какие-то значения?

Как сможете ответить на эти вопросы - думаю либо найдете решение либо хотя бы поймете куда копать.

ps:

<img src="'.$final_image.'.jpg" class="ass"/>

а в базе храните путь с именем, получаете 123.jpg.jpg или 123.gif.jpg, достаточно было посмотреть в браузере что вы выводите, с чего собственно и надо было начать.

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

без при помощи ajax

? так без или при помощи?

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

1) Если сервер не боевой и стадия разработки не релиз - ВКЛЮЧИТЬ ВСЕ ОШИБКИ И ВАРНИНГИ
2) Если нет ошибки в браузере - смотри в логах
3) Если использовать данный код можно получить много нехорошего, от скл инжекции до "поморде" от тимлида.

redis

читать доки

Это волшебные функции, помести их себе на стену в код и они принесут тебе удачу понятие что у тебя происхолит

var_dump($tpl);
print_r($tpl);

ps: var $hrml;
В - внимание

"Допиливать" и "настроить" суть два абсолютно несопоставимых по затратам процесса, натянуть шаблон за 20 баксов и настроить опенкарт под нужды клиента - в 95% случаев достаточно и недорого, разработать свой продукт - затраты другого уровня, не каждая крупная компания берется за такую задачу, и занять все может от месяца в простом случае, до нескольких лет в более серьезном виде. А предприниматель всегда смотрит на затраты на продажу единицы товара - если есть опенкарт - зачем платить больше? Ему фиолетово что внутри, работает - что еще надо?

1) Для начала - не называть поля таблиц на румынском, используйте общепринятый стандарт - английские названия в нижнем регистре.
2) Читать про базы данных, выполнение запросов в пхп и понимать SQL на уровне "выбрать и отсортировать по полю".
3) Учить операторы for, foreach, while, понимать для чего и как их использовать.

В чем вопрос? При чем тут аякс и жквери? Делаете 2 соединения, присваиваете разным переменным ссылку на разные соединения - все. Когда нужно 1 бд - юзаете $bd1, когда второе - $bd2.

1) Четкая структура приложения, чтобы все модули работали по единой схеме(смотреть MVC как самую распространенную для пыха и самая понятная для новичков)
2) Объекты, почитать про solid и другие grasp.
3) Единая точка входа и понятный вменяемый роутинг
Тогда и только тогда разработка превращается из адского ада в приятный процесс написания красивого кода и обдумывания самых удобных/быстрых решений, вместо карябанья тонн фикалокода и тысяч строк дублей.
Ну и смотрите как что написано у серьезных проектов, гляньте внутрь какого-нть ларавел и фэтфри для начала.

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

echo curl?

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

Я смотрю здесь идет отбор на битву экстрасенсов )
Возьми за правило проверять действия пошагово если что-то не работает, для начала оставь только строку с редиректом, без ифа, далее логично проверить что попадает в условие проверки и тд.

Вообще связь от сервера к браузеру, а не наоборот не может быть установлена, т.к. технология хттп запросов этого не предполагает. Если есть четкая необходимость 100% ответа от сервера браузеру в момент обновления данных на сервере, существует 3 способа, из них вам тут настойчиво предлагают самый неверный.

1) Запрос аяксом по таймеру( грузит и сервер и клиент, выполняет кучу ненужных запросов, генерируя мусорный трафик)

2) Лонг поллинг запросы - упрощенно - на сервер идет 1 запрос от клиента, который имеет длинный таймаут, сервер держит это соединение открытым до момента когда на сервере появляются новые данные, после чего отдает в запрос эти данные и закрывает соединение, из браузера открывается новое соединение и тд. Искать тут или в гугле long polling.

3) Сокеты, в принципе это те же лонг поллы, только более оптимально обкатанные, обычно на soсket.io и node.js, которые умеют это "из коробки" и не требуют дополнительных настроек сервера как в случае чисто
пхп лонг поллов.

По всем трем видам море информации, можно смотреть статьи типа такой, весь функционал подробно разжеван.