Янис

Ок, русский вариант документации поправил. И насколько я понял, английской версии почти нет.

Создал issue

Нашёл я причину, почему заказы от разных пользователей будут приходить на одного, совершенно другого пользователя. Браузер не при чём.
Итак, выдержка из документации miniShop2 Службы->Логика работы: «Получаем id юзера, по указанному email. Если такого юзера нет, то регистрируем его со случайным паролем и заносим в группы, указанные в настройке ms2_order_user_groups.»
Это не так. Выдержка из minishop2.class.php, строка 612, создание фильтра для поиска юзера

$filter = array('username' => $email, 'OR:Profile.email:=' => $email);
if (!empty($phone)) {
  $filter['OR:Profile.mobilephone:='] = $phone;
}

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

У тестового сайта срок закончился. Но я успел провести ещё кучу тестов и нашёл проблему. Чтобы не быть голословным, вот скрин из заказа, слева адрес, что был указан в заказе, справа — пользователь, на кого miniShop2 офрмил заказ (это сделано много позже первых тестов, просто чтобы не запутаться):

Регистрации на сайте нет, но где-то, как-то оставалась сессия (хотя в ходе тестов я удалял кукис сайта и закрывал все сессии из админки). Так вот у меня глючили все три браузера через которые я делал тесты. Проблема была именно в них. Поэтому я и не мог сразу найти проблему, а грешил на miniShop2. После очистки историй, кукис и всех сохранений всё заработало как надо.

Подтверждаю. Тогда я ничего не понимаю. Какой бы я браузер не использовал, получается сделать корректно только первый заказ. Проблема с провайдером? Есть ещё люди кто может сделать два заказа?

Поставил: http://s22959.h10.modhost.pro/
Те же яйца, вид сбоку. Первая покупка ОК, а следующие уходят первому.

Не понял. inputOptionvalues при таком составлении значений «color==#000» левую часть (имя) показывает в админке, а правую (значение) выносит во фронт. Просто поменяй местами имя и значение, и будет тебе счастье. В крайнем случае можно значение убрать и оставить только имена «vk||boom||yandex», тогда везде будет одно и тоже и в админке и на фронте.

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

В чанке только один плейсхолдер [[+cultureKey]]? Сессии пользователей пробовал сбросить?

Иногда случается, что после правок системных настроек Вавилон не отображает значок перевода на фронтенде, хотя у вас связка ресурсов есть. Это из-за сессии. Поэтому после изменения настроек принудительно завершаем все сеансы.

В статье, в самом конце я указал:

Чтобы было видно текущий язык, надо вызов оформить так:

[[BabelLinks? &tpl=`BabelLinksTpl` &showCurrent=`1`]]

Я же написал, для него действуют другие правила. К контекстам указанным в списке будет получен уровень доступа «Контекст», а для mgr это не нужно. Как это отразиться на работе админки, я не вижу смысла испытывать. Ведь нет никакой гарантии, что в следующих версиях MODXа это не вылезет боком, после чего редакторы начнут в панике присылать письма, что всё пропало. Пример: изменения в версии 2.5.7

Вашу статью не видел. Но разница не только в источниках. Например, у вас допущена ошибка при создании группы. В списке контекстов «mgr» быть не должно, для него действуют другие правила. В тоже время я не додумался сделать комментарии к каждому пункту политики. Мне показалось, что описание пунктов политики в редакторе политики вполне достаточным.

> Все равно у новичков будут вопросы из разряда «а как дать такой-то доступ или как закрыть?»,
Да, мне стоит дописать про редактирование пунктов политики. Собственно сейчас этим и займусь.

Можно купить, а можно самому настроить. Скоро вторая статья будет, как всё это организовать

Увы, встречаются такие персонажи. Поэтому и захотелось написать инструкцию для новичков, как разнести текст и код.

Идея в том, что администранор не видит код вообще. Чтобы это работало, для начала всё выносим из контента в шаблоны / чанки, а затем через ACL (в начале статьи упомянул, но похоже невнятно) делаем редакторскую группу, чтобы участники этой группы, видели только то, что им положено.

Ну совсем азы MODXа. В шаблоне поставить проверку на авторизацию, по результату или подключаем блок со скриптом или нет. Если проверка на Fenom, то сюда. Если стандарный парсер, то сюда

Или сделать ресурс и написать для него шаблон (если в ответе должен быть текст) или указать путь до php файла и инициализировать в нём MODX. Здесь документация.

Проблема в лимите. И там и там это параметр «limit». Стоит modInstagram пересохранить под другим именем и изменить в нём имя параметра, чтобы они не пересекались. И пробовать. И про cacheTime не забыть, иначе не заработает как надо.

И каков результат?
P.S. Сниппет работает через pdoTools и класса у него нет, так что модель не нужна, только element. И всё должно работать

pdoPage.