Настройки поиска (Страница 5 из 43)

другой по стилю вывод характеристик - в фильтре имеется ввиду?

Если да, то речь значит идет о шаблоне /moduleview/catalog/blocks/sidefilters/filters.tpl
текущая категория на странице каталога записывается в кастомное extra свойство текущего маршрута.
То есть получить объект категории можно так:

{if $router->getCurrentRoute() == 'catalog-front-listproducts'} {*Проверка что мы находимся на странице категории*}
    {$dir = $router->getCurrentRoute()->getExtra('category')} {* Получаем текущую категорию *}
    {if $dir.alias == 'test'} {* Проверяем что alias текущей категории = test *}
          {$customStyle = true} {* Делаем что нам нужно *}
    {/if}
{/if}

Если позволите, выскажу свое мнение.
Люблю иногда почитать оригинальное описание того, для чего разрабатывался тег rel="canonical" в RFC 6596.

https://tools.ietf.org/html/rfc6596

--------------

Тег rel="canonical" нужен исключительно для того, чтобы делать ссылки от дублирующего частного к общему.
Например, у вас есть одна страница со всеми товарами и есть страницы с этими же товарами с пагинацией, соответственно rel="canonical"  должен указывать на страницах с пагинацией на страницу со всеми товарами.

--------------

Различные страницы пагинации - это не дублирующийся контент, если у вас нет общей страницы (на каждой странице - разные товары). Указывая ссылку на первую страницу - вы просто отрезаете  от индексирования все остальные страницы каталога, кроме первой и все. SEOшники обычно ставят галочку - rel=canonical применили, задача закрыта, но это ведь не так!

В RFC прямо сказано про пагинацию, то о чем я пишу выше:

Просто жалко ваши сайты, когда что-то делается на них без понимания того, для чего в деталях это делается.

Установите флажок напротив "Публичность" в настройке "Поля категории, которые не следует обновлять"
на вкладке "Каталог товаров - что следует обновлять" в настройках модуля Обмен данными с 1С (exchange)

Облако не для программистов, облако - готовый сервис. Клиенты облака в основном не знакомы с html, css, ftp  и не желают в это погружаться.

Я даже не представляю как это с точки зрения пользователя может быть. Допустим есть товар:

1. Кружка - 3 шт. на складе А, 2 шт. на складе Б
2. Тарелка - 10 шт. на складе Б

Клиент же не обозначает где будет покупать, когда заходит на сайт в Гипермаркете и накидывает в корзину 4 кружки, 10 тарелок, потом идет в корзину нажимает кнопку оформить заказ, выбирает самовывоз со склада А и что дальше?

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

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

-------------------------------------------

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

Внесу ясность в правки шаблонов. Дело в том, что различные методы расширения функциональности шаблонов появлялись со временем, а старые при этом продолжали работать. По этому есть множество вариантов на выбор:

1. Полное клонирование темы и изменение файлов уже внутри нее. Делается прямо через админ.панель
Управление -> Шаблоны -> Клонировать тему. (есть особенности с темой default, в клона нужно сперва копировать tpl файлы из модулей, а затем изменять.)

2. Для простого добавления своих скриптов мы придумали scripts.tpl, которого нет в дистрибутиве, но он подключается, если в корне лежит этот файл. Этот метод подходит только для добавления скриптов и стилей на все страницы шаблонов.

3. Частичная модификация темы с помощью .my.tpl, .my.css  .my.js. Отлично подходит если хочется, чтобы все в теме обновлялось, кроме измененных частей. Очень простой способ модификации с относительно небольшими потерями обновляемости.

https://readyscript.ru/dev-manual/dev_t … tends.html

4. Модификация шаблонов с помощью кастомного модуля и обработки хуков в шаблонах. Способ сложный для обычного пользователя, но позволяет изменять даже часть одного tpl шаблона, при этом сохраняя обновление других частей этого же tpl.
Это самый ювелирный способ модификации.
https://readyscript.ru/dev-manual/dev_t … hooks.html

Насколько я понимаю, вы находитесь на странице просмотра статьи, т.е. article-front-view, за данную страницу отвечает контроллер \Article\Controller\Front\View, видим что в данном шаблоне статья передается в переменной article

        $this->view->assign(array(
            'article' => $article
        ));

Ваш ход мыслей верный, думаю вы просто ошиблись в том, что getCategory() нужно вызывать у $article в шаблоне
%article%/view_article.tpl

{$categoria = $article->getCategory()} {* Здесь будет Article\Model\Orm\Category *}
{$parent = $categoria->getParent()} {* Здесь будет Article\Model\Orm\Category *}
{$parent.title} {* У объекта Article\Model\Orm\Category название в поле title находится *}

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

Вам нужно вносить изменения в шаблон /ВАША ТЕМА/moduleview/catalog/product.tpl
А еще правильнее, создавать на его основе  /ВАША ТЕМА/moduleview/catalog/product.my.tpl

В этом случае при любом обновлении ваши изменения не будут исчезать.

Очень здорово, что вы не побоялись ввязаться в эту крайне непростую задачу.
Насколько я понимаю, вы добавляете join вашей таблицы во время выборки товаров, чтобы перекрыть цены из xcost?

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

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

Одна из проблем - это был объем такой таблицы, если на сайте 10 000 товаров, 1000 пользователей и 2 типа цен, то это уже 20 млн. записей. JOIN такой таблицы даже с индексами будет довольно дорогой по ресурсам. И это я привел очень скромные параметры - 10k товаров и все с одной комплектацией и без доп.унификаторов.

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

Вариант как у вас - что источник новых цен - всегда 1С частично снимает эту проблему, но делает цены какое-то время неактуальными на сайте для пользователя, хотя возможно это очень небольшое время.

Это в ближайшем обновлении будет починено добавлением опции в настройках модуля Обмен данными.
Почему-то Мой склад описание передает в реквизите "Полное наименование", что весьма и весьма необычно.