s5656

Несмотря на то что в вопросе немного каша, а в ответах - ад, ответ на вопрос, в общем-то, очевидный.

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

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

Хайлоад же проекты - это из немного другой области. Тут идет откат скорее в обратном направлении. Это как с денормализацией - БД должна быть нормализована, но из соображений производительности иногда приходится денормализовывать. ПОСЛЕ того как нормализовал.
SOLID помогает делать большие проекты управляемыми. Но когда большой проект сталкивается с высокими нагрузками, иногда приходится жертвовать принципами ради производительности. Но тут главное, опять же, не путать направление: СНАЧАЛА делаем правильный дизайн, и только потом в критических точках снижаем накал абстракции, переходим на более низкий уровень. Самый наглядный пример - ORM, когда критические запросы переписываются на чистый SQL.

Ну и пройти "полный курс" не имеет ничего общего с "полным изучением". С полного курса изучение всегда только начинается.

сейчас придет кто-нибудь и нарисует svg, но я не умею, а на css/scss можно начать как-то так

HTML никак специально экранировать не нужно. И вообще ничего экранировать не нужно. Экранирование - это треш, угар, прошлый век и инъекции. Данные в БД надо просто посылать отдельно от запроса.

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

Причем твоя лично проблема здесь совсем не в том, "как экранировать". HTML никак особо экранировать не нужно, базе данных абсолютно всё равно, что ты внее вставляешь. Твоя проблема в том, что ты в принципе не знаешь пхп и путаешься в основах языка, используешь устаревшую версию, которая не будет работать на живом сайте. И даже самый базовый синтаксис тебя пугает. Поэтому извини, я буду писать ответ не для тебя, а для тех, кто, в который раз, задается этим вечнозеленым вопросом, но по какой-то причине не смог освоить базовые навыки работы с гуглем/яндексом.

Чтобы вставить данные в mysql, и вообще никогда не думать ни про какое "экранирование", надо
1. Все переменные в запросе заменить на знаки вопроса
2. Подготовить запрос к исполнению
3. Привязать переменные к знакам вопроса
4. Выполнить запрос.

Как я уже говорил, функций, которые начинаются на mysql, в языке давно нет. Остаются только те, которые начинаются на mysqli и PDO. Вот для них я и приведу примеры.

mysqli

$type = 'testing';
$reporter = "John O'Hara";
$query = "INSERT INTO contents (type, reporter) VALUES(?, ?)"; // заменем
$stmt = $mysqli->prepare($query); // подготавливаем
$stmt->bind_param("ss", $type, $reporter); // привязываем
$stmt->execute(); // исполняем

Важно! Чтобы этот код работал, сначала надо правильно установить соединение mysqli
PDO

$type = 'testing';
$reporter = "John O'Hara";
$query = "INSERT INTO contents (type, reporter) VALUES(?, ?)"; // заменяем
$stmt = $pdo->prepare($query); // подготавливаем
$stmt->execute([$type, $reporter]); // привязываем и исполняем

Важно! Чтобы этот код работал, сначала надо правильно установить соединение PDO

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

1. Yii мёртв. Устарел лет на 10 по подходам и кодовой базе, и не развивается.
2. Плохой дизайн. Глобальное состояние для всего, наследование от базового класса модели, валидация через массивы там же, наследование для расширения всего и вся и прочая чушь. Отсутствие многих удобных фич типа нормального DI/аргумент резолверов, чего только стоит гибкость конфигурации сервисов в Симфе.
3. Свои велосипеды вместо чего-нибудь готового
4. Все компоненты прибиты гвоздями и не заменяются своими. Это делает код на нём нерасширяемым и нетестируемым(Ну то есть в теории переписав пол фреймворка и 100500 своих адаптеров можно писать нормально, но те кто хочет писать нормально просто уходят с Yii).
5. Слабое комьюнити которое сидит на нём потому что не осилило ничего другого / генерирует CRUD`ы через Gii(Заменить бы их уже не postgrest и прочие обёртки над базой) / инертные кодеры которым без разницы чего делать лишь бы на хлеб хватало.
6. Все фреймворки далеки(очень) от идеала, но Yii сильно отстаёт от прочих.

0. Прочитать лицензионное соглашение/условия использования
1. Выполнить условия
2. Profit

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

Имея как опыт попыток устройства программером в РФ, так и работы на удаленке на США, я заметил разницу. В РФ нужно, чтобы код был красивым и технологичным, в США нужно чтобы код без глюков выполнял возложенные на него задачи, а фрилансер предоставлял послепродажное обслуживание. Поэтому в США решают задачи с помощью наиболее подходящего инструмента, и часто вордпресс подходит лучше, а в РФ делают более технологичный подход, под который вордпресс ну никак.

Wordpress это CMS для блогов и школьников

Так и есть.
Делайте на WP, никто же не запрещает.

Wordpress дырявый, как решето. Конечно, дыры там периодически закрываются, но никто не гарантирует, что прямо сейчас там нет неисправленной критической уязвимости, через которую этих вордпресс-хомячков вовсю сейчас имеют))

Главный аргумент против - это процедурный подход в разработке, ориентированный на хуки, слабая реализация принципа MVC. Даже в богомерзком битриксе с этим лучше. Чем более кастомная у вас разработка, чем более сложные задачи, тем больше приходится писать все самим, а не полагаться на какие-то готовые расширения. Какое-то время они могут "вывезти", но при дальнейшем росте можно столкнуться с невозможностью дальнейшего нормального развития продукта.

Итого: если клепать однотипные сайтики невысокой сложности и без перспектив особого роста, без особой кастомизации со стороны клиента - да, можно выбрать любимую опенсорс платформу и делать на ней абсолютно всё. Но чем сложнее перед вами ставят задачи, тем важнее иметь в руках не CMS, а удобный для кастомизации разработки и проектирования фреймворк. И в этом плане любое ООП-решение удобнее хуко-процедурной мешанины. Что не исключает, конечно, бездумное поклонение некоторых студий битриксу и впихиванее его во все дыры, где надо и не надо.