Антон Р.

Судя по постановке вопроса — WordPress + WooComerce + Купленная\Бесплатная тема и попытки ее настроить или OpenCart + Переделка базовой темы.
Фреймворк для магазина это при такой постановке вопроса откровенно херовый вариант, ибо: артикулы, номенклатура, прихода\расходы, модификации, цены, графики, отчеты, покупатели, личные кабинеты, скидки, бонусы, акции, валюты, НДС, сервисы доставок, внешние API и еще вагон и еще вагон и маленькая тележка аргументов против бездумного окунания в то, чего не понимаешь. Для саморазвития можно и... нужно, наверное.

К тому же не совсем понимаю, если выбрать в пользу фреймворка, то вроде как JS говорят лучше, чем PHP (не знаю почему)

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

switch($url){
    case "$url": include("pages/user/$url.php"); break; // Страницы

Это пять)

Вы в htaccess передаете параметр menu, а принимаете параметр url

Потому что оператор if, а не If

Делаешь запрос https://wp-kama.ru/function/wp_query распаршиваешь контент, удаляешь лишнее и сохраняешь https://wp-kama.ru/hook/save_post

Либо скриптом без подтягивания wp, смысл тот же

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

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

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

Вот достаточно популярный ресурс по паттернам.

Если вы хотите прям ООП-ООП, то у вас более половины вашего кода должно быть написано иначе(а ещё лучше на ООП языке типа Java). Не должно быть просто вызовов функций: вся работа через объекты. Никаких `$toolbar.append` и прочего.

Опять же, я могу быть глубоко не прав, но js ни ООП, ни ФП подход не реализует в полной мере. Поэтому только и остаётся, что писать в каком-то гибридном стиле. Возможно, что это огромная проблема языка, возможно наоборот.

Возьми доки по ООП и какой-нибудь framework и потрать на них 48 часов. Не 2, а 48. И все станет ясно. Твоя проблема очень распространена после 2-го часа знакомства.
Будет трудно, будет хотеться выпить, плюнуть и войти в белорусский рандом, но надо терпеть. Пройдет 48 часов и все станет на свои места.

Т.е. сложно понимаю, что "засунуть" в один объект, что в другой, что должно быть статическим методом, что приватным и тд.

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

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

Теперь задумаемся о декомпозиции всего этого хаоса. Мы находим какую-то задачу, которую выполняет наш код (например какую функцию вызвать для обработки каждого конкретного запроса) и выносим это в отдельный объект. Отправка email-ов - отдельный объект. Весь SQL зашиваем в отдельный объект. Соединение с базой - объект. Пользователи - объекты. Все - объекты.

И главное, у каждого объекта есть своя область ответственности. UNIX way. Каждый объект делает что-то одно и делает это хорошо. Бывает так что ну... нужно сделать так что бы один объект делал две вещи. НЕ вопрос, мы можем его попросить сделать что-то сложное, а он будет как хороший менеджер тупо делегировать работу другим объектом. То есть он и сложную штуку сделает, и сам не будет знать как она делается.

А все безхозные функции, которые не пренадлежат никаким объектам (например функции порождающие объекты) можно вынести в статические методы. Главное что бы статичесих переменных у нас небыло (ибо это те же глобальные переменные). И поменьше публичного ибо черт его знает что эти разработчики будут использовать. Причем "те разработчики" это вы завтра.

Вообщем писав всё время на процедурке, сложно перейти на ооп.

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

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

Подскажите, какой проект начать писать (гостевая, блог), или может начать изучать фреймворк.

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

Есть хорошие упражнения на развитие понимания объектно-ориентированного проектирования. Например вот: https://habrahabr.ru/post/206802/

Сразу хочу отметить что это крайности. Упражнения же. Они должны ограничивать вас что бы заставлять думать и задавать правильные вопросы.

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

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

Если сайт совсем не вариант переписать на чем-нибудь нормальном (в вашем спагетти проблема не только в запросах) - можно как паллиатив использовать phpfaq.ru/safemysql
Но не валяйте запросы по коду, соберите их в классы, работающие с конкретными таблицами и выполняющие абстрагированную от конкретного запроса работу. Так легче будет и сопровождать код, и развивать его дальше.

Это называется ленивой загрузкой (lazy load) ссылка

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

проанализируйте, как реализован тот или иной функционал в похожих проектах, это сэкономит вам время на изобретении велосипедов

далее уже приступайте к работе: дизайн, фронт, бек