Да я так и делал. [[+address.city]]
не подставляется. Пустота в subject, а в самом письме подставляется нормально.

Насчет номера заказа понял. Спасибо.

Через файл-менеджер? (3 вкладка в левой колонке админки)

Спасибо большое!
Все теперь работает как надо.
Вы не знаете, можно ли как-то в самом modx просматривать содержимое стандартных чанков от сниппетов?

Удали /core/cache — и должно заработать.

Пока рано.

Это будет, но позже.

В словарях минишопа настройки subject-ов писем. Плейсхолдеры ставятся те же, что и в письме.
[[%ms2_email_subject_...]]
Нужен свой обработчик заказов, можно только функцию getnum переопределить. bezumkin.ru/modx/minishop2/classes/804/

Ого! На тестовом тарифе летает как реактивная! Заманчиво. Спасибо, Василий.
Вопрос не технического характера: заказчикам, которым принципиально иметь приходные документы, счета и т.п., можно будет, уже сейчас, рекомендовать ваш новый хостинг? Или рано пока?

Так работает) Огромное спасибо!

А можно ли как-то поменять subject письма, чтобы обрабатывался и вставлялся город?

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

Спасибо.

Я тоже готов вписаться деньгами. Полезная штука была бы.

Стандартный чанк содержит следующий код:

[[+_isactive:is=`1`:then=`
	<a href="[[~[[+id]]]]"><</a> 
	`:else=`
	<
	`]]

Вам в Ваших чанках нужно сделать тоже самое, ну и в else написать что хотите (или стереть).

Насколько я понял, tv-шки не джойнятся. Вам нужно доработать сниппет msGetOrder, либо написать свой — получать tv продуктов в заказе и заполнять соответствующие плейсхолдеры.

Поля publishedon, createdon, editedon, deletedon хранятся в базе в виде int(20). Вам нужно Вашу дату перевести в unix timestamp. Например, 1401235200 для 2014-05-28 00:00:00 в GMT.
Либо использовать &where без json:

&where=`modResource.publishedon > UNIX_TIMESTAMP('2014-05-28 00:00:00')`

Нет. Это все я уже перепробовал.

[[+tvname]]?

[[!pdoResources? 
             &parents=`19,12,7976,8108,8209,8311,15594` 
             &includeTVs=`hitspage, comment, expert_photo` 
             &limit=`5` 
             &depth=`0` 
             &tpl=`tmp` 
             &where=`{"publishedon:>":"2014-05-28 00:00:00"}` 
             &sortby=`hitspage`  
             &sortdir=`DESC` 
             &hideContainers=`1` 
             &showLog=`1`]]

Так же по идее должно работать? Выбираются материалы до 28.05 и сортируются по количеству просмотров. Или я что-то упускаю?

Вот это отлично было бы, мы за время работы с МАКИ МАКИ столкнулись с ограничениями разными. Например, у некоторых людей закрыт доступ к личной почте на работе. Или, если встает вопрос интеграции, скажем с iOS приложением, то там уже в любом случае нужен пароль, чтобы пользователь не прыгал между приложением и почтой.

Там ограничение на нагрузку. Свеб — полное г. как хостинг, когда проект начинает хоть немного потреблять ресурсы)

Понаблюдал. Что получается в версии 1.3.0:

1. При пересоздании конечного минимизированного файла предыдущий файл не удаляется. Тем самым, папка будет быстро и бесконтрольно пухнуть.
2. Конечный минимизированный файл пересоздаётся только в том случае, если меняется хэш содержимого минимизированного файла. Т.е. если изменить содержимое некоторого комментария исходного файла, то минимизированный файл пересоздаваться не будет, хотя исходный файл изменён. Логично.

3. Если не очищать кэш modx, то конечный минимизированный файл в версии 1.3.0 пересоздаётся так же быстро, как и в версии 1.2.2.
4. Если в версии 1.3.0 очистить кэш modx, то minifyX отрабатывает очень долго (в 10 раз дольше), не зависимо от того, пересоздаётся конечный минимизированный файл или нет.

Возникает вопрос: что делает MinifyX 1.3.0 при очистке кэша modx ?

У меня формируется 2 минимизированных файла (их размер различается в 10 раз):
.css размером 20 Кб
.js размером 200 Кб

В версии 1.2.2 скорость формирования этих файлах такая:
.css — x
.js — 10х

В версии 1.3.0 скорость отработки minifyX без очистки кэша modx (не зависимо от того, пересоздаются минимизированные файлы или нет):
.css — x
.js — 10х

В версии 1.3.0 скорость отработки minifyX после очистки кэша modx (не зависимо от того, пересоздаются минимизированные файлы или нет):
.css — x
.js — 100х
Т.е. здесь обработка .js выполняется уже в 100 раз дольше .css, хотя размер его в 10 раз больше .css

Может, последняя версия munee при обработке .js-файлов выполняет ещё какую-то масштабную обработку? Причём эта дополнительная масштабная обработка выполняется только при очистке кэша modx. Если кэш modx не очищать, то даже при пересоздании минимизированных файлов MinifyX 1.3.0 отрабатывает быстро (как и 1.2.2).

Так причина перегенерации файлов при очистке кэша modx тоже неизвестна?

у меня всё по-прежнему быстро

Об этом можно судить только протестировав время для двух вариантов. Я протестировал. Время увеличилось в 4 раза. Уверен, что и у любого другого протестировавшего разница будет существенной.