ThunderCat

Зачем нужен ООП?
Кратко зачем ооп вместо функций:
1) Снижение сложности кода(да, звучит странно, но на самом деле именно так и есть - сложные вещи пишутся 1 раз, а далее вы пользуетесь практически предложениями естественного языка и описываем реально существующие манипуляции с реальными объектами, например $user->getName(), $image->rotateLeft()...)
2) Инкапсуляция - все что делает объект изолированно внутри одного инстанса, вы работаете по сути с отображением реальных объектов в цифровой мир(+ этот объект может быть сколь угодно сложным внутри, наружу он смотрит простыми методами для возможности операций над ним).
3) Снижение затрат памяти - классы подгружаются только в необходимом объеме и в нужно месте, в процедурном подходе все функции грузятся сразу.
4) Локализация кода - всегда логика одной сущности доступна в одном месте, не размазана по функциям и коду. Это такой нехилый бонус к инкапсуляции, и при рефакторинге вам не надо переписывать кучу кода, если объект был изначально правильно построен, максимум поменять немного логику внутренней обработки данных.

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

Я понимаю что это плохо и не правильно, но оно работает, хотел бы попросить у Вас совета, насколько это плохо, и можно ли использовать данный подход?

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

1) Сокеты - более дорогое по ресурсам соединение, ибо занимает слот и не умирает, оно выгодно там где в нем есть необходимость. В спа такой необходимости нет.
2) Писать код (и потом его обслуживать) как на фронте так и на бэке проще(читай дешевле) в классическом стиле, нежели оборачивать все в сокет. А бизнес не любит тратить лишние деньги. Это и к п. 1 относится.
3) Stalker_RED пишет что с кешированием могут возникнуть нюансы, я сходу не могу сказать так ли это, имхо в этом проблем не будет, если вы будете тащить сокетом только разметку, а статику брать по православному хттп. В случае статики по сокету конечно же вы хапнете этой беды по полной. Больше меня смущает как будет видеть страничку поисковый бот, но тут уже не узнаешь пока не построишь.

пару замечаний:
// remove all special characters - вероятно сделать 1 раз для всего текста будет эффективнее чем дергать каждый раз в цикле.

function reverseString(str) {
    return str.split("").reverse().join("");
}

скорее всего (не факт) будет работать быстрее развернуть всю строку и проверить на равенство.

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

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

Как это реализовать на js?

никак, точнее со стороны клиента в браузере никак. Можете использовать ноду на сервере, тогда будет на js и то что нужно.

Вы привязываете стили к id, а кнопке добавляете класс, будьте внимательнее.

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

вводим страну(в базе есть англия, германия, франция, испания, италия) и результатом будут города, всё это дело работает через ajax

ниче не ясно, дохрена кода, нихрена не понятно. Возвращаете вы что? Список городов принадлежащих стране? Листаете постранично как? Через линки или тоже аяксом?

Если же данные клиента не полные, то данные сохранять только в заданиях (таблице 2).

Почему? Чем обусловлена такая хитропопая логика? Вам от клиента по сути нужен уникальный номер, дальше привязывать к нему какие-то данные или нет вообще вопрос вторичный. Данные во вторй таблице(`customer_name`, `customer_phone`, `customer_email`) вообще не нужны, это нарушает 3 нормальную форму.

TL;DR
теги лишние уберите.
1) Расставьте вардамп и ексит в ключевых точках кода, посмотрите как идет выполнение и где что срабатывает не так
2) Откройте в хроме панель нетворк и посмотрите какие заголовки приходят на переадресацию.
3) Выключите/включите директивы переадресации в хтаксесе.

Кароче классический дебаг проведите.

Мой вам совет - не гонитесь за крутизной а ля "я выбрал все одним запросом", в данном случае это не лучшее решение, как ни странно. Я не знаю как у вас организованна работа с коллекциями объектов, в моем случае любой объект наследуемый от базового(итем, брэнд, пост, юзер...) имеет поле $haveImages, и при формировании коллекции объект коллекции получает все id выборки в отдельный массив, а массив выбранных и инициализированных данными объектов имеет индексы равные id объекта. После чего проверяется, если у объекта $haveImages = true; вызывается метод appendImages(), который уже делает выборку по картинкам где objectid in( ... ) и по результатам раскидывает их в объект $images(это коллекция картинок) каждому объекту из коллекции итемов (или юзеров или чего другого). В итоге каждый объект имеет в составе коллекцию изображений.

гугл отключили за неуплату?
js zoom plugin