Yan-s

очень отпугивает своими таблицами и запросами.

Работать с файлами будет сложнее. Намного.

Mysql. Таблицы - очень просто и интуитивно понятно. Запросы - человеческий синтаксис, очень удобно оперировать данными. Высокая надежность, огромное количество информации, сообщество.

Файлы - вообще не вариант. Вот несколько популярных вариантов которые можно рассматривать в качестве хранилища данных: mysql, sqlite, postgres, redis, mongodb.

Рекомендую выбрать из первых двух. Вероятно sqlite будет проще для вас.

Не вижу смысла создавать отдельную таблицу из-за 6-ти типов кузова

Что насчет такого смысла: использовать рабочий, проверенный, расширяемый вариант, вместо придумывания того, с чем могут возникнуть проблемы?
Если нужны будут выборки моделей по возможным типам кузова, как будете решать без доп таблицы?

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

А в чем вопрос? Вы решили хранить значения в формате CSV, что нужно реализовать? При создании записи записываете в поле через запятую идентификаторы. При получении записи разбиваете строку с идентификаторами в массив по разделителю. При обновлении записи перезаписываете поле целиком на новый набор идентификаторов.

Если не Git (а правильно таки git, но мало ли что у вас там с хостингом), то есть инструменты для деплоя по FTP. В том же phpstorm есть.

Совсем для ленивых, тупой вариант - берем FTP клиент, например Filezilla, открываем директорию с проектом на сервере, копируем в нее файлы проекта, Filezilla спросит что делать с совпадающими файлами, выбрать вариант "заменить если отличается размер и дата изменения"

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

К сожалению идеальных вариантов не придумано и выбирать надо наиболее подходящие под задачи.

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

У звездных систем недостаток в том, что запись которой 1 человек дал 5 звезд будет выше в рейтинге, чем запись которой 5 звезд дало 10 человек, а 1 дал 4 звезды.

Так что в чистом виде такие подходы очень условные. Можно придумать (или найти готовую) формулу дающую более взвешенный результат, но нужно учитывать дополнительные переменные.

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

Так это вы скажите, на кой чорт вам Wordpress? Если не знаете, то видимо не нужен.

либо же самому загружать это изображение через форму и потом искать на сервере

Что?
Изображения хранятся в виде файлов, на сервере, иногда на отдельном файловом сервере. В БД хранится запись о изображении. Путь, связи, другая мета информация, если требуется.

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

P.S. В php я полный ноль.

Тогда начните с изучения языка php.net

docs.guzzlephp.org/en/latest/request-options.html#proxy
https://stackoverflow.com/questions/5211887/how-to...

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

Отобразить форму для ввода ФИО, других паспортных данных, телефона, на втором шаге заполнение анкеты для классификации клиента по социальному положению, интересам, платежеспособности. На третьем шаге подтверждение вводом кода из смс. Форма должна всплывать поверх сайта и блокировать его использование до успешной отправки.

Зачем? Вы что то не то хотите. Значение и так придет на сервер в соответствующем массиве откуда вы сможете его получить и сохранить в переменную с любым удобным вам именем.

Вы же не указываете требования к интерфейсу, значит на фронте может быть что угодно. Даже голый HTML.

Поступите так: возьмите блокнот и подробно опишите сервис, который планируете делать. Что там обязательно должно быть, чего точно не будет. Опишите типичные юзеркейсы, процессы регистрации/входа/поиска/создания вопроса и тд. А там глядишь и станет понятно, что понадобится для реализации. А если нет, то тогда уже сможете конкретно спросить как лучше реализовать то или иное.

Зависит от задачи. Оба варианта могут быть использованы.

Если у вас страница интерактивная, используется AJAX для основного контента, то верным будет второй способ. Иначе у вас будет дублирование в контроллере страницы и в контроллере AJAX.

Можно применять различные стратегии в зависимости от ситуации.

Если вероятность заказа высока или объем явно не большой, можно провести полноценную оценку и включить потраченное время в итоговую стоимость. Или можете не включать это время, если хотите.

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