Михаил

Старайтесь делать то, что что вам нравится)

С полного нуля. Пользователь вводит логин + пароль:
Пользователь входит через ВК

Не имеет особого значения, ваша задача полученную информацию замапать на ID пользователя в ВАШЕЙ базе, с учетом необходимых проверок. ВК будет считаться доверенной стороной, т.е. ему вы доверяете процедуру проверки аутентичности юзера. Если аутентификация на вашей стороне - то проверяете вы (проверяете пароль по соленому хешу в базе, ну или как-то еще). Если у вас "быстрый вход" по ВК (без регистрации), то нужно сделать еще авторегистрацию, если userid не найден по данным от ВК. Правда, тут нужно быть готовым, что юзер захочет слинковать свои аккаунты, если он уже зарегался по логину/паролю. Ну или хотя бы предупредить при входе по ВК, что он в базе не найден и будет создан новый акк, чтобы он не удивлялся потом.

Что писать в куки

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

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

проверять наличие сессии для данного пользователя (по ID пользователя с этапа аутентификации). Если сессия уже есть - убивать ее, создавать новую (новое устройство успешно зайдет, старое - "разлогинится"). Юзеру правда ничего не помешает скопировать идентификатор сессии из кукисов на другой девайс, так что можете еще в сессию IP писать, или user-агента (поменялся - пересоздаем сессию).

А если с нескольких?

ничего дополнительно не проверять, допусть создание любого количества сессий.

Как на каждой странице организовать проверку авторизован пользователь или нет?

идем в хранилище сессий (стандартные механизмы PHP/Redis), запрашиваем/стартуем сессию по идентификатору, пришедшему в куках. Если такой сессии нет (устарела, либо никогда и не было, идентификатор юзер сам придумал) - авторизацию не выполняем. Если сессия есть - то в зависимости от того, что мы там храним, либо достаем USERID, и пробиваем по основной БД его права, либо достаем права из самой сессии, если мы их там закешировали. "Выдача" прав - есть процедура авторизации. Теперь в зависимости от набора прав - меняем логику внутри скрипта. В больших системах применяют понятия ролей и групп - это все можно погуглить. Вкратце - при авторизации определяется, в каких группах состоит пользователь. Затем, по множеству групп сопоставляются роли, которые "играет" пользователь в системе (администратор данных/пользователей, администратор бэкапа, главбух, менеджер и т.д. и т.п.). Роли фиксированы, и зависят от логики приложения - в зависимости от имеющихся у пользователя ролей меняется и поведение приложения.
Также сейчас можно встретить claim-based подход, особенно в asp.net - тоже погуглите.

Что хранить в сессии?

Как минимум - USERID, но можно еще и закэшировать информацию о его правах, чтобы не читать постоянно ее из основной базы. Плюс, тут же хранить данные, относящиеся к САМОЙ сессии, например тот же IP входа, время входа и т.д. Тут зависит от задачи.

Есть два варианта хранения данных об авторизованном пользователе:
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), запрос простой, например получить имя пользователя, если ВК выдал что токен просрочен или ошибку, то сессию закрывать или куки с данными обнулять.

А чем API не подходит?

$page = $modx->getObject('modResource', 123);
if (!$page->setTVValue('bio', 'This is my new bio...')) {
    $modx->log(xPDO::LOG_LEVEL_ERROR, 'There was a problem saving your TV...');
}

Проект не стандартный. Скрипт сопоставления цен чего только стоит. Я имел дело с подобными проектами. Заставить это все работать без багов, дело хлопотное. Что-то поменялось в прайсе стороннего магазина и все. Сомневаюсь, что данный проект может жить без постоянного программера.Главный вопрос - получение данных от других магазинов. У них api или прайсы в csv или xml? Или парсить надо?
В зависимости от ТЗ оценил бы проект от 50 до 150k. если идея сделать, что-то типа яндекс-маркета - то надо собирать команду на гитлабе и колбасить несколько месяцев.
То что движки для этого не пригодны - факт. Надо брать фреймворк (yii2, symfony, laravel) и делать.
Думаю автор не совсем понимает, насколько это трудоемко. И тот кто возьмется это сделать за 10 - тоже не понимает.

Вы с ума сошли что ли? Какие 7к? Верстка + программирование 7к? Допустим, что на каком-нибудь несчастном опенкарте это сделать, но какие магазины? Есть ли у них АПИ нормальное или тащить самим? От 50к и выше нормальная работа стоит.

Верстануть psd, если он не сложный, найдете за 10к. Школоту не смотреть если. А то и за 500 руб сверстают.
Движок тут либо самопис(видимо вы собираетесь зарабатывать на партнерках), либо любой популярный + плагин к нему.
В любом случае, что парсер писать для 30к товаров с разных магазов, а потом импортировать стандартными средствами, что использовать апишку партнерок и импортировать сразу в базу, выйдет ну минимум 20-30к и то, многие не возьмутся.
Даже если брать минимально, такая работа от 50к начинается. А если делать все качественно - раза в 3 выше точно.
Если вам предлагают 5-7к, бегите. А, или наоборот, попробуйте, а потом отпишитесь, как оно работает)

Я уже раньше отвечал по поводу оптимизации VPS под быструю работу именно WP. Можете порыться в моих старых ответах. Но там все конечно в общих чертах. Сейчас как раз готовлю серию статей по этому поводу - от сетапа системы и пакетов, до оптимизации самого WP и кастомного кода. В принципе, могу достаточно детально проинструктировать, но писать тут сейчас такой объем лень :) Если хотите - стукните в личку (см. профиль).

Если кратко:

На shared хостинге разве что плагины кеширования, disk cache и тд. Чтобы добиться максимума, нужно:

VPS
нормально настроенная система, особенно дисковые и сетевые операции, включая tcp congestion control и прочие няшные твики
Nginx, можно с fastcgi_cache, для хардкора есть модуль для прямой работы с memcached
HHVM c фоллбеком на PHP-FPM (с opcache)
Memcached / Redis
MariaDB
WordPress
плагин/класс объектного кеширования на уровне WP
минификация и конкатенация скриптов и стилей
оптимизация изображений
грамотный код (в том числе использование объектного кеша, transients / wp_cache)
грамотное использование функционала ядра WP и архитектурные решения
и еще огромная тележка мелких нюансов

зы: такой хардкор касается не только WP но и любой другой платформы, если надо "быстро"
ззы: а еще уже вышел HTTP/2 модуль под Nginx, сейчас как раз тестирую. Шустрая штука (кстати, снимает небольшую часть задач перечисленных выше)

1. Установить nginx + php-fpm
2. Настроить в nginx выдачу всех страниц, которые генерятся в PHP через файлы
habrahabr.ru/post/124684
не кэшировать, если пользователь авторизовался или оставил комментарий через внутреннюю систему комментариев. Если комменты через Disquss, то с ними сам Disquss разберётся.
3. Подключить плагины к Wordpress, которые работают с memcached.
навскидку: Supercacher и W3 Total Cache
4. Настроить сборку всех JS и CSS в кучу, сжатие и выдачу в минифицированном виде.

Нет никаких возрастных ограничений. Физиологических нет. Могут быть психологические (и у вас сейчас есть, раз вы в 27 уже задаетесь таким вопросом), но это лечится. Мозг, как и мышци, можно и нужно тренировать постоянно, до последнего вздоха.

Думаю имеется в виду сборка аля gulp - преобразование CSS, конкатинация JS итп...

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

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

Я постоянно ищу хороших верстальщиков, только уже сменил человек 6.
Российский рынок насыщен говно-дизайнерами( -кодерами и тд) в основном от этого и качество отстой и соответственно платят меньше.

Можешь показать мне свой скилл и я смогу тебя нанять через апворк.

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

Я считаю их стоит рассматривать только в одном случае: если запретят хождение доллара или отключат swift, в остальных случаях welcome to upwork etc

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