Северное Сияние

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

В общем у меня уйдёт на это 2 - 2.5 месяца. Только на основы!

Ну обосраться. Два грёбаных месяца!!!1
До чего докатилась индустрия, что 2 месяца воспринимаются как огромный срок. И всё чаще натыкаешься на статьи, где пишут о годовалых якобы мидлах и трехлетних якобы сеньорах.
Лично я считаю, нужно потратить от 2-3 лет, чтобы начать более-менее прилично и системно ориентироваться в теме. В течении этих лет неоднократно будут возникать моменты, когда тебе кажется, что ты уже достаточно крут - но это только кажется.
Нормальный специалист средней руки формируется около 3 лет. Не гуру, не сенсей, не сеньор - просто крепкий линейный боец. Это много где так, не обязательно в JS. И это нормально.
Хочешь за несколько недель - иди установщиком пластиковых окон, как раз строительный сезон начался.

Можно сочинить множество причин, но на самом деле этим вопросом должны заняться психиатры. Не будет нормальный человек так тратить своё время. Можете всех, у кого рейтинг выше 1000, смело считать сумасшедшими. Нет, конечно среди них могут быть нормальные люди - но это следует доказывать, по каждому человеку отдельно.

9 класс блин) я в 9м классе не знал ни о существовании Хабра, ни о программировании - тем не менее жив, здоров, программирую) Наслаждайся детством парень, программирование с тебя и так все шкуры сдерет, так что не торопи события, позажимай одноклассниц там еще что-нибудь, но точно не Хабр читай))

Найти постоянную работу в офисе. Стабильности будет больше. Да и по деньгам не так уж плохо.

А в чём прелесть фриланса? Найдите удалённую работу. Улучшите стек, например, взгляните в сторону Vue.js, где сейчас платят очень хорошо. Сам верстаю и стою на распутье бэка и фронта. Не могу уйти с основной работы, так как «фрилансом», действительно, заработать стабильно и хорошо - сложно, если почти невозможно (на вёрстке).

Если альт и тайтл не заполняете то нет смысла

Сделайте статический класс хелпер и вынесите туда все ваши функции.

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

Ваш человек, который занимается сайтами ПРАВ! Стало сложнее, доходы НАМНОГО ниже. Обоснование также этому есть - технологии развиваются и сам по себе продукт "веб-сайт" немного отмирает в пользу других. Например обратите внимание, если раньше сайт был must have для любого бизнеса, то теперь для некоторых сфер более чем достаточно аккаунта в Instagram или мобильного приложения. Это ли не показатель того, что рынок уже далеко не тот.

Глядя на этот ужас, летящий на крыльях ночи, я всегда задаюсь вопросом: допустим, автор захочет написать аналог тостера. Что будет с текстом его вопроса после обработки такой функцией?

По поводу того, что сюда добавить:

В ужасе стереть все что что тут написано.
Прочитать раз в жизни документацию и забыть про mysql_real_escape_string как про страшный сон.
Включить голову, и сообразить, что mysql не подвержена XSS. То есть при записи в базу данных от этой атаки защищаться не нужно.
Освоить PDO, и использовать подготовленные выражения для работы с базой данных.

Все очень просто. Любой человек, как и механизм - изнашивается.
Работа мозгами - один из тяжелых видов деятельности. Т.е. это ровно такое же изматывание организма.
Изучение - тоже изматывание организма. В 20 лет начать и в 30 - разница колоссальная. Ты 4 часа можешь с девочкой в 20 лет, а в 30 - 5 минут. Поэтому все это понимают, что 30-и летний джуниор - это как минимум не состоявшийся нигде специалист. Достаточно старый и плюсов у тебя перед такими же 20-и летними нету - у них сил больше.

Ты можешь попытаться, но тебя будут собеседовать мальчики младше тебя. Будут гонять тряпками и ты будешь чувствовать свою ничтожность. Если ты устроишься джуниром, то будешь работать с ними - с детьми. А твои ровесники - управленцы, тимлиды и директора.

Тебе нужно посвящать огромное кол-во времени самообучению. А семья? Даже если нет семьи - это время. Много времени. Ты готов тратить все свое время, что бы к 35 стать разработчиком среднего уровня?

Мне 33 почти.

Вот тут
https://habr.com/ru/post/101544/
короткое и прозрачное описание разных вариантов организации версионности.

С течением времени было множество трактовок.
Одним из примеров MVC является - игровая приставка.

Model - сама приставка
View - телевизор, который подключается к приставке
Controller - контроллер для игровой приставки (манипулятор), так и называется. Неофициально - "джойстик".

Ключевым моментом является Model (сама приставка), в ней происходят все сложные процессы и вычисления, хранение данных и просчёты.
View, что в соответствии телевизор, - это лишь средство представления информации с вида, удобного для приставки (нули и единицы), в вид, удобный для человека.
Controller, что в соответствии игровой контроллер, - это способ преобразования команд с вида, удобного для человека (вперёд, прыжок), в вид, удобный для приставки.

Модель, в принципе, подразумевает у неё самой наличие функций, позволяющих ей меняться. Контроллер лишь командует - в какой момент времени каким функциям нужно вызваться, чтобы поменять модель. Если убрать из системы игровой контроллер, и попытаться отвёрткой замыкать контакты в гнезде игровой приставки (т. е. обратиться напрямую в модель, минуя контроллер), пытаясь тем самым "управлять персонажем", то это будет затруднительно - куда проще нажать на кнопку, а контроллер преобразует это в нужный вид.

Картинка из вики:

С точки зрения проектирования базы данных смысла во второй таблице нет. Просто разделение на две таблицы как правило является следствием использования каких-нибудь фреймворков, где "из коробки" создается таблица с "login. password, status", а для другой информации иногда вместо расширения этой таблицы создают вторую таблицу(например UserProfile) уже с "birthday, sex, ava" и тд. Но, повторюсь, по сути это лишняя сущность, поэтому хранить все в одной таблице более чем корректно.

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