Василий Назаров

во многих вакансиях я вижу также такие требования, как

У некоторых работодателей и такие требования бывают.

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

например
Но учтите

Странная логика насчёт "устарел".
Современный компьютер Бэббидж придумал в 1835 году, выкинем все свои компы/смарты?

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

В вашей ситуации может быть множество нюансов, но два крайних варианта видятся такими:

1. Всё так и должно было быть, согласно договора вашего начальства с исполнителем, примерно так (со стороны разработчика) "мы делаем статику, а потом ваш специалист ставит на ваш сервер и вашу CMS".
Ну, понятно, что в этом случае вам карты с мануалами в руки, и делать свою часть работы.
Кстати, я бы порекомендовал Вордпресс.

2. Разработчик держит вашу контору в лице руководителя за лоха.
Тогда можете попробовать вступить с ним(и) в переписку, начиная с того, что "вышлите, пожалуйста, инструкции по редактированию сайта и пароли для доступа к редактированию".
Если разработчик уйдёт в отказку, по крайней мере, вы сможете показать руководителю, что паролей нет, перейти к первому варианту, но уже с тем, что руководитель осознает глубину.

почему, если он такой крутой, то нет хостингов на его базе?

Примерно потому же, почему нет хостингов на Java, C++, Ruby, ...

Если у вас объёмы доработок томами ТЗ измеряются, может, выбрать что-то условно любое, максимально простое и расширяемое (возможно даже, что-то облачное с нормальным API, не Б24, так амоСРМ), и к нему припиливать свои хотелки? Всё равно к тому времени, когда вы все тома реализуете, от основы мало что останется.

Плюсы/минусы примерно те же, что и при сравнении "общественный транспорт" против "свой", причём как раз с учётом, что и общественный транспорт разный (как и конструкторы), и свой (от роликов до самолёта).

Напишите хотя бы 1 (лучше больше), пусть небольшой, лучше интересный проект. И начинайте стучаться на миддла сразу.
Или/и фриланс попробуйте задёшево для начала.

Оставьте контакты или напишите мне, обсудим, вариантов не так много, но есть нюансы, основные два:
1. Какой движок сейчас стоит и какая степень интеграции с ним потребуется.
2. Действительно ли поиск нужен только по наименованиям (это довольно редкий случай для магазина)

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

Плюсую к ответу "в чём вопрос" выше.
Вообще непонятно, как можно вдохновляться от разработок человека, который так "спрашивает" (то ли наставника ищет брату, то ли свои [cencored] сомнения просит укрепить, то ли себя рекламирует, не зная, "зачем это здесь")

Я не телепат, но выглядит так, что вы не туда идёте.
Посмотрите https://laravel.ru/docs/v5/eloquent

1. Вам нужно не "чистить куки", а "очищать корзину".
2. Если вы не разработчик, лучше не лезьте править код.

1. На скорость это повлияет так:
Без индекса по полю "date" выборка будет, естественно, более ресурсоёмкой. Но если добавить индекс только для этой задачи, то более ресурсоёмкой станет запись (перестраивать придётся оба индекса, а не один индекс по id).
2. В общем случае, порядок записи в БД и порядок возникновения события - это не одно и то же, но
- разница обычно не превышает долей секунд
- если вы используете time() MySQL-ную, эта разница становится вообще бессмысленной

ИИ, не?

Для начала нужно определиться, для чего на сайт будут приходить люди.
Если чтобы узнать, какие вы крутые и как много всего вы можете - лучше один сайт.
Если вы хотите сделать максимально "продающий" вариант - для каждой услуги/товара лучше делать отдельный лендинг. Размещать ли лендинги на отдельных доменах или делать их в виде внутренних страниц вроде site.ru/usluga - зависит от многих факторов, в т.ч. (но не только) от соотношения объёмов контента лендинга/основного сайта.