В смарти все переменные живут в рамках одного объекта Smarty. Во время рендеринга страницы каждый блок рендерится в своем экземпляре Smarty.

В вашем случае наверное будет удобнее воспользоваться общим объектом приложения APP, если вы хотите настройки в layout.tpl задавать.

{$app->custom_var1="123"}
{$app->custom_var2="456"}

Где нужно, просто используйте: {$app->custom_var1}

Такой объект будет во всех шаблонах общим.

А еще у нас есть THEME_SETTINGS - рекомендую конечно его использовать дня глобальных настроек шаблона.
https://readyscript.ru/dev-manual/dev_templates.html

Насчет фильтра по диапазону чисел:

На мой взгляд вам нужно сделать 2 характеристики числовые:
- Площадь, от (тип. число)   - визуально скрыть её
- Площадь, до. (тип. число) - визуально скрыть её

А затем просто в визуальной части отобразить общий слайдер (безусловно нужно программировать на JS),
И при установке значения на общем слайдере, на самом деле добавлять фильтр по двум  характеристикам в скрытые input'ы

----------

Выводить подходящую комплектацию в категории для установленных фильтров - возможно, нужно разрабатывать доп. модуль.
В шаблоне у вас доступны переменная $filter со всеми фильтрами и полный список найденных товаров, вы можете перед отображением товара выбирать наиболее подходящую комплектацию и отображать какие-то данные из неё.

----------

Пользовательская документация по фильтрам:
https://readyscript.ru/manual/catalog_c … cteristics
https://readyscript.ru/manual/catalog_p … _tab_chars
https://readyscript.ru/manual/catalog_property.html

Принцип работы поиска можно найти в коде, класс Catalog\Model\PropertyApi::getFilteredQuery()

Разработка API, а тем более REST API - это большая задача, особенно если нет под рукой набора базовых классов для API. (собственно мы этим сейчас занимаемся). Все же вас хочу предостеречь и предложить дождаться выхода нашего модуля для удобной разработки внешнего API.

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

Если вам все же необходимо начать разработку прямо сейчас на имеющихся возможностях фреймворка,
то просто можете создать свой модуль. Рекомендую нашу статью в помощь https://readyscript.ru/text-blog/razrab … nyy-modul/

Приоткрою тайну, мы сейчас активно работаем в направлении мобильных приложений для нашей платформы и соответственно активно разрабатываем механизм обмена данными с движком посредством внешних API.

Чуть позже мы включим в наш дистрибутив модуль для нашего фреймворка, позволяющий элементарнейшим образом добавлять любые внешние методы API. Определенная часть методов API (которые будут нужны нашим приложениям) будут уже написаны и смогут служить примером для написания других методов.

Скажу сказу, мы проанализировали классический REST подход, отлично описанный на сайте jsonapi.org. И посмотрели в сторону API Вконтакте, которое на несколько порядков удобнее в дальнейшем расширении и разработке. Пару недель потратили на анализ и прагматичное сравнение двух архитектурных стилей. В результате мы выбрали архитектурный стиль ВК API. Название этого архитектурного стиля мы так и не смогли выявить, видимо потому что его нет, но оно чудовищно удобное. https://toster.ru/q/350268

Из плюшек будущего API:

1. Оно будет самодокументируемо за счет PHP Reflection, т.е. вы просто пишете класс, создаете методы, согласно интерфейсу, объявляете параметры вашего метода API в виде аргументов специальной функции, прописываете комментарии PHPDoc, на выходе получаете полностью готовую автоматическую документацию по всем вашим API.
2. Будет определенный набор базовых абстрактных классов, для стандартных CRUD операций.
3. Авторзация уже будет в комплекте, пока будет метод oauth/token из официальной спецификации oAuth.

4. Верификация параметров будет многоуровневая. Сперва фреймворк будет автоматически сверять наличие обязательных параметров на основе обязательных аргументов специальной функции контроллера. (с помощью Reflection), далее каждый метод может делать дополнительную верификацию и бросать исключение в случае ошибки.

Модуль еще находится в активной разработке, рекомендуем подождать его выхода. (Срок пока сложно назвать)

В текущий момент, вам возможно будет проще разработать более простой консольный импорт/экспорт файлов вашего формата, т.е. не полноценный внешний API, а просто механизм импорта/экспорта файлов вашего кастомного формата, это на порядок быстрее и вероятно закроет вашу задачу?

1. available (есть в наличии) будет true, если остаток товара > 0.
2. В теге param отображаются как характеристики товара, так и характеристики комплектации.

В случае, когда в теге param идет значение характеристики товара - там атрибут unit приписывается, если у соответствующей характеристики задана единица измерения.

В случае, когда в теге param идет значение хар-ки комплектации - атрибут unit не предусмотрен, так как у характеристик комплектаций нет Единицы измерения. Вы можете его предусмотреть в названии хар-ки, например "Размер, RU"

Проверили, действительно для админских контроллеров возможность перегружать через файлы темы была недоступна. Добавили. Выйдет в следующем обновлении.

Вы можете  открыть в браузере ссылку на YML файл и там будет видно, что все характеристики, у которых не установлен флаг "Не экспортировать", по умолчанию попадают в теги <param>

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

Система в момент формирования XML файла будет читать у каждого товара указанную характеристику и выводить её в XML файл для Яндекса.

Насколько я понял, у вас используется 2 независимых контейнера в Конструкторе сайта:

1. Поиск (searchContainer)
2. Конент (mainContent)

Вы можете у первого задать "Внешний шаблон" следующего содержания:

<div class="wrapper"> {$wrapped_content}

И у второго задать "Внешний шаблон", следующего содержания:

{$wrapped_content}</div>

Розничная в моем примере - это цена, задаваемая вручную (не автовычисляемая).

Просто сперва вы в неё можете скопировать цены из Базовой, с помощью мультиредактирования,
а затем для нужной группы её уменьшить, опять с помощью мультиредактирования.

Спасибо!

Вы вносите изменения в файлы входящие в дистрибутив, что естественно несовместимо с обновлениями, если вы в процессе обновления ставите флажок напротив данной темы.

Любые изменения в системе допустимы только с помощью новых файлов.

В вашем случае (так как у вас незначительные изменения) можно делать так:

Вам нужно создавать свой CSS файл (custom_file.css) в папке perfume/resource/css, в CSS вам нужно путем перегрузки селекторов задавать новые стили, указывать новые ссылки на и НОВЫЕ файлы изображений (ни в коем случае не перезаписанные старые).
Затем вы можете создать файл scripts.tpl в корне темы perfume и воспользоваться в нем конструкцией по подключению CSS файлов:

{addcss file="custom_file.css"}

Если хотите изменять tpl файлы блочных контроллеров, то в конструкторе сайта можете назначить конкретному блоку новый шаблон и только его изменять.

-----

Если вы хотите изменять TPL файлы не блочных контроллеров, то безусловно вам нужно клонировать тему, т.е. отвязывать её от обновления (так как по факту это уже будет ваша собственная тема), а затем вручную обновлять, исключая те файлы, где вы внесли изменения.

Описанная вами проблема решается путем заведения в системе исходной цены, назовем её Базовая. Эту цену никто не модифирует, а используют для расчета Розничной (именна она отображается на сайте и является по умолчанию).
На все товары сперва применяется формула.
Розничная = Базовая + 0 р., затем на нужную группу: Розничная = Базовая - 10%.

Уточните, какая у вас тема оформления. Как и какие изменения вы вносите?

Сложность в том, что у одного товара может быть по 100 цен и больше, вы рассматриваете только свой случай, а мы учитываем все существующие и возможные магазины на платформе. За данную реализацию мы приступим, сразу после того, как сделаем вывод комплектаций возле товаров в списке, все поэтапно.

Воспользуйтесь инструментом для мультиредактирования цен. Выбираете категорию, на которую нужно сделать отрицательную наценку, ставите флажок "Выбрать товары на всех страницах", внизу нажимаете редактировать.
Указываете формулу для редактирования, например Продажная = Розничная - 10%.

Здесь подробнее с картинками:
https://readyscript.ru/text-blog/Novye- … adyScript/

DI (Dependency Injection) - довольно удобная вещь, но на статически расширяемых фреймворках. Где расширение происходит программистом, путем прописывания нового модуля вручную в конфиг и где полный набор модулей заранее известен разработчику, таким образом он всегда знает, кто перегружает тот или иной класс, опираясь на свой же конфиг.

Наша же архитектура - динамически расширяема. ReadyScript у всех пользователей работает с разным набором модулей, которые привносятся в систему в разном порядке. Иными словами вы в своем модуле никогда не будете знать кто сейчас перегрузил класс, который вы хотите использовать, модуль "a" или модуль "b", а может есть какой-то модуль "d", который это делает. Тем самым в динамических платформах - это способно внести определенный хаос в работу системы и в стабильность работы системы.

Вы можете ожидать, что установили свой модуль и перегрузили какой-то класс, а на самом деле Пользователь установил затем другой модуль, который тоже перегрузил этот же класс, в итоге вы будете обращаться к несуществующим методам.

У нас вместо этого реализовано огромное множество альтернативных приемов перегрузки и расширения стандартной функциональности. Можем, например, обсудить какую задачу вы не смогли решить, думаю подскажем какое решение можно применить.

Юрий добрый день!

Вижу, что последний ответ нашего специалиста по вашей заявке был вчера. Приносим извинения за ожидание, сегодня все работы будут завершены по вашей заявке. Вы всегда можете позвонить к нам в офис по бесплатной линии 8-800 или написать ваш вопрос к нам в online консультант, чтобы узнать статус заявки. Мы всегда на связи.

Воспользуйтесь функцией array_reverse в шаблоне для списка адресов, это будет самым простым решением.

Общий алгоритм должен быть такой.

1. Создаете дополнительное поле через настройки модуля магазин для заказа.
2. Затем навешивайтесь на событие orm.afterwrite.shop-order, и обновите поле user_passport у объекта пользователя

Кол в обработчике afterwrite заказа, будет схематично такой:

$user = $order->getUser();
$user['ПОЛЕ ПАССПОРТА В БД ЮЗЕРА'] = $order['userfields_arr']['АЛИАС ПОЛЯ ПАСПОРТА ЗАКАЗА']; //В userfields_arr - находятся значения кастомных полей, добавленных в настройках модуля админки.
$user->update();

521

(1 ответов, оставленных в Вопросы по работе с системой)

Вы можете назначать собственные темы оформления для каждого сайта.
1. Создайте копию темы оформления, через кнопку "клонировать тему оформления" в разделе Управление->Шаблоны.
2. Назначьте второму мультисайту клонированную тему оформления, так у вас появится отдельный style.css для нового сайта.

Нет, в product_x_dir не создаются записи. Товары выбираются согласно заданным критериям из своих категорий. Подмешивание товаров просходит в контроллере listproducts

Вы можете добавить в list_products.tpl

{$app->title->addSection("Страница {$paginator->page}", 0)|devnull}

Товар - очень сложная сущность. У него может быть множество цен + еще может быть множество цен у каждой комплектации товара, в итоге у товара может быть и 50 и 100 цен (в этом сложность), данная функция возможно появится в будущих версиях, когда мы реализуем показ всех комплектаций товара в общем списке товаров админки.

В текущий момент, вы можете воспользоваться экспортом Остатков и цен  в CSV, массовой правкой цен в excel, затем импортом CSV.

Вам нужно просто в шаблоне, где выводятся значения характеристик (product.tpl), добавить модификатор |unescape

Пример:
{$prop_value|unescape}