ThunderCat

без при помощи 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, которые умеют это "из коробки" и не требуют дополнительных настроек сервера как в случае чисто
пхп лонг поллов.

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

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

Начнем с того что сжатия изображений без потерь не работает для уже сжатых файлов, например jpg, png, gif, за редким исключением, когда например гиф или пнг имеют меньшее реальное количество цветов чем задано в палитре. Речь идет о сжатии с потерями, которое хотя и не портит изображение до неузнаваемости, все же вносит серьезные искажения в картинку, как в цветовом плане, так и в плане "зернистости" и "артефактов". Приемлемый уровень сжатия индивидуален для каждого отдельно взятого изображения, и чаще всего отображается в условной шкале "качества" от 1 до 10 (иногда от 1 до 100, просто шаг искажений делают меньше), где 10 - очень малая степень сжатия и высокое качество, а 1 - полный фуфел, в котором не всегда можно угадать о чем вообще картинка. Соответственно, сжать все в папке не лучший вариант, с каждым проходом и пережатием качество падает, даже не смотря на то что мы выставим максимальное качество, через N итераций мы получим фуфло в чистом виде. По этому гугл определяет отношение размера картинки в пикселях к размеру в байтах и выдает рекомендации на основе статистики, сколько примерно должна весить такая картинка, +/- , пережимать или нет. Так что я бы не стал прям вот все картинки в папке так наивно под одну гребенку.