Рекомендую попробовать ZoomX на сайте-доноре. Компонент отлично справляется с построением API как раз с json ответами, и умеет отдавать сразу файлы, если вдруг вы его будете формировать заранее.
Обмен между двумя сайтами лучше производить в формате JSON. Это общепринятая система.
Инициатором обмена может быть как одна, так и другая сторона.
Варианты, которые вижу я.
1. Изменение цены одного продукта. В этом случае запускается событие, которое отправляет API запрос на сайт на сайт-приемник. В запросе артикул продукта и цена.
2. Изменение группы цен на сайте-доноре, в результате какой-то синхронизации со складом, например. В этом случае формируется текстовый файл json формата и посылается уведомление о готовности новых данных, со ссылкой на файл. Сайт-приемник, получив уведомление запускает скрипт обработки json файла
3. Сайт-приемник, самостоятельно, по расписанию запрашивает сайт-донор. Если товаров не много — то забирает на лету сформированный json Ответ. Если товаров много, то забирает файл, подготовленный заранее.
4. Если товаров много, то можно пойти дальше. Сайт-приемник первым запросом отправляет уведомление донору и необходимости подготовить свежие данные. Затем через несколько минут (сколько там нужно временим на подготовку файла с ценами), вторым запросом забирает подготовленный файл.
В целом все крутится вокруг json файла (или массива данных) и нескольких достаточно простых API запросов.
Если отключить — то получается не смогут. Согласен здесь проблема.
Наиболее простое решение это опираться на IP адрес клиента и срывать\показывать нужные компоненты.
Но это отдельный проект. Владельцы и разработчики далеко не дураки — я думаю в конце концов придумают решение.
Возьмем к примеру компонент mSearch2 и его автодополнения в поисковой строке.
Компонент отправляет запросы к серверу, беря за основу текущий хост. Который всегда без сегментов адреса.
Сервер используя хост, получает язык контекста и отдает ответ на языке чистого хоста.
Таким образом находясь на адресе site-region3.ru/en/ сервер будет запрашивать контекст основываясь только на хосте site-region3.ru и язык ответа для поисковых запросов будет русский (ну или какой там будет основным)
И таких компонентов, которые берут за основу только хост — много. Их можно дорабатывать конечно. Просто возни больше.
Вам принципиально определять язык через сегмент адреса?
Было бы существенно проще, если бы язык шел поддоменом. en.site-region3.ru/
В текущем случае вы конечно осилите переключение языка основываясь на host + /lang/
Но останутся нерешенными проблемы внутри JS. Все ajax запросы будут улетать на базовый хост, и ответы будут приходить на базовом языке.
У вас в шаблонах, используются php методы в trim, array_merge в качестве модификаторов. В обычном режиме работы pdoTools про php методы ничего не знает. Чтобы узнал, можно попробовать включить настройку «Разрешить php в феном». Я не уверен что поможет, но попробовать можно.
Если не поможет то — либо убирать такие записи по коду шаблона, либо создать сниппеты реализующие подобный функционал.
Конкуренция не в ценовой политике же, а в функционале.
Сложновато назначать цену, если в магазине не дают продавать. Здесь неравные условия изначально.
Строго говоря, фактическим владельцем и основателем данного сообщества является modstore. Хоть владельцы проекта и не вмешиваются в его деятельность, но свои интересы просят соблюдать. Это нужно учитывать.
Мое мнение — политика монополии ни к чему хорошему не приводит. Сделал и забыл. У людей нет выбора — они покупают. Конкурирование в схожих компонентах ведет к развитию, модернизации.
Да, в оптимистичных планах думаем это решить в текущем году.
Но тут вопрос не только в Jquery — планируется полностью с нуля написать всю JS оболочку, так как та, что есть сильно отстала по времени.
Вполне себе работает. Зависать может из-за нехватки мощностей хостинга. Но сам импорт по идее должен пройти.
После перезагрузки страницы обычно все на месте
Знаешь как мне страшно в Minishop PR слать. Более того — я точно знаю, что мой код фигня полная, по сравнению с тем что делают старшие товарищи. Но это хоть какой то движ.
Здравствуйте. Нет таких планов нет. В первую очередь потому что никто не спрашивает. Вы на моей памяти первый. Мы можем обсудить этот вопрос.
Вы действительно активно пользуетесь таким компонентом?
Что нового вы ждете от компонента? Ну кроме очевидного обновления библиотеки.
Вы готовы участвовать в спонсировании обновления? Как альтернатива вы готовы видеть компонент платным и покупать его?
Вот ссылка
Инициатором обмена может быть как одна, так и другая сторона.
Варианты, которые вижу я.
1. Изменение цены одного продукта. В этом случае запускается событие, которое отправляет API запрос на сайт на сайт-приемник. В запросе артикул продукта и цена.
2. Изменение группы цен на сайте-доноре, в результате какой-то синхронизации со складом, например. В этом случае формируется текстовый файл json формата и посылается уведомление о готовности новых данных, со ссылкой на файл. Сайт-приемник, получив уведомление запускает скрипт обработки json файла
3. Сайт-приемник, самостоятельно, по расписанию запрашивает сайт-донор. Если товаров не много — то забирает на лету сформированный json Ответ. Если товаров много, то забирает файл, подготовленный заранее.
4. Если товаров много, то можно пойти дальше. Сайт-приемник первым запросом отправляет уведомление донору и необходимости подготовить свежие данные. Затем через несколько минут (сколько там нужно временим на подготовку файла с ценами), вторым запросом забирает подготовленный файл.
В целом все крутится вокруг json файла (или массива данных) и нескольких достаточно простых API запросов.
Наиболее простое решение это опираться на IP адрес клиента и срывать\показывать нужные компоненты.
Но это отдельный проект. Владельцы и разработчики далеко не дураки — я думаю в конце концов придумают решение.
Возьмем к примеру компонент mSearch2 и его автодополнения в поисковой строке.
Компонент отправляет запросы к серверу, беря за основу текущий хост. Который всегда без сегментов адреса.
Сервер используя хост, получает язык контекста и отдает ответ на языке чистого хоста.
Таким образом находясь на адресе site-region3.ru/en/ сервер будет запрашивать контекст основываясь только на хосте site-region3.ru и язык ответа для поисковых запросов будет русский (ну или какой там будет основным)
И таких компонентов, которые берут за основу только хост — много. Их можно дорабатывать конечно. Просто возни больше.
Было бы существенно проще, если бы язык шел поддоменом. en.site-region3.ru/
В текущем случае вы конечно осилите переключение языка основываясь на host + /lang/
Но останутся нерешенными проблемы внутри JS. Все ajax запросы будут улетать на базовый хост, и ответы будут приходить на базовом языке.
Если не поможет то — либо убирать такие записи по коду шаблона, либо создать сниппеты реализующие подобный функционал.
Сложновато назначать цену, если в магазине не дают продавать. Здесь неравные условия изначально.
Мое мнение — политика монополии ни к чему хорошему не приводит. Сделал и забыл. У людей нет выбора — они покупают. Конкурирование в схожих компонентах ведет к развитию, модернизации.
Но тут вопрос не только в Jquery — планируется полностью с нуля написать всю JS оболочку, так как та, что есть сильно отстала по времени.
После перезагрузки страницы обычно все на месте
Вы действительно активно пользуетесь таким компонентом?
Что нового вы ждете от компонента? Ну кроме очевидного обновления библиотеки.
Вы готовы участвовать в спонсировании обновления? Как альтернатива вы готовы видеть компонент платным и покупать его?