Василий Наумкин

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

Не надо гнать на сообщество, общайтесь с автором в специально придуманном для этого месте.

инструкции для этого можно прямо в сообществе найти.

Или даже в документации.

Всё работает, проверил с minishop2.com

I don't think that store all values in one JSON TV is good idea for filtering resource.

Maybe it would better to split it to 3 separate TVs or miniShop2 options.

You need to understand how MIGX stores data in database before you could filter it by &where.

1. Office extra requires only email for registration, all other info you can add after it in the private office. But you can change it by custom system plugin, see an example here.

2. Just as any other field in the form. After it you need to specify new field in the &userFields property of msOrder:

[[!msOrder?
    &userFields=`{"gender":"gender"}`
    &...
]]

It will bind form field gender to profile of user in MODX.

3. I believe you could manage it with javascript on frontend, or with custom system plugin for msOnBeforeCreateOrder event that will check this new field on backend.

Да, затупил.

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

Или даже использовать параметр &includeThumbs

mFilter2 have special option &paginator.

So

[[!mFilter2?
    &paginator=`pdoPageWrapper`
    &...
]]

How can I get this to work with mFilter2 Ajax mode?

Please, send all questions about paid extras to the modstore.pro support.

Меня проблемы этих сервисов как-то совсем не заботят.

Если есть огромное желание — убери вообще [contenthash:8]. и добавляй версию при подключении файла в плагине.

Для истории нужно использовать Git.

You could just wrap your call with another snippet:

[[!pdoPageWrapper?
    &parents=`0`
    &limit=`5`
]]
[[!+page.nav]]

pdoPageWrapper:

<?php

$output = $modx->runSnippet('pdoPage', $scriptProperties);

$total = $modx->getPlaceholder('page.total');
$pages = $modx->getPlaceholder('pageCount');
$page = $modx->getPlaceholder('page');

$from = (($page - 1) * $limit) + 1;
$to = (($page - 1) * $limit) + $limit;
if ($to > $total) {
    $to = $total;
}

return $output . "<p>Showing $from to $to of $total ($pages pages)</p>";

С PHP 7.3 pdoTools всё ещё не работает?

Прямо вот этот сайт прямо сейчас работает на PHP 7.3. Естественно, на pdoTools

Нет.

Можно попробовать собрать самостоятельно из исходников.

Потому что мне неохота платить 100 баксов за программу Apple Developer.

Это же не новая версия дополнения, и не факт, что автор вообще примет правки.

Какой смысл писать топик из 2х предложений здесь?

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

Прямо сейчас представил, как я сдал modstore.pro Витале с Лёней, а они там стили со скриптами в админке правят, чтобы меня не вызывать лишний раз. До слёз!

которую эти webpack / gulp совсем ни о чём не говорят, ему надо только шрифт в нескольких местах изменить, да скриптов пару поправить.

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

Скрипт сборки по умолчанию и так запускает npm run build, но процесс это небыстрый и, как правило, build.php прибивается по таймауту, если запускать его из браузера. А вот при работе в консоли такой проблемы не будет.

Если я одну библиотеку обновил, то именно она и загрузится у юзера заново, а остальные останутся в кэше.

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

App придуман именно для того, чтобы в админку вообще не заходить.