Артем

Артем

С нами с 15 октября 2017; Место в рейтинге пользователей: #465
Артем
12 ноября 2019, 01:39
0
т.к. предполагаю, что с этой болью сталкивались (почти) все
так и есть, все и решают ее традиционными способами: либо вы выставляете ручками везде дополнительные пробелы, либо вы погружаетесь в эту статью и вникаете в принцип работы {ignore}, чтобы понимать, где он сработает, а где нет, а затем комбинируете это с первым вариантом, либо вы пишете свой плагин, который обрабатывает нужный вам контент, ищет вхождения регуляркой и заменяет их, добавляя дополнительный пробел. Собственно, это просто автоматизированный первый вариант.
Артем
11 ноября 2019, 23:03
0
Писать плагины для решения конкретных задач — это теперь костыль?
Собственно, нравится Fenom — извольте учитывать его особенности и решать их при необходимости.
Если вы хотите, чтобы проблему решили в ядре, то вы явно не по адресу, вам сюда: github.com/fenom-template/fenom/issues
Если не нравится особенность Fenom'а, то всегда можно отказаться от него в пользу доисторических фильтров MODX.
Артем
22 октября 2019, 00:40
+2
Вполне себе уместное замечание было касаемо Shopkeeper'а. msBonus и msBonus2 связывают только общее название и не более, почему автор должен заботиться об обратной совместимости с чужим компонентом? Об этой особенности явно написано на странице компонента в modstore.
Артем
04 октября 2019, 22:10
+1
Правильно, в админке используется ExtJS — с ним и нужно работать.
Артем
18 сентября 2019, 02:43
0
1) неправильный service_url, правильный: modstore.pro/extras/
2) есть такая проблема
Артем
18 сентября 2019, 02:18
0
Честно говоря, msProductOption вообще имеет какую-то проблемную таблицу и с ним постоянно всплывают какие-то нюансы, буквально недавно наткнулся ровно на ту же проблему, напрямую получал объект msProductOption, менял значение через xPDOObject::set(), сохранял, а в таблице ничего не менялось, при этом и ошибок никаких не было, xPDOObject::save() возвращал true. Скажу даже больше, использование xPDO вместо объектов тоже не решило эту проблему, данные все так же не менялись. Вероятно, это связано с отсутствием PK в этой таблице как такового, другой причины не вижу.

Собственно, остается работать с этой таблицей только через PDO, именно так это и реализовано в методе msProductData::saveProductOptions(), который вызывается во время сохранения товара.
Артем
07 сентября 2019, 12:56
0
Эти ошибки не мешают функционированию дополнения, поэтому на них можно не обращать внимания.
Артем
03 сентября 2019, 12:59
1
+1
А еще лучше
$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);
для экономии ресурсов
Артем
16 августа 2019, 00:39
+1
{set $rows = $_modx->resource.elements | fromJSON}
{foreach $rows as $row}
    {foreach $row.show as $item}
        {$item}
    {/foreach}
{/foreach}
Артем
08 августа 2019, 14:23
0
Например, тут
Артем
12 июля 2019, 01:46
0
Спасибо за webpack, да и вообще отличную заготовку! Правда один момент неоднозначный получается: ресурсы генерируются со статическими id из массива, но что, если менеджер создал несколько новых ресурсов в админке? Получится так, что если мы вдруг надумаем добавить еще один ресурс в массив, то при следующей сборке ранее созданные ресурсы менеджером перезапишутся ввиду того, что наш пакет не знает о них. Такая же история получается при какой-нибудь выгрузке из 1C, например.
Артем
07 июня 2019, 21:19
0
А как тогда теперь задавать динамические возможные значения для тв? Неужели вешать плагин на пререндер?
Артем
27 апреля 2019, 14:51
+1
Тоже когда-то столкнулся с этой «проблемой», но на деле все просто — получить информацию о чужих заказах нельзя, только о своих.
Артем
14 марта 2019, 05:19
0
Действительно, есть такая проблема. @Володя что Вы думаете об этом?