FernandoErrNando

Зачем отключать? Он что где-то сам по себе всегда работает?) Просто не используйте нигде view()

Есть несколько вариантов решения это проблемы.

1) Некоторые могут пропагандировать сервисный слой (design-pattern.ru/patterns/service-layer.html), как следствие: "App/Services/ServiceName" - набор классов, отвечающих за какое-то абстрактное действие. Например: "UserAvatarUploaderService", который отвечает за загрузку аватарки пользователя.

2) В качестве альтернативы и способ, который предпочитаю я - это создание директории "src" с набором независимых компонентов, включая собственный composer.json. Тот же сервис загрузки аватарки будет выглядеть следующим образом:

- src/
    - AvatarUploader/
        - README.md
        - composer.json
        - tests/ ...
        - src/
            - AvatarInterface.php
            - FileSystemInterface.php
            - FileSystemUploader.php
            - UploaderInterface.php

Для подключения этой библиотеки достаточно будет прописать в корневом:

{
    "repositories": [
        {
            "type": "path",
            "url": "./src/AvatarUploader"
        }
    ],
    "require": {
        "app/avatar-uploader": "*"
    }
}

А выглядеть внутренний (т.е. внутри "src/AvatarUploader") composer будет так:

{
    "name": "app/avatar-uploader",
    "autoload": {
        "psr-4": {
            "AvatarUploader\\": "src/"
        }
    }
}

Таким образом мы запилим совершенно независимый компонент со своими тестами и зависимостями, а внутри основного приложения будем лишь к нему обращаться.

Да, самый простой вариант, это:
Пользователь отправляет нам на сервер логин+пароль.
Сервер сверяет с данными в БД, если всё хорошо, то генерирует большую случайную строку(Токен), которую добавляет как запись в БД (UserID, Token), после этого отправляет клиенту токен, чтоб тот установил у себя его в куки (заголовок Set-Cookie).
Теперь браузер клиента на каждый запрос будет отсылать на сервер куку и мы можем, обращаясь к БД на поиск строки из куки, получать данные о пользователе.
Но так как хранение в БД не всегда эффективно, токены хранят иногда в быстрых БД, таких как Redis или MemCached.

По поводу сессии:
Иногда, чтоб не ходить в главную БД на каждый запрос, некоторые данные выносят из главной БД(В тот же Redis, MemCached или даже просто в файл на диске с именем токена). Просто теперь, хранится не только токен, но и по имени токена сразу же получают некоторые данные, например, что у пользователя ID=42 и что он администратор.

Через какое то время удалять?

День, неделя, несколько часов, зависит от задачи.
Например, некоторые сайты хранят сессию сутки, но если нажать галочку "Запомнить меня", то срок может увеличится до недели или месяца.
Сервисы оперирующие с деньгами или чем-то, что может представлять ценность, делают сессии от 10 минут.

https://dev.mysql.com/doc/refman/8.0/en/spatial-fu...
https://dev.mysql.com/doc/refman/8.0/en/creating-s...

О. обожаю этот вопрос!

Открою секрет - IT само по себе бесполезно. Как, например и логистика/грузоперевозки. Или охрана.
IT должно облегчать другие сферы жизни. Программист должен писать что то, облегчающее другие сферы жизни.
Обязательно надо в чём то разбираться:

• бизнес/магазин - разбирайся с логикой заказов/покупок/возвратов
  
• банк - логика движения, денег, валют, транзакций, проверок, откатов
  
• движок игры - разбирайся с физикой. магнитизм, механика, свет/тень - все эти жизненные законы надо оцифровывать.
  
• игра на готовом движке - тогда закапывайся в детали, какого размера ступеньки должны быть что бы соответствовать шагу игрока с учетом его скорости передвижения. здесь требования не таки сложные, но вот игра без таких деталей будет казаться г**ном
  
• драйвера - разбирайся в железе, какую нагрузку держат - температура как повышается, сколько микроват где бегает.
  
• МАШИННОЕ ОБУЧЕНИЕ???????? Это вообще жесть как надо миллион тематических свойств изучить чтобы заложить обучение. И эксперты области редко понимают чё тебе надо
  
• data engeneer - вообще не область. Но даже тут надо понимать какие данные надо хранить/обрабатывать и с какой вероятностью нужны будут правки.
  
• роботы - опять же физика движений во всех проявлениях
  
• ИИ - психология, лингвистика.
  
• парсинг текстов - опять же, лингвистика, еще и разных языков, грамматика, синтаксис. а может и стилистику языков надо учитывать
  
• ...и т.д.
  

И так со всем.
Да, программисту будут ставить задачи, может даже детальные. Но всё равно он последняя инстанция - до него что то могли не продумать - программист ошибку увидит сразу и должен отреагировать. Предотвратить что то или увидеть возможности для прикладного...

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

Эти функции - какой-то ужас, летящий на крыльях ночи. mysql_real_escape_string - вообще за гранью добра и зла.

Но главное, что я не могу понять - это какое отношение к mysql и mssql имеет функция xss_clean. Ну то есть я даже представить себе не могу, как можно функцию для защиты от xss применять для любых манипуляций c SQL. Это - я не знаю - как положить деньги в презерватив от грабителей. Он же служит для безопасности. Ну вот деньги и будут в безопасности.

По теме: ради всего святого, используйте PDO с подготовленными выражениями. Это сделает ненужной всю эту мышиную возню с регулярками. PDO поддерживает как mysql, так и mssql, так что разница будет только в синтаксисе запросов, а сам код работы с запросами будет один и тот же

$sql = "SELECT TOP 10 * FROM user where mssql.department_id=?";  
$stmt = $conn->prepare($sql);  
$stmt->execute([$_GET['department_id']]); 
$users = $stmt->fetchAll();

$sql = "SELECT * FROM user where mysql.department_id=? LIMIT 10";  
$stmt = $conn->prepare($sql);  
$stmt->execute([$_GET['department_id']]); 
$users = $stmt->fetchAll();

Как можно заметить, в запросах нет ни одной кавычки вообще, что делает сам вопрос про замену бессмысленным.

От XSS же надо защищаться совсем в другом месте, и также без всего этого ужаса

Нет.

Для этих целей можно использовать библиотеки бесплатных картинок.
Или фотостоки (купить там или у них есть бесплатные "фото дня" или даже целые разделы бесплатного).

Отвечает за те зависимости, которые необходимы только для dev-окружения.
К примеру, Вы точно знаете, что библиотека phpunit нужна для разработки, а на проде будет лишней, тогда phpunit попадает в require-dev.
Когда выполняется простой

composer install

устанавливаются и dev-зависимости.
Когда выполняется

composer install --no-dev

устанавливаются только те зависимости, что в основном блоке require.

Источник

Это Route Model Binding.

Customizing The Key Name
If you would like model binding to use a database column other than id when retrieving a given model class, you may override the getRouteKeyName method on the Eloquent model:

/**
 * Get the route key for the model.
 *
 * @return string
 */
public function getRouteKeyName()
{
    return 'slug';
}

F5

могу вручную делать return в каждом методе своего API, но это не выглядит правильным

Почему? Это нормальная практика. Каждый метод - это часть контроллера, а контроллер должен возвращать ответ. Ответ в Laravel должен быть инстансом Response (массив автоматически конвертируется в него).

если структура изменится, мне придется менять весь свой код

Для таких случаев Лара предоставляет возможность создать свой собственный тип ответа, например, ApiResponse. Соответственно, после создания будете вызывать в коде как-то так:
return response()->api($code, $data);
Все форматирование будете делать в классе ApiResponse.

Собственно, чтобы создать, регистрируете в сервис-провайдере новый тип response.

Response::macro('api', function ($code, $data) {
    return new ApiResponse($code, $data);
});

В первую очередь при возникновении такого вопроса стоит поинтересоваться - а зачем это вообще делать?

Но оставим этот вопрос висеть в воздухе, ответим на заданные.

Скажите, есть ли смысл запихивать весть сайт в pjax?Используют ли вообще так pjax или он больше для других целей?

Конкретно в pjax - нет. Yiiшный pjax это инструмент для оборачивания одного виджета для обеспечения его работы по ajax. Это даже по полному имени класса заметно - yii\widgets\Pjax Т.е чтобы весь сайт работал через pjax - нужно извратиться и сделать его весь - одним виджетом, пусть и со встроенными в него другими. Роутинг такого виджета станет вашим начным кошмаром, потому что стоковый Yiiшный к такому не готов - да и не должен

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

Если вам ехать, а не шашечки, то чтобы сделать Single page application используйте технологию для этого подходящую. React, Angular, Vue - весь мир современного фронтенда к вашим услугам. Да, не получится сделать это штатными средствами Yii, и не прокачаетесь в Pjax, но зато получите опыт написания Api на Yii (с которым будет работать SPA) и полноценного фронтенда.

1. Выделить одну главную функцию сервиса
2. Сделать её, сверстать и выкатить, это будет MVP
3. Не заморачиваться с вёрсткой
4. Не заморачиваться с методами авторизации
5. Не думать про нагрузку, не заниматься оптимизацией кода и БД
6. Если поймали себя на мысли что вы думаете какой паттерн тут применить вы в Ж, просто пишите код, который работает!!
7. Не совмещать написание сервиса, который вы РЕАЛЬНО хотите запустить с изучением чего-то нового (языка, БД). Утоните в учёбе и никогда не запустите.

Это всё на своём опыте написания проекта говорю вам а не голословно ))

Обернуть все роуты в Route::group(["prefix" => "test_prefix"])