Гриборий

Есть же поле exdended, оно как раз для подобных извращений. Офис, ксати, полноценно умеет с ним работать. Я как-то делал следующим образом: в clientConfig'e хранил список полей и их настройки, потом феномом перебирал с ними массив, создавая формы по шаблону.

Спасибо за инфу. Я ленивый и пошел поменял запись в словаре, тк пока вроде еще на спалился.

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

Вот разжевывается принцип.

Написал плагин в итоге?

Создайте во втором разделе ресурс типа «ссылка» и укажите в соответствующем поле (оно там будет вместо контента) id статьи на которую хотите сослаться. Таким образом получите нужные ссылки в навигации и не получите дублей страниц тк ссылка будет делать редирект на настоящую статью.

А, ну и конечно мультикатегории минишопа.

Там написано «Следующие три фильтра применяются только к полю parent ресурса», но на самом деле к любому полю, содержащему id ресурса.

Вам тип ресурса «ссылка» или «символическая ссылка».

tv|roomType:parents

или

tv|roomType:categories

или

tv|roomType:grandparents

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

Решение немного печальное (сам так делал) тк вкладки отловить можно только по extjs идентификатору или порядку расположения. А оно все может измениться. Еще так не получится скрыть первую вкладку – по дефолту сначала будет открываться все равно она, пока не запомнится другая.

Может нам кто добрый покажет как это нормально сделать на extjs?

А чем это отличается, кэп, от повторной покупки с такой же скидкой на другой ключ?

ИМХО цена повторной покупки на тот же ключ долна быть хотя бы чуть меньше. Как бы для маркетингового обоснования нововведения. Ибо что мешало раньше покупать повторно.

'parents' =>  $_modx->resource.id,

&nbsр;

Управление словарями > Core > User

Надеюсь, понятно, что речь о изменения текста лейбла у поля. Например, на странице редактирования профиля. А отправлять и получать данные нужно будет по-прежнему из поля state.

Дополнительные поля профиля (extended и не) – это, конечно, прекрасно. Но это, имхо, если не хватает обычных. Я бы записал организацию в любое неиспользуемое у вас поле профиля (zip, state…)

И как у вас хранится контент (заголовки, описание…)?

Подстановка контента – это же уж совсем индивидуально для каждого проекта. Вот тут принцип описан.