Здесь одно единственное правильное решение, которое давно уже было реализовано в черт его знает скольких вариантах.
1. Все домены ведут на один сайт
2. Никаких контекстов. Единый контекст с одним и тем же контентом для всех доменов
3. Плагин слушает текущий адрес сайта и в зависимости от него выставляет системную настройку «city»
4. Шаблонизатор в свою очередь слушает вышеупомянутую системную настройку и в зависимости от значения выводит нужные данные.
5. Нужно менять цены по городам? Нет ничего проще. Пишем плагин заменяем на лету цены.
6. Хотим простое управление всеми необходимыми настройками (адреса, телефоны, координаты карты) — создаем простейший компонент с табличкой «данные по городам» где ключом будет домен.
За пример такого компонента можно взять допустим changeDomain
7. Хотим чтобы контент динамично менялся. Вставляем туда вместо нужных слов плейсхолдеры, которые будут в зависимости от города подставляться
В первую очередь необходимо поменять пароли к хостингу и FTP доступ. С таким доступом считайте любой — имеет максимальные права управления сайтом.
Далее нужно сменить пароль admin (это можно сделать программно, знать первоначальный пароль не обязательно)
Ну и сменить пароль к базе mysql чтобы там не навредили.
Я сам не особо этот вопрос одолел.
Дело в том что авторизация в MODX хранится в сессии, что делает достаточно сложным вопрос опознавания юзера, который обращается к сайту по API. Это нужно идентификатор сессии получать и подписывать каждый запрос, да еще и поднимать уже существующую сессию по присланному идентификатору. Я пока не осилил.
Есть несколько путей попроще. Например jwt сессии когда все хранится на стороне клиента.
Я вот по пути Laravel обычно иду. Делаю идентификатор пользователя, подписываю им запросы и при каждом запросе авторизую пользователя. Но тут тоже есть подводные камни. Авторизацию и права нужные вы получите а вот с другими компонентами использующими сессию в работе все также проблематично пользоваться. Тем же minishop2 с его сессионной корзиной.
Можно еще написать Issue на github и мне с @Иван Бочкарев в личку. Тогда точно вопрос решится.
Ответ такой же какой и вопрос — посмотреть как это сделано в miniShop2
Ну еще например можно открыть прям главную страницу Github и написать в поиске minishop2. Не поверите — работает! На всякий случай вот вам пожалуйста ссылочка
В настройках модыкса, у поля «server_protocol» — стоит «https»?
Не вводите в заблуждение человека. Эта системная настройка не работает. Она вообще в MODX не используется нигде.
Протокол соединения формируется исключительно на основе порта подключения. Если порт 80 — то http, если 443 то — https
Да, вот уже люди поделились что давно наблюдают. А я впервые заметил.
Но также есть те, кто вчера потестировал не по подтвердил. В общем странное дело.
Я автора уведомил, теперь пусть у него голова болит.
А чем тебе корсы мешают подключиться из локалхоста к серверу?
Вроде решается же несколькими правилами. По крайней мере я не замечал какой то особой проблемы. Могу поделиться своим CORS конфигом (тоже сейчас на VUE работаю, когда админка локально, сервер удаленно)
Чет вы по-моему путаете минишоп и тикеты. Если речь идет о товарах нужно смотреть права на товары.
Для любой операции с добавлением\редактированием товаров нужно право msproduct_save
Все процедуру проверки прав происходят в соответствующем процессоре.
Например mgr/product/update
Там строку с проверкой прав можно при желании закомментировать.
А что тут заготавливать? Пишешь приложение VUE выполняющее нужный тебе функционал.
От modx там только запросы на соответствующий коннектор, плюс потом загрузка скрипта внутри админки.
Но это столь незначительно что даже твой Тезка тут об этом не пишет, рассказывая что ведет разработку локально без MODX потом просто вставляя скрипт в коннектор.
Ну а как вставить скрипт в админку MODX более подробно освещал Баха, вот тут вроде бы
А что делать с аутентификацией при каждом последующем запросе?
1. Все домены ведут на один сайт
2. Никаких контекстов. Единый контекст с одним и тем же контентом для всех доменов
3. Плагин слушает текущий адрес сайта и в зависимости от него выставляет системную настройку «city»
4. Шаблонизатор в свою очередь слушает вышеупомянутую системную настройку и в зависимости от значения выводит нужные данные.
5. Нужно менять цены по городам? Нет ничего проще. Пишем плагин заменяем на лету цены.
6. Хотим простое управление всеми необходимыми настройками (адреса, телефоны, координаты карты) — создаем простейший компонент с табличкой «данные по городам» где ключом будет домен.
За пример такого компонента можно взять допустим changeDomain
7. Хотим чтобы контент динамично менялся. Вставляем туда вместо нужных слов плейсхолдеры, которые будут в зависимости от города подставляться
Далее нужно сменить пароль admin (это можно сделать программно, знать первоначальный пароль не обязательно)
Ну и сменить пароль к базе mysql чтобы там не навредили.
Дело в том что авторизация в MODX хранится в сессии, что делает достаточно сложным вопрос опознавания юзера, который обращается к сайту по API. Это нужно идентификатор сессии получать и подписывать каждый запрос, да еще и поднимать уже существующую сессию по присланному идентификатору. Я пока не осилил.
Есть несколько путей попроще. Например jwt сессии когда все хранится на стороне клиента.
Я вот по пути Laravel обычно иду. Делаю идентификатор пользователя, подписываю им запросы и при каждом запросе авторизую пользователя. Но тут тоже есть подводные камни. Авторизацию и права нужные вы получите а вот с другими компонентами использующими сессию в работе все также проблематично пользоваться. Тем же minishop2 с его сессионной корзиной.
Вся магия в плагине на который вы ссылаетесь и модифицированном методе get класса msproduct.class.php
Через $modx->getObject(hdOrder) записи доступны?
Ответ такой же какой и вопрос — посмотреть как это сделано в miniShop2
Проще всего сменить версию движка базы
Протокол соединения формируется исключительно на основе порта подключения. Если порт 80 — то http, если 443 то — https
Но также есть те, кто вчера потестировал не по подтвердил. В общем странное дело.
Я автора уведомил, теперь пусть у него голова болит.
Вроде решается же несколькими правилами. По крайней мере я не замечал какой то особой проблемы. Могу поделиться своим CORS конфигом (тоже сейчас на VUE работаю, когда админка локально, сервер удаленно)
Для любой операции с добавлением\редактированием товаров нужно право msproduct_save
Все процедуру проверки прав происходят в соответствующем процессоре.
Например mgr/product/update
Там строку с проверкой прав можно при желании закомментировать.
От modx там только запросы на соответствующий коннектор, плюс потом загрузка скрипта внутри админки.
Но это столь незначительно что даже твой Тезка тут об этом не пишет, рассказывая что ведет разработку локально без MODX потом просто вставляя скрипт в коннектор.
Ну а как вставить скрипт в админку MODX более подробно освещал Баха, вот тут вроде бы