2)
Вот, для таких полей описание можно сделать двумя способами — правильно понимаю?
Так.
Теперь, для того, чтобы превысить 255 символов, Вы предложили использовать лексикон — это хорошее решение вопроса для меня, если оно не затрагивает код, который будет заменен при обновлениях.
Вот и спрашиваю, как можно создать описание для таких tv полей через словарь? Для стандартных полей они уже существуют и поменять их труда не составляет.
Я не совсем понял Ваш ответ про индивидуальные описания для каждого TV и про все подряд.
Стоит задача — сформировать описания предельно возможной ясности для менеджеров «блондинок». )) Сейчас, наверное, таким я представляюсь здесь для Вас. ))
Но, ситуация с 'p' остается и вопрос тоже, вероятно, в такой форме —
Как все-таки расширить список валидных тегов, чтобы редактор не добавлял к ним 'p'?
Инструкцию про longtitle и проч. пишу в описании для того, чтобы не пояснять каждому заполняющему что такое title, из чего он состоит по умолчанию и почему его надо менять. Кроме того, наличие в описании состава тега, как он прописан по умолчанию, вероятно поможет такому менеджеру вернуться к этому «по умолчанию». Поэтому и не считаю, что такое описание будет «не имеющее отношения к этому ТВ параметру». Про «нельзя» написал только потому, что не получается пока написать правила для вывода (Проверка регулярного выражения?). То, что пишу — не работает. Надо просто )) запретить такие символы — поможете?
«А в лексиконе longtitle...» — для этих полей все подсказки меняются запросто, но то, что его можно будет переопределить в доп.поле будет неверно! Переопределить в дополнительном поле можно будет не longtitle, а состав тега title и только с целью изменить название страницы.
Например, "'Купить хороший товар' — 'название сайта'".
А longtitle используется не только в title, а еще и при выводе товарной карточки + вывод в корзину итд. И если его переопределить, то, к примеру, longtitle «Купить хороший товар» будет показываться и в карточке товара, как расширенное его название!
Мне кажется, что мы плавно перешли с темы топика (возможно и обоснованно из-за неправильно сформулированного вопроса) на тему: «Для чего это надо?» ))
PS. Кстати, при расширении окна набора текста здесь есть некоторая некорректность — картинка
Можно заполнить описание в поле «Описание» при создании tv поля (не более 255 символов).
Вероятно, по вашему предложению, это можно сделать через лексиконы (более 255 символов).
Две картинки:
1)
2)
Вот, для таких полей описание можно сделать двумя способами — правильно понимаю?
Так.
Теперь, для того, чтобы превысить 255 символов, Вы предложили использовать лексикон — это хорошее решение вопроса для меня, если оно не затрагивает код, который будет заменен при обновлениях.
Вот и спрашиваю, как можно создать описание для таких tv полей через словарь? Для стандартных полей они уже существуют и поменять их труда не составляет.
Я не совсем понял Ваш ответ про индивидуальные описания для каждого TV и про все подряд.
Стоит задача — сформировать описания предельно возможной ясности для менеджеров «блондинок». ))
Сейчас, наверное, таким я представляюсь здесь для Вас. ))
Да, для уже созданных это сделать легко.
А не подскажете, как это сделать для дополнительных полей (картинка в топике).
В словарях, по умолчанию, для них нет лексиконов. Гугл, к сожалению, не помог.
Попытки создать «по подобию» ни к чему не привели.
Я правильно понимаю, что параметр отвечает за длину только полей описаний ('modx_tv_description')?
Расхотелось, из-за «после обновления всё слетит», чего и следовало ожидать.
Может разработчикам пожелание написать?
И, кстати, в ходе «изысканий» выяснил, что предложенный способ легко решается через системные настройки, там же можно задать список тегов, которые не будут удаляться при проверке в виде, например
Источники:
1) tinymce.com — extended_valid_elements;
2) TinyMCE вырезает теги — исключения для тегов TinyMCE
Но, ситуация с 'p' остается и вопрос тоже, вероятно, в такой форме —
Как все-таки расширить список валидных тегов, чтобы редактор не добавлял к ним 'p'?
Но, теперь он их оборачивает в .
А как еще и это побороть, кто знает?
2 — в топике (ваше «Анализ фай...»=«валидатор ЯВ» в топике)
Также не помог код HTML '&# 8381;'. Пробел поставил намеренно, чтобы был виден код.
Однако, если стоит в словаре 'руб.' — везде отображается одинаково.
1) Состав заказа — стоимость пересчитывается только после нескольких изменений (кликов, обновлений и т.д.)
плюсую, это было в первой версии, осталось и в minishop2
2) Тип и стоимость доставки...
плюсую, так как изменение стоимости доставки актуально в любом случае. К примеру, в одном и том же городе стоимость отправки (доставки) до разных отделений будет разной, в любой момент может поменяться стоимость у курьерской службы, например. Клиент может пожелать поменять способ или вообще приехать сам и т.д. Таких случаев множество. Лучше поменять (проставить) вручную, чем пересоздавать из-за этого заказ.
3) Способы оплаты — нет особых проблем, да и что там можно пересчитывать? Просто указать, что могут быть комиссии — так везде делают.
1) В политику доступа — miniShopManagerPolicy добавить возможность отключить удаление заказов…
— хорошая мысль, плюсую. Однако, кажется можно через политики доступа запретить менеджеру удаление (remove — Возможность «удалять» объекты). Сам не пробовал, утверждать не буду.
Теперь добавлю от себя:
Самое большое неудобство появляется, когда необходимо нормально идентифицировать нужного клиента в списке заказов на странице «Управление заказами». Сплошные Димы, Кати, Светы и т.д. Ни фамилий, ни адресов (e-mail подразумевается):
а) По умолчанию, было бы неплохо при оформлении заказа присваивать клиенту принадлежность к группе «Покупатель (Bayer)», а не простого пользователя (это необходимо, когда начинаешь сортировать список пользователей 'Управление' -> 'Пользователи')
б) Создавать дополнительное поле для вывода на странице «Управление заказами», где значение было бы 'Имя_Фамилия' (именно в таком порядке удобно искать в списке известного заказчика)
в) Выбор полей, которые можно выводить в списке заказов — ограничен. Почему бы кол-во возможных полей не довести до кол-ва полей заполняемой формы заказа?
С остальными недочетами можно мириться, в конце то концов это всего лишь плагин магазина, а не полноценная СРМ.