Артем

Если твой сторонний сервис не предоставляет никаких TTL (время жизни цены) или любой другой информации, по которой можно отследить ее актуальность, то у тебя есть 2 пути:
— либо ты делаешь запрос каждый раз, когда нужно узнать цену
— либо ты кэшируешь ее на любое время, которое считаешь нужным.
В первом случае клиенты твоего сайта получат всегда актуальные цены перед глазами, а во втором — нет, поэтому тебе нужно будет принудительно запрашивать цену перед, например, оформлением заказа, ну и уведомлять клиента о том, если она изменилась за это время.

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

Лично мне вариант с сокетами кажется наиболее разумным решением — клиенты всегда видят актуальные цены, не нужно слать по 150 запросов в секунду, все довольны.

Что в логах?

В чанк с темплейтом «openGraph_Img» подставил Вашу строку и страницы, у которых к новости есть картинка перестали загружаться.

Ты всего скорее скопировал с неверными кавычками — тут они заменяются на «елочки», а такое в Fenom не сработает.

Если уж ты решил перейти на Fenom, то имеет смысл переписать эту конструкцию целиком. Сверху в head пишешь:

{set $data = $_modx->resource.image | fromJSON}

а затем просто

{set $image = $data ? $data[0].image : 'images/defaultPic.jpg'}
<meta property="og:image" content="{'site_url' | option}{$image}">

И никаких дополнительных openGraph_Img не нужно.

MIGX TV — это не более чем простой JSON, поэтому в Fenom с ним можно работать без всяких getImageList.
Ты можешь распечатать $data на странице и посмотреть, что там внутри:

{$data | print}

Закинул issue

В общем, это баг miniShop2, в последних версиях отрефакторили процессор получения заказов и чего-то намудрили с выборкой. Во-первых, зачем-то используется название поля customer вместо fullname, которое указано в схеме таблицы. Во-вторых, именно по этой причине выборка ломается, потому что поля customer в таблице нет, а альяс для него не указан.
Быстрое решение в 1 строку — заменить эту строку на

$q->query['columns'] = ['SQL_CALC_FOUND_ROWS msOrder.id, fullname as customer'];

Теперь для fullname есть альяс и выборка ломаться не будет.
А по-хорошему надо это нормально отрефакторить.
Попозже закину issue или PR.

(ERROR @ /home/i/papka/site.ru/public_html/core/components/pdotools/vendor/fenom/fenom/src/Fenom/Template.php(487): eval()'d code: 47)

это не имеет отношения к проблеме, это в каком-то из твоих шаблонов ворнинг

(ERROR @ /home/i/papka/site.ru/public_html/core/components/minishop2/processors/mgr/product/getlist.class.php: 240) PHP warning: count():

а вот такого быть не должно — стоит заглянуть в процессор и посмотреть, почему там в count прилетает неверная переменная

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

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

ну так в чем проблема додумать самому и заменить sendEmail на то, что тебе нужно?
или ты хочешь готовый код, чтобы копипастом себе его вставить?

Ещё раз повторю, ты просто не вник в механизм «скрипки».

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

Он без проблем справится с любыми задачами.

Правда?
Задача: вывести массив товаров, у каждого товара 3 поля — id, sizes, pictures. Каждые 3 итерации меняется класс товара. Сначала 'a', потом 'b', потом 'c', потом по новой. Если есть размер 50, то товар получает класс 'xl', если же 50 нет, но есть 48, то 'l', в противном случае 'm'. В массиве 'pictures' содержится 2 поля — image & thumb. Если thumb нет, то нужно вывести image.

На вход получаешь один массив со всеми товарами.

{set $classes = ['a', 'b', 'c']}
{foreach $products as $product}
    {set $index = $product@index / 3 % 3}
    {set $size = (50 | in : $product.size) ? 'xl' : ((48 | in : $product.size) ? 'l' : 'm')}
    <li class="product {$classes[$index]} {$size}">
        <img src="{$product.thumb ?: $product.image}">
        Product #{$product.id}
    </li>
{/foreach}

Покажи, пожалуйста, альтернативное решение без проблем. Разумеется, без Fenom.

Был бы ещё один шаблонизатор похожий на другие, но в отличие от них (универсальных), он использовался бы только в MODX.

Почему? Smarty используется вне modx? Да. Fenom используется вне modx? Да.
Можно было бы написать некий аналог Fenom, но с некоторыми крутыми фичами, которые работали бы только в modx.

Тот же Fenom заставляют работать в парадигме шаблонизации MODX, а у него другая логика.

Тут согласен, да. Чего только стоят issue в репе Fenom о том, что ignore не работает в modx.

Если тебе гитара нравится больше, чем скрипка, это ещё не значит, что скрипка не музыкальный инструмент.

Так это не мне больше нравится, это вполне объективные вещи, с которыми трудно поспорить.
На данный момент родной «шаблонизатор» в modx просто нельзя назвать шаблонизатором — он не справляется с большинством типовых задач шаблонизации, это же очевидно.

Она реально лаконичнее.

Лаконичнее в нем только вызов тегов — тут согласен. Но в реальных сценариях никто не вызывает просто теги, практически всегда требуется дополнительная обработка. А когда ты пишешь сниппет «If», то это уже не кажется таким лаконичным.

Я в своё время экспериментировал

Да, вот если бы в нем был такой функционал, то это был бы полноценный шаблонизатор, со своими фичами и идеей, и это было бы круто.

Проясню, что все негодование связано с тем, что текущий вариант шаблонизации в modx без использования Fenom приносит исключительно боль и страдания.

Как, к примеру, вывести TV или id текущего ресурса через |?

Все это доступно в $_modx->resource. При желании к нему можно обращаться только через квадратные скобки — это обычный массив с данными. Не думаю, что это сложнее, чем различать [[*id]] и [[+id]].

Или тут какие-то подводные камни снова?

'id' | placeholder — то же самое, что и $modx->placeholders['id'], какие тут могут быть подводные камни? Если $modx->placeholders['id'] доступен, значит и альтернативная конструкция что-то вернет.

Если что, я не говорю, что стандартный шаблонизатор лучше, он просто выглядит логичнее и проще.

Так стандартный «шаблонизатор» практически ничего не умеет. Он призван лишь фильтровать вывод. Это, например, когда нужно вывести текст-заглушку, если плейсхолдер пуст. Тут — никаких проблем. Но что-то сложнее — увы.

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

Для конкретного разработчика однозначно вариации обращений в fenom больше

Это каких вариаций обращения больше? Если ты про различные методы, которые предоставляет объект $_modx, так это нельзя назвать вариациями, это же тот же самый глобальный $modx, только с некоторыми ограничениями.
Под вариациями можно понимать обращение к массиву либо через точку, либо через квадратные скобки, но это легко решается — к массиву можно обращаться всегда через скобки, прямо как в php.

если я и буду использовать модификатор, то один вариант, который привычен (например, :ne=``)

Так это для тебя привычен этот вариант, а если тебе достанется сайт от другого разработчика, которому будет привычен вариант notequals?

я имел ввиду именно вызов тегов MODX

Так стандартные модификаторы напрямую связаны со стандартными тегами modx.
Не будешь же ты проверять через Fenom-овский {if} наличие [[*id]]

Было бы сильно удобнее, если бы fenom в MODX отрабатывал бы по схожей логике

Так это и так уже есть — альтернативный синтаксис через прямую черту. Например,

{1 | resource : 'pagetitle'}
{'some_entry' | lexicon}
{'some_text' | upper}

Чем не единый стиль?

Есть какой-то стандарт требований к шаблонизатору? Я не нашел.

Шаблонизатор — это ведь про удобную обработку входящих данных в твоем шаблоне.
Представь, что тебе в чанк прилетел массив, который тебе нужно обработать.
Для первых 3 элементов тебе нужно добавить один css-класс, для остальных — другой.
Шаблонизатор должен решать эти задачи, в этом его и назначение.
Fenom с этим отлично справляется, как и какой-нибудь Smarty/Twig/Blade/etc.
Фильтры ввода-вывода не могут даже по массиву пройтись, тебе нужно будет писать сниппеты или парсить малюсенькие чанки столько раз, сколько элементов в твоем массиве.
Чувствуешь разницу?

мол зачем вообще писать сниппеты, пусть «тру-шаблонизатор» отрабатывает все.

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

реально настолько отвратительно?

Да, после Fenom это наимерзкая штука, даже притрагиваться противно. На каждый чих нужно писать сниппет, синтаксис сам по себе ужасный. Попробуй написать какую-нибудь более-менее сложную конструкцию с парочкой if-ов. Глаза сломаешь читать это потом.

Что уже говорить про разношерстность этих модификаторов. Одних только != модификаторов (notequalto, notequals, isnt, isnot, neq, ne) уже шесть штук, зачем? Один разработчик использует одно, второй — другое, третий — третье.

Так что еще очень хороший вопрос о том, что разношерстнее — модификаторы или несколько вариаций обращения к массиву в Fenom.

И то, и то шаблонизаторы, принципиальной разницы нету.

Если «шаблонизатор» не позволяет пройтись по массиву в цикле, то это никакой не шаблонизатор, это фильтры ввода-вывода — именно так они правильно и называются.

msGetOrder запускается непосредственно из основного класса miniShop2. Изменить это поведение можно одним способом — расширить основной класс заказа и прописать там специальный метод changeOrderStatus из основного класса — miniShop2 предусматривает это.
Ну а в методе уже можно поменять логику, как душе угодно.

{foreach 1..31 as $value}
    {if $value@index % 2 == 0}выполняется каждые 2 итерации (шаг == 2){/if}
    {if $value@index % 5 == 0}выполняется каждые 5 итераций (шаг == 5){/if}
{/foreach}

for — устаревший тег, его не нужно использовать.
Что значит «свой шаг»? Напиши полную задачу.

т.е. нельзя из msProducts данные в массив загнать?

Нельзя.

как мне от-туда миниатюры minishop получить, например?

Открыть сниппет msProducts, написать в поиске includeThumbs, а затем продублировать подобную выборку в pdoResources.
Если не нравится такое решение, то можно вызывать msProducts дважды, вряд ли это радикально повлияет на производительность, особенно в рамках карусели, где редко бывает больше 10-20 товаров.
Либо можно написать свою собственную выборку в новом сниппете, с помощью pdoFetch.
Либо на худой конец скопировать msProducts и убрать обработку чанка.

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

Собственно, можно было бы воспользоваться общим параметром &return, выставив json, но в msProducts есть такая строка:

'return' => !empty($returnIds)
        ? 'ids'
        : 'data',

Это значит, что из сниппета можно вернуть либо список id, либо распарсенный шаблон (строку).
Отсюда простой вывод: если нужен массив, то используй pdoResources в связке с 'return' => 'json'.

toPlaceholder

$res = $q->stmt->fetch(PDO::FETCH_ASSOC);

fetchAll

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

$product = $modx->getObject(msProductData::class, ['article' => 'твой артикул']);

ну а затем просто добавить его в корзину через API

$miniShop2->cart->add($product->id);