Михаил

1 используйте API, которые есть в WP
запрос на сторонний сервер правильнее сделать с помощью через HTTP API
https://codex.wordpress.org/HTTP_API

2 правильно писать так, как вам и другим разработчикам будет позже удобнее работать с кодом
> использовать классы или же просто функциями
вопрос из разряда "что лучше - табуляция или пробелы". используйте тот подход, которым вы владеете в большей степени.

если идей, как организовать плагин нет, скачайте любой из гугла по "wp plugin boilerplate".
чего-то особо уникального там нет, подход везде примерно одинаковый.
отличаются названием функций/классов, путями и названием папок

>Как правильно это организовать, чтобы только после получения данных срабатывал шорткод?
в функции шорткода пропишите условие,
если данные есть - показывать, если нет - не показывать

Чувак, у тебя надуманная проблема, которая тем не менее ввергает тебя в страх и наводит на тебя оцепенение. Решается просто - когда у тебя появляется понимание того, что тебе не хватает знаний в какой-то области - надо садиться и учить это. Может сейчас тебе кажется, что сделать сайт на вордпрессе очень сложно, тем более что сейчас тебе наговорили, что для этого надо дизайнера, сеошника, фронт/бэкэндера и админа впридачу - не слушай. Это другой уровень проектов, которыми ты займешься тогда, когда это тебе потребуется, сейчас тебе нужно:
Cео - изучить рекомендации от яндекса - https://yandex.ru/support/webmaster/recommendation... - тебе этого хватит, а если кто-то попросит продвигать его сайт - просто скажешь, что ты программист и этим не занимаешься.
Дизайн - на тостере поискать вопросы "где взять бесплатные качественные шаблоны". Вообще мне лично заказчики сами предоставляют макеты дизайна, либо я рекомендую им знакомых дизайнеров. На худой конец можно взять шаблон с тимфореста, но тут заказчик должен решать, шаблон или уникальный дизайн он хочет. Также неплохо бы слепить из пары этих шаблонов примеры для портфолио, чтобы заказчик имел представление, какого уровня дизайн будет, если он решит использовать шаблоны.
Администратор - блин, да бросьте, вордпресс на хостинг поставить, для этого уже нужен администратор? Если раньше ты имел дело с движками, то наверное как-то ставил сайты, если нет - научишься. Вбить в конфиги вордпресса или опенкарта параметры для доступа к базе и настроить там же пути - для этого не нужен администратор.
Фронтэнд - бэкэнд - да, тут надо заниматься. В твоем случае надо учить php (вордпресс, опенкарт и все остальное написано именно на нем). Ну а как ты хотел, ты ж фрилансер, тебе по роду деятельности надо будет постоянно совершенствовать свои знания :) Но тут есть свои плюсы - это интересно! А через какое-то время наверное ты даже специализацию выберешь себе и волне возможно с php перейдешь на другой язык, который тебе будет больше нравиться (go? nodejs?). Если не хочется обучаться программированию - тогда дорога в дизайнеры, это тоже прикольно. Либо раз у тебя есть знания js - в контору на фронтэндера, но для этого тебе дополнительно нужно будет посмотреть на backbone и angular.

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

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

Это вопрос вёрстки, а не CMS.

Для карт используйте leafletjs.com. Внутри можете использовать кастомные карты + добавлять объекты на них. Есть богатый выбор плагинов, может найдете что под себя: leafletjs.com/plugins.html

я делаю так
верстаю с sass, в файле main.scss добавляю такое:

.projectPrefix{
@import
	"_normalize",
	"modules/_layout",
	"modules/_editor",
	"modules/_general",
	"vendor/_wbbtheme",
...
}

получается, что все стили у меня идут как .projectPrefix div{}, .projectPrefix .title{} и тп.
соответственно, вывод плагина нужно обернуть в div.projectPrefix.

для основной массы задач этого бывает достаточно

Ответ asd111 шикарен, от себя добавлю:

- WordPress, на котором работает 24% всего тырнета - переписанный форк другой платформы, одним человеком - Matt Mullenweg
- Sublime Text - изначально написан одним Jon Skinner, да и сейчас большую часть он пилит
- John Carmack, автор движка для таких легендарных игр как Doom, Wolfenstein, Quake
- Тим Бернерс-Ли, кагбэ - HTML, URI, URL, HTTP и много чего еще. Википедия
- Richard M. Stallman - Emacs, gcc
- Bill Joy - vi, rlogin, rsh, rcp, TCP/IP стек для BSD
- John Resig - jQuery
- Larry Wall - Perl
- Anders Hejlsberg - Turbo Pascal, Delphi, C# (и частично .NET)
- Bram Cohen - BitTorrent, который дает ~50% всего трафика сейчас
- Yukihiro Matsumoto - Ruby
- Sid Meier - любимые многими игры Civilization, как минимум
- Phil Zimmermann - PGP
- John Backus - Fortran
- Jon Van Caneghem - разработал первую из серии Might and Magic
- Bram Moolenaar - VIM
- Joe Hewitt - Firebug, DOM Inspector
- Simon Tatham - PuTTY
- Shawn Fanning - Napster
- Markus Persson (Notch) - Minecraft
- Cleve Moler - MATLAB
- Will Wright - SimCity
- D. Richard Hipp - SQLite, Michael Widenius + David Axmark - вдвоем, MySQL, а mSQL из которого все пошло (с некоторыми оговорками), написал David Hughes. В свою очередь, сам SQL, основа всех и вся, хоть и был создан в IBM, написали его тоже всего 2 человека - Donald D. Chamberlin и Raymond F. Boyce
- Eugene Roshal - Far, RAR формат, WinRAR
- Rich Hickey - Clojure
- Tim Sweeney - еще один игровой движок, Unreal Engine (точно знаю, что он в одиночку пилил 1ю и 4ю версию движка, по остальным инфы нет, но думаю тоже)
- Austin Meyer - X-Plane
- Justin Frankel - создатель Winamp and Gnutella, первой P2P
- Charles Simonyi - первые Microsoft Word и Excel
- Allan Odgaard - TextMate
- Andrew Tridgell - rsync, samba
- Jeff Atwood, Joel Spolsky - StackOverflow

и еще тысячи таких людей по всему миру.

ЗЫ: Пруфы не линковал - гугл и вики подтвердят.

Multisite решит вопрос. Каждый сайт может иметь свой магазин, на то они и автономные сайты сети.

Недавно написал книгу о том как начать бизнес с нуля и начать по-настощему зарабатывать.
Книгу можно скачать бесплатно: solodukha.com/thebook

Коротко о себе:
- Стартовал 8 бизнесов, из них 4 по продаже оборудования. Все были без физического офиса, без физического склада. Последний раз вообще сотрудники были на удаленке.
Рекорд: вывод компании за 2 месяца на оборот $250'000 в месяц при средней доходности 25-30%
- В один из своих бизнесов привлек инвесторский займ в размере 5 млн. руб.
- Разработали продал инвестиционный Проект с объемом инвестиций в 1,2 млрд Евро

Готов помочь

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

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

Не имеет особого значения, ваша задача полученную информацию замапать на 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к и выше нормальная работа стоит.