Денис

Форма наследуется от RegistrationForm, следовательно rules будут наследоваться от этой модели и валидироваться во view исходя от этих rules. Когда вы в контроллере вызываете метод save(), срабатывает сохранение модели User, и валидация происходит через rules этой модели.

Можете писать rules только в RegistrationForm, но тогда в другом месте вы не сможете использовать модель User напрямую, т.к. валидация внутри не прописана.

Доброй ночи.
Вы наследуете RegistrationForm от Model и поэтому можете прописать в ней свои правила валидации, не привязанные к модели User.
Это будет более правильней и не надо будет заморачиваться с сценариями.
Сценарии понадобятся в том случае, например, если Вы захотите сделать отдельную модель User для админки. Тогда да, понадобятся сценарии.

p.s. Посмотрите модель SignupForm в шаблоне advanced, никакие сценарии там не используются. Они в данном случае лишние.

а почему бы не заменить
$user->getPrimaryKey();
на
$user->id;//где id это и есть Ваш primary key
и не плохо бы выложить код модели Token, почему в ней могут проблемы сохранения....

Это нормально, потому что вставка использует число из последовательности автоинкремента.
Например, транзакция включает два запроса: легкий и очень нагруженный.
Первый вставляет запись и получает её айди, например, 13, который используется во втором запросе.
В тот момент, когда начал выполняться второй запрос, могла произойти вставка в таблицу, в которую добавлялась запись первым запросом.
Если бы эта конкурирующая вставка использовала "незанятый" айди 13, по которому записи ещё "как бы" не существует, то возникла бы коллизия, когда тяжёлый запрос выполнится: он уже использовал айди 13, но по факту этот айди принадлежит другой записи. Плюс, непонятно, куда коммитить первую запись из транзакции.

На средние. Где то и высокие будут играбельны. Памяти хватит, а вот видеопроцессор слабее топовых 1070 и 1080. Ну и что за вопросы, возьмите да посмотрите.
Многое зависит от того, что для вас комфортно. Я вот люблю скоростные шутаны и остро ощущаю разницу между 60 и 40 фпс, а лет 5 назад 40 считал приемлемой величиной. Кому-то и сейчас 30 - комфортно вполне, тем более если это не очень динамичная игра. Поэтому исходя из ваших определений комфортной игры смотрите на выдаваемый фпс в тех или иных играх и делайте выводы.

А не обязательно оборачивать в .container

Просто вложи в обычный див, например, и он по дефолту растянется на 100% экрана. Колоночки будут хорошо работать в нем безо всяки конейреров и флюидов.

Вы можете из метода registration вернуть user_id. ID у AR объекта вызывается после сохранения. Т.е:

if($user->save()){
    return $user->id;
}
return null;

сделайте роли "ban", "confirmedUser" и раздавайте. Это удобнее, чем отдельный статус, потому как контроль доступа весь через rbac и не надо доп велосипеды делать.

По умолчанию будет взят пакет с большей версией. А вообще, можно управлять тем, откуда что ставится, назначать приоритет репозиториев, указывать в вызове apt конкретную версию пакета и.т.п. Вот хорошее пояснение на английском, правда: https://gist.github.com/JPvRiel/8ae81e21ce6397a050...

& - это элемент родитель к которому применяеться псевдокласс, можно так же писать и полное имя родителя.
Вот пример с хабра.

.parent {
    position: absolute;  
    &:before {
        height: 100%;
        display: inline-block;
        vertical-align: middle;
        content: '';
    }
}

Он же без &, а с полным именем родителя.

.parent {
    position: absolute;  
}
.parent:before {
        height: 100%;
        display: inline-block;
        vertical-align: middle;
        content: '';
}

Хорошая либа, можно настроить скорость каждого отдельного блока
markdalgleish.com/projects/stellar.js

Вы знаете величину скролла (допустим проскроллили на 100 пикселей), далее вы должны сместить изображение на эту величину в противоположном направлении. Каждый слой должен иметь некий коэффициент смещения. Чем ближе слой к наблюдателю (т.е. чем больше его z-index), тем больше коэффициент (но не более 1).

Например:
слой 1 (звёзды - самый дальний от нас): смещение = 100 * 0,3
слой 2 (планеты): смещение = 100 * 0,6
слой 3 (ракета): смещение = 100 * 0,9

Крутим вниз, смещаем вверх. Я коэффициенты подобрал от балды (1 / 3 ~= 0,3), с ними можно поэкспериментировать.

Для png и jpg лучший вариант - gulp-tinypng, работающий через api tinypng. По качеству он на порядок превосходит всех конкурентов. Бесплатно 500 изображений в месяц, больше - $0.009 за изображение.
В качестве альтернативы есть kraken. ($9 за 2GB), качество чуть ниже, но тоже отличное.
Полностью локальные решения от их качества далеки безумно. Но если рассматривать такие варианты - иногда использую gulp-image-optimization, это немного переработанный всем известный gulp-imagemin.

По поводу

не копирует/оптимизирует не одно изображение

Дело не в плагинах. Вероятно, это вы что-то делаете не так.

Лично у меня галп настроен таким образом:
Собирает файлы по частям и обфусцирует в один или несколько в зависимости от того, где они нужны. При этом ты можешь проводить тесты. Так что полностью поддерживаю vvvadimos и Wheelie.

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

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

Как я понял предполагается инжекция css + js в результирующий html.

Смысла я в этом не вижу. Сжатие и объединение файлов полезно для уменьшения количества запросов и уменьшения размера. И сохраняется возможность его брать из кэша, при повторном обращении.
Если у вас на всех страницах он будет в теле страницы, то этот объём будет каждый раз загружаться.

Если у вас single-page application, то тут по сути можно и так сделать, но зачем не нахожу плюсов.
Сейчас есть http2/spdy и можно вообще хоть и немного но расслабиться.

А так в целом, gulp и сжатие отдельно css вендоров и свои, js вендоров и свои.
Свои собираете когда что-то правите, файлы вендоров когда обновляются библиотеки.
Некоторые библиотеки(jQuery) рекомендуется брать из общих CDN, есть большая вероятность что они уже будут в кэше и по сути все будет моментально.