Кажись разобрался, ситуация такая.
Были изначально созданы опции, допустим 1,2,3,4.
Созданы товары и указаны значения этих опций.
Затем созданы опции 5,6,7,8…
Так вот эти новые опции стали выводиться, даже если пустые. До тех пор пока я не прошелся по товаром и тупо их не пересохранил.
Я так понимаю, это какой баг в minishop?

А всего лишь нужно было документацию почитать или взглянуть на код pdoPage:

'pageVarKey' => 'unique',
'pageNavVar' => 'unique.nav',
'ajaxElemWrapper' => '#unique',
'ajaxElemRows' => '#unique .rows',
'ajaxElemPagination' => '#unique .pagination',
'ajaxElemLink' => '#unique .pagination a',
'ajaxElemMore' => '#unique .more',

И как полностью поменять чанк письма, задать свои стили и использовать ms2_frontend_currency вместо р?

Как вернуть старую логику работы компонента, для расчёта скидки по полю «Стоимость покупок»?

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

Ещё к позволит, смысл прокси тот же самый, что и ваша «кластерная архитектура», только без vps и ещё дешевле.

Интересно, Александр, где вы встретили ограничение запросов по ip, ведь на сколькр мне известно, там наоборот нужно указать конкретный ip с которого будут запросы, а ограничение основано на XML-лимитах, которые выдает Яндекс щас подключенные сайты в сервисе я.вебмастер.

Существует даже «рынок» этих лимитов.

Сколько раз переносили наш сборщик на новы сервер, каждый раз приходилось руками указывать его новый ip в Яндекс.XML…

А для Гугла вам по-любому понадобятся прокси или VPS или ещё что-то для подмены ip (хоть vpn), для корректного снятия позиций в разных регионах, потому что гугл плевать хотел что вы задаёте регион явно, выдача все равно идёт с учётом ip. Поправьте меня если что!

Ошибка с кодом 500 обязательно будет расшифрована в логах вебсервера. Кидайте сюда текст этой ошибки, сможем дальше подсказать!

Попробуйте копать в сторону &pageVarKey и других параметров pdoPage в которых есть слово *var* (variable).

Кажется, то что вам нужно, есть там из коробки!

Круто) Поделишься?

Вооот ещё одна странность.

Ну так теперь же всё как раз хорошо раскрыто — теперь вы можете разрабатывать дополнение, которое повторяет функциональные возможности существующих пакетов. Статья ведь про то, что ограничение сняли, теперь об этом не надо думать.

Тоже постоянно сталкиваюсь с такой проблемой.
Обычно отказываюсь от использования pdoPage и придумываю что-то сам.
Вот недавно делал такое.
В шаблоне

{set $result = '!pdoResources'|snippet:[
'parents'=>$id,
'depth'=>0,
'limit'=>3,
'includeTVs'=>'',
'tvPrefix'=>'',
'tpl'=>'@FILE tpls/oneSolution.tpl'
]}
{if $result}
<section class="current-projects-use ip-decisions-slider wrapper">
    <div class="h4 completed-projects__title">name</div>
    <ul class="completed-projects__list-slider ip-decisions__slider" id="solutionsWrapper-{$id}">
        {$result}
    </ul>
    <a href="#" class="completed-projects__order button loadDataByAjax completed-projects__order-text"
        data-parent="{$id}" data-limit="3">
       Показать больше
    </a>
</section>
{/if}

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

Есть javascript

const loadDataByAjaxs = document.querySelectorAll('.loadDataByAjax');
if (loadDataByAjaxs) {
    loadDataByAjaxs.forEach((btn) => {
        btn.addEventListener('click', async (event) => {
            event.preventDefault();
            const btn = event.target;
            const parent = btn.dataset.parent;
            const limit = btn.dataset.limit;
            const wrapper = document.querySelector(`#solutionsWrapper-${parent}`);
            const offset = wrapper.childElementCount ? wrapper.childElementCount : 3;
            console.log(wrapper.childElementCount);

            const data = new FormData();
            data.append('parent', parent);
            data.append('limit', limit);
            data.append('offset', offset);

            let response = await fetch('/core/elements/snippets/getData.php', {
                method: 'POST',
                headers: {},
                body: data
            });

            let result = await response.text();
            if (result) { wrapper.innerHTML += result; } else { btn.remove(); }
        });
    });
}

Он навешивает функцию на событие click, собирает данные о родителе, сколько загружать и высчитывает, а сколько данных уже отображено на странице, чтобы создать offset

И есть php файл

<?php
require_once 'path_to/config.core.php';
require_once MODX_CORE_PATH.'model/modx/modx.class.php';
$modx = new modX();
$modx->initialize('web');
$modx->getService('error','error.modError', '', '');
$parent = $_POST['parent'];
$limit = $_POST['limit'];
$offset = $_POST['offset'];

$output = $modx->runSnippet('pdoResources',array(
    'parents' => $parent,
    'limit'=> $limit,
    'offset'=>$offset,
    'includeTVs'=>'',
    'tvPrefix'=>'',
    'tpl'=>'oneSolution.tpl'
 ));
 echo $output; 
die();

К этому скрипту отправляет запрос javascript и получает назад html нужных элементов которые потом подставляются на страницу.
Такой способ позволяет на странице иметь сколько угодно блоков, потому что каждый из них имеет свой уникальный идентификатор, в которые информация будет погружать отдельно.

Используй pdoPage

Ну вероятно надо смотреть скрипт который возвращает данные, т.к. он скорее всего возвращает в блок с классом ajax-container. Соответственно просто скопировав блоки сделать не получится, надо править скрипт.

изначально тестировал на хроме, потом уж сафари (всё ios). Ни там ни там

Ну на самом деле вы придумываете несуществующую ситуацию.

Я бы очень поспорил с этим заявлением.
Достаточно открыть тред недельной давности и посмотреть на споры в комментах между «дублирует» и «не дублирует».
Если бы эти условия были четко прописаны, то никто не спорил.

то это явно претендент на размещение и ни у кого не будет никаких претензий.

Только об этом нигде не написано и узнать об этом можно только из комментариев к этому треду или в техподдержке, о чем я выше и говорил.
Где та грань, при которой «очевидно», а где та, при которой «спорно», а где та, при которой «всего скорее нет»?

Я даже процитирую свои слова, чтобы не повторять это снова.

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

Ну да, к сафари вопрос.

Давай будем корректны — Как бы Ios сам по себе ничего не рендерит. Это вопросы к движку браузера тогда уж.

Этим правилом решается проблема несправедливости. Всё мы понимаем, что сделать аналог какого-то дополнения будет проще, чем придумать его с нуля. И такие аналоги могут начать демпинговать — пострадает и автор, и магазин. Так что это правило защищает в первую очередь авторов. И вы как разработчик можете быть уверены, что после размещения компонента будете защищены от демпинга.

Ну на самом деле вы придумываете несуществующую ситуацию. Если дополнение включает в себя только 30% функционала «похожего» дополнения, а на 70% состоит из нового функционала, то это явно претендент на размещение и ни у кого не будет никаких претензий. У нас есть msDiscount и msPromoCode. И то, и другое — скидки, но всем абсолютно очевидно, что это разные дополнения и выполняют они разные функции разными способами.