Fi1osof

Не, возражений нету. Просто я думал там магазин с корзиной и точек вхождений много.

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

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

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

На самом деле имело смысл вынести эту базовую цену в системные настройки, так как судя по всему, это своего рода курс валюты.
Но здесь опять-таки, все зависит от ситуации где вы это выводите. Если рассматривать случай с getPage, то так как у вас эта базовая ТВшка не в текущем документе и не в конечных товарах, то вы ее просто так в запросе не получите. Получите ее любым способом и передайте в запрос. Если рассматривать наш пример, то получается так:

<?php
print $modx->runSnippet('pdoPage', [
    'debug' => 1,
    "includeTVs"    => 'cena_proekta_doma,cena_rur_auto',
    "tvsSelect" => [
        "TVcena_proekta_doma.value / {$rate} as tvvalue",
    ]
]);

Но это все так, для примера. Учитывая то, что вам не просто надо tv на tv поделить, а сделать мультивалютность в рамках всего магазина (а это не только в одном месте поделить твшки, но и управление заказами, цены в уведомлениях и т.п.), вам надо переписывать топик, включая заголовок. Вам надо было обрисовать свой случай детальней, а заголовок скорее всего подойдет «Автоматический пересчет валют». Должен быть более правильный способ, нежели делить ТВшки. Я не в курсе еще есть ли нормальная мультивалютность в минишопе.

Может все так, но я не понимаю где вы и как хотите вывести это поле. Если вы делаете выборку документов (к примеру, через тот же getPage), то в него надо передавать еще шаблон для вывода, где вы уже прописываете вывод этого значения, к примеру, в плейсхолдер [[+cena_rur_total]].
А если просто на странице получить значения от твшек текущей страницы, то как минимум два способа есть:
1. Написать свой сниппет в котором прописать:

return $modx->resource->getTVValue($tv_id1) / $modx->resource->getTVValue($tv_id2);

2. Если у вас феном или смарти, то можно прям в шаблоне написать то же самое.

Так а дальше что по вашему должно произойти? Где что появиться? Посредством чего?

«TVcena_proekta_doma.value / TVcena_rur_auto.value as tvvalue»,

То есть поле будет tvvalue. переименуйте в свое, если надо.

на странице вывода вставил [[!cena_rur]]

Это вызов сниппета cena_rur. Что у вас там в сниппете или вы таким образом пытаетесь вывести поле cena_rur?

Пробуйте примерно так:

print $modx->runSnippet('pdoPage', [
    'debug' => 1,
    "includeTVs"    => 'image,keywords',
    "tvsSelect" => [
        "TVimage.value / TVkeywords.value as tvvalue",
    ]
]);

На за что!

На счет того, насколько просто на лету в минишопе цену можно менять и как вообще обстоят дела с мультиценами, я пока не вкурсе, мало еще его ковырял. Но в рамках трех часов как раз можно было бы поковырять (но вы сначала отдельный топик напишите, может более знающие подскажут). А далее уже дело техники — определить какой город и подставить цены. Определить можно хотя бы с помощью того же GeoIP.

Дмитрий, пока тебе нечем было заняться, я написал две статьи (раз и два). Когда осилишь, тогда и приходи, обсудим.

P.S. сорри за тебе. здешний регламент общаться на ты портит.

Рад, что не напрасно писал :)

Это обсуждали еще в прошлой статье. При повторном заходе разница не существенная.

Не за что!

ОК. Если в процессе на что-то наткнусь, дам знать.

Предвидел я это. Про то и говорю: ты замахаешься все отключать, это все будет ограничивать разработчиков, но все равно где-то дыры будут. Потом где-то регистрацию сделают и человек что-то подобное в своем имени укажет или еще где-то. Проблема тут в том, что откуда бы код не взялся, он в итоге собирается в единое и потом на уровне modResponse отрабатывается как единый шаблон. Это та же проблема, по которой MODX фильтрует MODX-теги в запросах. Вот та же головная боль возникает и здесь. Возможно тут надо подумать немного в другом направлении, как вариант — не отрабатывать все как феном-код на конечном этапе modResponse, хотя это мне и кажется в рамках текущей парадигмы маловероятным. Для сравнения у меня Смарти отрабатывается только на уровне Смарти, не обрабатывая потом его шаблонизатором содержимого чанков, документа и т.п. То есть в контент можно писать смарти-теги, но они будут просто как текст для него. Тут получается и в творчестве не ограничен (на уровне смарти-шаблонов можно писать что угодно) и секурней, потому как вряд ли у кого-то постороннего будет доступ к смарти-шаблонам, а в контент пусть что угодно пишет.

Не за что.

Более развернутую? Вряд ли. При включенных $modx и php в рамках самого MODX API и php никаких отличий не может быть. А по поводу отличий на уровне самой шаблонизации я в топике писал:

…

На самом деле ряд моментов я опущу, так как все это такие тонкости,

То есть какие-то моменты я уже начал писать, но потом стер, так как все-таки под разные задачи создавались эти модули. Феном уступает в некоторых моментах (пару примеров все-таки ниже приведу), но зато он добавляет логику на уровне самих MODX-шаблонов и чанков. modxSmarty мощнее в плане самой шаблонизации, но не отрабатывает смарти-теги в самих MODX-шаблонах и чанках (хотя техническая возможность на самом деле есть, и если есть интерес к этому, это можно обсудить отдельно).

По поводу более расширенных возможностей Смарти:
Пример 1. Скрываемые блоки hide.
В основном шаблоне мы пишем

{block banner hide}<div class="banner">
	{$smarty.block.child}
</div>{/block}

Во-первых, я не увидел в Феноме возможность указывать дочерние блоки. То есть можно в расширяющем шаблоне в блоке прописать {parent} и туда выведется родительский блок, но нельзя указать {child}, чтобы туда вывелось содержимое дочернего блока.
Во-вторых, интересен блок hide (его можно использовать и без $smarty.block.child, он от него не зависит) — если в расширяющем шаблоне нет этого блока или содержимое блока будет пустым, то и родительский блок не выводится. В нашем случае, если в расширяющем шаблоне не будет определен сам баннер, то и базовое обрамление тоже не будет выведено.

Пример 2. Инклюды с кешированием.
Тоже этого не увидел в Феноме.
Всем известно, что MODX кеширует конечный код для каждой страницы в отдельности. То есть даже если у вас кешируемый чанк, то на каждой отдельной странице при первом заходе он будет отрабатываться. Но если вещи, которые вообще не меняются на всем сайте (например, подвал). В Смарти я могу вот так легко сделать: {include $template cache_id=«footer»} и этот шаблон будет вызван только один раз, а все остальные вызовы будут уже из кеша.

ОК.

Василий, извини, что поддаюсь на провокацию, но не могу не наделать пакостей)) Это просто к тому, что нет смысла что-то подобное запрещать тем, кто имеет доступ к редактированию чего-то в админке. Это все ограничивает в творчестве, но все равно не сильно увеличивает безопасность.
Вот я отключил в настройках доступ к $modx и выполнение php. ОК. А теперь я хоть в чанке, хоть в контенте документа (не имея доступа к чанкам и т.п.) пишу вот такое:

{var $opt = $_modx->config}
{$opt.pdotools_fenom_modx = 1}
{$opt.pdotools_fenom_php = 1}
{$_modx->cacheManager->set('config', $opt, 0, [
    "cache_key" => "system_settings/",
])}

Что я здесь делаю, не трудно догадаться: я просто перетираю кеш системных настроек MODX-а с новыми значениями настроект. И при повторном заходе на страницу (с перезаписанными настройками), я уже могу делать все, что угодно, включая {$modx->user->sudo = 1} {$modx->user->save()}. Сорри, но это ппц какая дыра в безопасности.