Артем

По-моему, тебе тоже стоит запомнить раз и навсегда, что [[~[[*id]]]] — не id дедушки, а ссылка на текущий ресурс.

Потому что нужно использовать не modX::toPlaceholder(), а modX::setPlaceholder() — у методов разная реализация. Также можно было использовать JSON.

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

Справедливости ради, даже в американском произношении чаще можно услышать -day, чем -dee. Где-то 75/25, если в процентном соотношении.

1. Вам не знакомо понятие импорта и экспорта статических файлов?
2. Давно компоненты стали чувствительны к данным в таблицах типа site_content?
3. Стащите, кто мешает?
4. Уверен, что если компонент вам действительно нужен, то вы найдете свой собственный тестовый контент.

Вам не знакомо понятие экспорта и импорта базы данных?

т.к. предполагаю, что с этой болью сталкивались (почти) все

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

Писать плагины для решения конкретных задач — это теперь костыль?
Собственно, нравится Fenom — извольте учитывать его особенности и решать их при необходимости.
Если вы хотите, чтобы проблему решили в ядре, то вы явно не по адресу, вам сюда: github.com/fenom-template/fenom/issues
Если не нравится особенность Fenom'а, то всегда можно отказаться от него в пользу доисторических фильтров MODX.

Вполне себе уместное замечание было касаемо Shopkeeper'а. msBonus и msBonus2 связывают только общее название и не более, почему автор должен заботиться об обратной совместимости с чужим компонентом? Об этой особенности явно написано на странице компонента в modstore.

Правильно, в админке используется ExtJS — с ним и нужно работать.

1) неправильный service_url, правильный: modstore.pro/extras/
2) есть такая проблема

Честно говоря, msProductOption вообще имеет какую-то проблемную таблицу и с ним постоянно всплывают какие-то нюансы, буквально недавно наткнулся ровно на ту же проблему, напрямую получал объект msProductOption, менял значение через xPDOObject::set(), сохранял, а в таблице ничего не менялось, при этом и ошибок никаких не было, xPDOObject::save() возвращал true. Скажу даже больше, использование xPDO вместо объектов тоже не решило эту проблему, данные все так же не менялись. Вероятно, это связано с отсутствием PK в этой таблице как такового, другой причины не вижу.

Собственно, остается работать с этой таблицей только через PDO, именно так это и реализовано в методе msProductData::saveProductOptions(), который вызывается во время сохранения товара.

Эти ошибки не мешают функционированию дополнения, поэтому на них можно не обращать внимания.

А еще лучше

$ids = [];
$c = $modx->newQuery('msCategory', [
    'pagetitle' => $modx->resource->pagetitle,
    'id:!=' => $modx->resource->id,
]);
$c->select(['id']);
if ($c->prepare() && $c->stmt->execute()) {
    $ids = $c->stmt->fetchAll(PDO::FETCH_COLUMN);
}

return implode(',', $ids);

для экономии ресурсов

{set $rows = $_modx->resource.elements | fromJSON}
{foreach $rows as $row}
    {foreach $row.show as $item}
        {$item}
    {/foreach}
{/foreach}

Например, тут

Спасибо за webpack, да и вообще отличную заготовку! Правда один момент неоднозначный получается: ресурсы генерируются со статическими id из массива, но что, если менеджер создал несколько новых ресурсов в админке? Получится так, что если мы вдруг надумаем добавить еще один ресурс в массив, то при следующей сборке ранее созданные ресурсы менеджером перезапишутся ввиду того, что наш пакет не знает о них. Такая же история получается при какой-нибудь выгрузке из 1C, например.

А как тогда теперь задавать динамические возможные значения для тв? Неужели вешать плагин на пререндер?

Тоже когда-то столкнулся с этой «проблемой», но на деле все просто — получить информацию о чужих заказах нельзя, только о своих.

Действительно, есть такая проблема. @Володя что Вы думаете об этом?