Олег

Спасибо. Воспользуюсь, если не получится с лексиконом сделать.

Скорее я неправильно поясняю.
Инструкцию про longtitle и проч. пишу в описании для того, чтобы не пояснять каждому заполняющему что такое title, из чего он состоит по умолчанию и почему его надо менять. Кроме того, наличие в описании состава тега, как он прописан по умолчанию, вероятно поможет такому менеджеру вернуться к этому «по умолчанию». Поэтому и не считаю, что такое описание будет «не имеющее отношения к этому ТВ параметру». Про «нельзя» написал только потому, что не получается пока написать правила для вывода (Проверка регулярного выражения?). То, что пишу — не работает. Надо просто )) запретить такие символы — поможете?

«А в лексиконе longtitle...» — для этих полей все подсказки меняются запросто, но то, что его можно будет переопределить в доп.поле будет неверно! Переопределить в дополнительном поле можно будет не longtitle, а состав тега title и только с целью изменить название страницы.

Например, "'Купить хороший товар' — 'название сайта'".

А longtitle используется не только в title, а еще и при выводе товарной карточки + вывод в корзину итд. И если его переопределить, то, к примеру, longtitle «Купить хороший товар» будет показываться и в карточке товара, как расширенное его название!

Мне кажется, что мы плавно перешли с темы топика (возможно и обоснованно из-за неправильно сформулированного вопроса) на тему: «Для чего это надо?» ))

PS. Кстати, при расширении окна набора текста здесь есть некоторая некорректность — картинка

Василий, я наверное туплю или может быть вопрос некорректно задал.
Можно заполнить описание в поле «Описание» при создании tv поля (не более 255 символов).
Вероятно, по вашему предложению, это можно сделать через лексиконы (более 255 символов).
Две картинки:
1)

2)
Вот, для таких полей описание можно сделать двумя способами — правильно понимаю?
Так.
Теперь, для того, чтобы превысить 255 символов, Вы предложили использовать лексикон — это хорошее решение вопроса для меня, если оно не затрагивает код, который будет заменен при обновлениях.
Вот и спрашиваю, как можно создать описание для таких tv полей через словарь? Для стандартных полей они уже существуют и поменять их труда не составляет.
Я не совсем понял Ваш ответ про индивидуальные описания для каждого TV и про все подряд.
Стоит задача — сформировать описания предельно возможной ясности для менеджеров «блондинок». ))
Сейчас, наверное, таким я представляюсь здесь для Вас. ))

Спасибо.
Да, для уже созданных это сделать легко.
А не подскажете, как это сделать для дополнительных полей (картинка в топике).
В словарях, по умолчанию, для них нет лексиконов. Гугл, к сожалению, не помог.
Попытки создать «по подобию» ни к чему не привели.

Поиск хороших менеджеров — прерогатива начальства, которое, обычно, не горит желанием платить нормальные зарплаты. ))

Владислав, спасибо за ответ.
Я правильно понимаю, что параметр отвечает за длину только полей описаний ('modx_tv_description')?
Расхотелось, из-за «после обновления всё слетит», чего и следовало ожидать.
Может разработчикам пожелание написать?

Обертывает в 'p' только невалидные теги, но проверку все-равно проводит на предмет наличия незакрытых тегов.

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

с атрибутами:
тег[атрибут|атрибут|атри...],тег[атрибут|атрибут|атри...] 
если неизвестны атрибуты тега:
тег[*],тег[атрибут|атрибут|атри...],...
если тег не имеет атрибутов:
тег,тег[*],тег[атрибут|атрибут|атри...],...

Источники:
1) tinymce.com — extended_valid_elements;
2) TinyMCE вырезает теги — исключения для тегов TinyMCE

Но, ситуация с 'p' остается и вопрос тоже, вероятно, в такой форме —
Как все-таки расширить список валидных тегов, чтобы редактор не добавлял к ним 'p'?

Да, неизвестные теги теперь не удаляет.
Но, теперь он их оборачивает в

<p>

.
А как еще и это побороть, кто знает?

[[pdoSitemap?
    &parents=`-23`
    &showHidden=`1`
]]

1 — опубликован
2 — в топике (ваше «Анализ фай...»=«валидатор ЯВ» в топике)

Пробовал тогда же ставить в чанк письма подгрузку font awesome — ни к чему не привело.
Также не помог код HTML '&# 8381;'. Пробел поставил намеренно, чтобы был виден код.
Однако, если стоит в словаре 'руб.' — везде отображается одинаково.

Сперва по топику:
1) Состав заказа — стоимость пересчитывается только после нескольких изменений (кликов, обновлений и т.д.)
плюсую, это было в первой версии, осталось и в minishop2

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

3) Способы оплаты — нет особых проблем, да и что там можно пересчитывать? Просто указать, что могут быть комиссии — так везде делают.

1) В политику доступа — miniShopManagerPolicy добавить возможность отключить удаление заказов…
— хорошая мысль, плюсую. Однако, кажется можно через политики доступа запретить менеджеру удаление (remove — Возможность «удалять» объекты). Сам не пробовал, утверждать не буду.

Теперь добавлю от себя:

Самое большое неудобство появляется, когда необходимо нормально идентифицировать нужного клиента в списке заказов на странице «Управление заказами». Сплошные Димы, Кати, Светы и т.д. Ни фамилий, ни адресов (e-mail подразумевается):

а) По умолчанию, было бы неплохо при оформлении заказа присваивать клиенту принадлежность к группе «Покупатель (Bayer)», а не простого пользователя (это необходимо, когда начинаешь сортировать список пользователей 'Управление' -> 'Пользователи')
б) Создавать дополнительное поле для вывода на странице «Управление заказами», где значение было бы 'Имя_Фамилия' (именно в таком порядке удобно искать в списке известного заказчика)
в) Выбор полей, которые можно выводить в списке заказов — ограничен. Почему бы кол-во возможных полей не довести до кол-ва полей заполняемой формы заказа?

С остальными недочетами можно мириться, в конце то концов это всего лишь плагин магазина, а не полноценная СРМ.

Кто-нибудь хостился на worldhost.ru?