s5656

Оффер - это предложение конкретному человеку выйти на конкретную позицию на определённых условиях, который выдаётся после собеседований. Очевидно, списка офферов нигде не существует. Видимо, вы имели ввиду слово "вакансия", а не "оффер".

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

Или же я вообще пишу глупость

В целом да. Но

вся эта логика прекрасно будет в index.php лежать?

- это гораздо большая глупость.
Ну то есть лежать-то будет, но к MVC уже никакого отношения не будет иметь.

По пунктам

Юзер не должен принимать в конструкторе логин и пароль.
Вот сейчас эта страница отображает мне двух юзеров помимо меня. Их обоих надо создавать с логином и паролем, серьёзно?

Что такое AuthPage вообще непонятно. Модель, контроллер? По базе проверяет модель, куки пишет контроллер. А здесь какой-то кадавр.

Перед тем как писать авторизацию "в стиле MVC", надо сначала разобраться, что такое модель, что такое контроллер, и что такое вью.

Модель - это вся логика приложения.
Контроллер - это интерфейс для общения модели с браузером. Делает всё, связанное с обработкой НТТР запросов.
Вью - отображение.

Как правильно.

Соответственно в модели должен быть класс User с методом auth(), который принимает логин и пароль и возвращает инстанс класса Юзер.
В конторе делается экшен: отдельный метод, который
- проверяет, если был запрос методом ПОСТ, то берет из него логин и пароль,
- валидирует их, если валидация не прошла, то создает ошибку, которую надо показать юзеру
- если прошла, то вызывает метод auth() модели User, передавая в него логин и пароль
- если совпали, то пишет в сессию ид юзера, и делает редирект куда-нибудь
- если не совпали, то создает ошибку, которую надо показать юзеру
- вызывает вью с формой для логина и пароля

Для регистрации делается еще один экшен, который
- проверяет, если был запрос методом ПОСТ, то берет из него данные для регистрации,
- валидирует их, если валидация не прошла, то создает ошибку, которую надо показать юзеру
- если прошла, то то заполняет класс User данными и выполняет метод save() и делает редирект куда-нибудь
- вызывает вью с формой для регистрации

Для личного кабинета делается третий экшен, который берет из сессии ид юзера, обращается к методу read() модели User и через View показывает личный кабинет

Варианты реализации

Самый простой вариант реализации контроллера - это папочка с отдельными файлами-экшенами. Ничего плохого в такой архитектуре нет, этот этап надо пройти, если раньше так не делали.

То есть папка user в которой есть, скажем, файл index.php который является экшеном личного кабинета.
Он проверяет юзера в сессии, и если нету, то перекидывает на auth.php
в auth.php есть форма и ссылочка на register.php
Все три файла инклюдят в себя файл user.php из папки model, в котором есть функции auth(), register() и profile()

Но в более классическом варианта к трем буквам MVC добавляется ещё одна - R, роутер. Специальный сервис, который разбирает адресную строку, и видя, например, что к сайту обратились по адресу /user/register, создаёт экземпляр класса UserController и вызывает его метод register()

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

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

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

Хайлоад же проекты - это из немного другой области. Тут идет откат скорее в обратном направлении. Это как с денормализацией - БД должна быть нормализована, но из соображений производительности иногда приходится денормализовывать. ПОСЛЕ того как нормализовал.
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