Если используется композер - то свои автолоады крайне не желательны, ибо вносят долю хаоса. Конечно, исключения возможны, например, автоматическое генерирование классов на из запросе и что-то подобное, но, имхо, даже это можно сделать используя стандартные схемы автолоада. А на крайний случай, да, можно использовать свой spl_autoload_register, но и тот я бы советовал подключать через files автолоада композера
У вас неверный EAV. Value должно быть в product_option, иначе нарушается нормальная форма.
EAV вообще так себе паттерн, его даже часто называют анти-паттерном, и не только из-за проблем с типами, но и из-за проблем с фильтрацией по нескольким условиям.
Типы в EAV решают кто во что горазд. Кто-то отдельными таблицами, кто-то отдельным полем с указанием типа (и большой varchar value), кто-то просто текстом.
Если вы хотите давать разные виды доступа (с разными лимитами) разным пользователям - то да, считать. Не по IP, конечно, а по ключу/логину и т.п. Хранить в базе соответствующие показатели, накапливать запросы и пересчитывать счетчики с какой-то периодичностью. Если нагрузка мала - можно и на каждый запрос считать.
Если цель - защитить скрипт от флуда - это делается на уровне веб-сервера или даже фаирвола. Но в таких случаях не стоят задачи "до 1000 запросов в день", там стоят задачи "N запросов в секунду". Для nginx, например, модуль ngx_http_limit_req_module.
По сути https - https работает через расшифровку и повторную шифровку, т.е. сертификаты должны быть и на nginx. Посмотрите пример любого ssl сервера на nginx.
По ТК вы должны работать 8 часов. По санпину - каждый час должен быть предоставлен отдых на 15 минут. Т.е. как миниум полтора часа уйдет на отдых (не считая обеда). Остальное, по идее, вы должны работать. То, что тут пишут про "4 часа" - это обычное нытье посредственности. Просто научитесь отдыхать и расслабляться в эти 15 минут и менять задачи по ходу дня. Если задача одна и объемная - для разбавления рутины выделяйте время на ревью своего кода, рефакторинг и т.п.
Если вас перевели на рабочем месте на почасовую оплату, то поинтересуйтесь - как будут оплачиваться отдых, если никак - просто требуйте поднять ставку часа.
Вот тут все популярные способы https://habrahabr.ru/post/114997/
Наиболее популярный - N-грамм метод. Готовые реализации есть в mysql 5.7 и postgresql. Впрочем, и самому сделать реализацию весьма просто.
Ну и в добавок к этому я бы предложил вбивать не только оригинальное название, но и звучания на русском и английском в отдельных полях хранить и использовать их для поиска тем же три-граммом.
Думаю под знанием linux подразумеваются базовые знания пользователя, такие как:
отличие наименования файлов (case-sensitive, slash), символьные ссылки, как работают права доступа, как запускаются скрипты.
основы шела, путешествие по файловой системе, основные команды (типа ls, mkdir, mv, rm, grep, tail, head, и т.п., пайпы и редиректы, sleep и bg процессов)
представлять, что такое процесс, базовые вещи по управлению ими (ps хотя бы).
что такое крон, как им управлять.
Насчет управления пакетами.... не знаю, имхо это не обязательно. Ну если ты растешь сам по себе, наверное все-равно такие вещи узнаешь, но для приема на работу не должно быть серьезным критерием - подготовка среды разработки - задача не разработчика, а девопса или на худой конец тимлида.
При регистрации пользователь вводит пароль к примеру 123, он хешируется через password_hash. Далее, при аутентификации пользователь вводит пароль 123, из базы по логину достается сохраненный хеш, и проверяется через password_verify.
Обратите внимание на слеш в конце адреса бекенда. Именно он показывает необходимость реврайта URI запроса. Учтите, что этот реврайт никак не влияет на само тело запроса (т.е. если у вас вернется html со ссылкой a href="/", то она такой и останется)
__сall вызывается только если метода в классе нет, по-этому в вашем случае будете разное поведение при обращении к объекту извне и при обращении внутри класса, что не есть хорошо.
Ради экономии одной строчки с return такое не стоит делать.
Если уж делать, то полностью магию убрав setPreset вообще, или используйте IDE, который умеет генерить fluent setter
То, что в MySQL называется "база данных" - это не совсем базы данных в понимании других СУБД, а не более чем схемы. Это позволяет без проблем делать запросы между ними, равно как и в других СУБД вы можете это делать между схемами. А база данных в понимании баз данных других СУБД у MySQL всегда одна, так что и подключение как бы всегда к ней.
Через дом, конечно, можно. Но это может быть довольно затратно, а так как эти теги вставляет ваш редактор (т.е. структура достаточно детерминирована), то много проще обойтись регекспом.
Я вот добавлю. Адаптивная верстка вообще как раз и нужна для того, что бы сайт на меньших экранах выглядел не так, как его просто масштабировали, а более адаптивно ;)
Т.е. не так
А вот так
