MegaMufa

"Художник должен быть голодным"

Отказаться от заказа.

Короче всё проще. Ставите Dropbox, и храните psd в каталоге dropbox'а. Оно всё синхронизирует с хранилищем, в хранилище есть контроль версий....

Есть два варианта хранения данных об авторизованном пользователе:
1) В куки (так по умолчанию используется в асп.нет): необходимые данные (claims) шифруются machineKey и отдаются пользователю в http-only куках, таким образом при каждом запросе на сервер они присылаются, расшифровываются и далее можно проверить в необходимых местах.
плюсы: полностью stateless, нет надобности обращаться к БД
минусы: при необходимости "выбить" сессию со стороны сервера нужно поднимать более сложную логику и хранить флаги в промежуточном хранилище (проверять что если для такого-то пользователя требуется завершить, то такие действия, иначе другие);
2) Ключ сессии: после успешной аутентификации авторизуем пользователя и claims храним на сервере в быстрой памяти или БД (key-value), где ключ - ключ сессии, значение - любые данные.
плюсы: есть полный контроль состоянием авторизации (как и возможность завершить сессию со стороны сервера, так и сменить пользователю роль(или другие параметры) "на лету")
минусы: организация доп. прослойки - кэша или хранение в БД (медленно), при перезапуске/падении сервиса сессии клиентам потребуется перелогиниться.

1
1.1 В куки писать или ключ сессии или шифрованные данные о пользователе, сессия - абстрактное понятие (это пара: ключ и данные), ключ должен быть защищенным, т.е. трудным к копированию (хотя бы зрительно трудно запомнить), уникальным (чтобы не возникло коллизий: двум разным пользователям выдался один и тот же ключ, т.е. это не должна быть хэш-функция от логина-пароля или IP или чего-то неуникального).
1.2 В асп.нет существуют атрибуты авторизации (в которых можно расставлять проверки на требование таковой, роль, конкретный пользователь), в общем смысле логика такова: поступил запрос на сервер, далее нужно посмотреть к какому ресурсу идёт обращение (защищенному или свободному), если ресурс защищен, то проверить куки (ключ сессии или шифрованные данные), расшифровать/получить данные о сессии из кэша и предпринять решение: пускаем или не пускаем (отдаём 401/403 или отдаем 200/404/...).
1.3 Завести на сервере (в кэше или БД) словарь , при алгоритме проверки сессии добавить условие проверки на наличие записи в словаре.
1.4 С нескольких - словаря не нужно.

2
2.1 Даже если пользователь входит через ВК всё равно нужно отдавать свои ключи сессий/шифрованные данные, а вот внутри данных уже хранить access_token от вк-шной сессии, так очень маленькая вероятность, что токен ВК утечет, а если утек ключ сессии, то действия будут ограничены только функционалом сайта.
2.2 После расшифровки куки или данных по ключу сессии делать доп запрос на сервер ВК с токеном, который сохранился при аутентификации (access_token), запрос простой, например получить имя пользователя, если ВК выдал что токен просрочен или ошибку, то сессию закрывать или куки с данными обнулять.

Less/Sass в помощь господа. Как верстал большие проекты так и буду верстать на bootstrap.

Что касается мненией "не актуален" и "bootstrap для тех кто не умеет верстать": Если вы не понимаете сути css-фреймворка как такового, то зачем писать такие мнения. И я не только про bootstrap, а про все css-фреймворки.
Когда попробуете сам фреймворк в действии, а не просто скачаете минифицированный скомпилированный css файлик, тогда поймете всю прелесть и не сможете верстать по другому.
Less/Sass это не просто css и за пару минут вы не сможете понять все прелести. Попробуйте хотя бы Less с bootstrap (он попроще Sass, хотя по моему мнению Sass интереснее и продуманнее), отключите не нужное вам, пользуйтесь "переменными", пользуйтесь миксинами, увидите что это ускорит скорость разработки в разы.
Удачи всем.

Почитайте Архитектура сервера онлайн-игры на примере Skyforge. Это конечно, не то о чем Вы спрашивали (это не учебное пособие), но думаю Вам будет интересно почитать. Лично я для себя нашел этот материал интересным.

Прямых методов нет, то ты можешь реализовать их таким образом самостоятельно

class Comment extends CActiveRecord
{
    public function setUser(\User $user = null)
    {
        if (is_null($user))
        {
            $this->user_id = null;
        } else
        {
            $this->user_id = $user->id;
        }
    }
}

$comment = new Comment;
$comment->user = $user;
// или
$comment->setUser($user);

На самом деле схема значительно более сложная, чем просто написать setter для свойства user.
Что делать, если поменять свойство user_id через которое вычисляется user - его же вроде опять надо подгрузить из базы?
Будут ли идентичными сущности $user для двух разных комментариев с одинаковым user_id?
Что делать, если $user ещё не был сохранён ? Не давать присваивать $comment->setUser($user) или делать автоматическое сохранение цепочкой (сначала $user, затем $comment) ?

Много много много вопросов.
В Yii2 такие сложности не реализованы, поскольку универсальное всеохватывающее решение как в Doctrina или PropelORM работают очень медленно и жрут память. Там как раз иногда приходится запрещать навороченную логику.

На мой взгляд по двум из причин: так исторически сложилось или так модно.

Каким то образом получилось что в рунете более популярны Backbone, Angular, а не Ember.

Думаю что в своем видении причин я более или менее прав поскольку очень редко кто при выборе фреймворка проводит полноценное сравнительное исследование.

Обычно на кого больше ссылок выдал Google, того и принимают за идеал - ведь 86% не могут ошибаться.

Вы задавали этот вопрос уже Как правильно покупать web-дизайн? и Вам там много умных людей аргументированно написали почему рисовать страницы поштучно - откровенно хреновая идея.

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

Сидят 3 хиспстера в свитерах и пьют кофе. Менеджер ищет на гитхабе что то похожее на свой будущий проект.

Сколько человек мыслит, например, над концепцией будущего проекта?

Ни сколько. Менеджер согласовывает с клиентом ТЗ и пилится сайт на основе имеющихся наработок.

За что отвечают старший дизайнер и арт-директор?

Таковых нет. Если клиента не устраивает предложенный макет, отдается заявка на фриланс.

Здесь же был вопрос про типовую веб-студию?

Никак.