Можно последовательно несколько раз указать один и тот жей шаблон с разными условиями.
Если стандартных условий не хватает, то можно вынести свою логику в функцию или метод класса, где возвращаеться булово значение, и в условие шаблона указать "Выражение PHP" и вызов вашей функции/метода.
Если код с логикой короткий, то можно его написать сразу же в этом поле, вместо вынесения отдельно.
Читаю код импорта, по сути поле звучит "IPROPERTY_TEMPLATES" В csv формате его обработки нету и по сути это поле передаеться напрямую в CIBlockElement::Update или CIBlockElement::Add Но там ожидаеться ассоциативный массив. Если бы парсер имел преобразования строки например из json в csv поля то могло бы выйти.
Но в коде для xml импорта вижу такой функционал. Собственно, потестил, все работает, и файле есть соотвествующие теги
Код
...
<НаследуемыеШаблоны>
<Шаблон>
<Ид>ELEMENT_META_TITLE</Ид>
<Значение>Шаблон META TITLE</Значение>
</Шаблон>
<Шаблон>
<Ид>ELEMENT_META_KEYWORDS</Ид>
<Значение>Шаблон META KEYWORDS</Значение>
</Шаблон>
<Шаблон>
<Ид>ELEMENT_META_DESCRIPTION</Ид>
<Значение>Шаблон META DESCRIPTION</Значение>
</Шаблон>
<Шаблон>
<Ид>ELEMENT_PAGE_TITLE</Ид>
<Значение>Заголовок элемента</Значение>
</Шаблон>
</НаследуемыеШаблоны>
...
Также вижу заведен функционал и для разделов и даже для инфоблока.
Создание копии сайта в облако 1с-Битрикс не работает
Да, RegisterTag гараздо красивей решение, в теге укажите id сущности для которой делаеться выборка комментариев, что бы не сбрасывался весь кеш каталога, при добавлении(изменении/удалении) коммента к любому товару. Хотя не уверен в производительности, когда у вас будет столько же тегов сколько товаров(1к/10к/100к/и более)
Кеширование, Как мне свой вывод материалла пустить в обход кеша страницы?
Минимизация вывода html довольно глупая затея, так как вебсервер имеет потоковое зжатие для текстового контента. По крайне мере вебсервер здорового человека.
Экономить трафик нужно явно не в этом месте.
Кеширование, Как мне свой вывод материалла пустить в обход кеша страницы?
template.php кешируеться и точка, то есть он выполняеться один раз и все. Следственно Ваш код с комментариями должен быть в другом файле.
Вариантов валом например component_epilog.php. Да, он выполняеться после шаблона, но всегда.
Если ваш виджет не может идти после страницы, и должен быть в самой странице. То например в component_epilog.php может быть json с комментами. А ваш JS рендерит виджет на основе этого json. Но это не индексируеться, а желательно комменты индексировать с микроразметкой для расширенных снипетов поиска.
Например, Вы можете в template.php использовать свой тег свободной формулировки например "<mycomments/>" или "%MY_COMMENTS%". Желательно что-то невидимое в случае сбоя. и заключить вызов самого компонента в ob_start(); ob_get_clean(); конструкцию с последующим str_replace("%MY_COMMENTS%", "html моего виджета", ob_get_clean()). Не знаю на сколько это канонично, на производительности не заметно и утечек памяти нету.
ajax после загрузки страницы считаеться нормальным, но мне не нравиться это решение, так как таких динамических областей бывает дофига, миникорзина, сравнение товаров, голосовалки, избранное и тд. А когда это множество виджетов собираеш в некую единую красивую и оптимизированную систему, то уже пишеш свой фреймверк, а там уже и до angular не далеко. Плюс это все таки нагрузка на пхп, а не nginx статика. Смысла я в этом вообще не вижу. Но все же это считаеться нормальным...
И все же выборку комментов желательно кешировать (или автокешировать в терминалогии битрикса). Что бы был сброс кеша при изменениях в таблице. И снова рекомендую использовать встроенные orm, он имеет свой функционал кеширования выборок из таблицы со сбросом при добавлении, обновлении и удалении
--- Не понятно как предлогаеться применить отложенные функции, ведь в \CBitrixComponentTemplate нету метода ShowViewContent. Из кешируемого компонента можно только захватить вывод через $this->SetViewTarget('MyComponentOutput'); ?>My html code <? $this->EndViewTarget(); и например в component_epilog.php этот вывод получить $APPLICATION->GetViewContent('MyComponentOutput');
Не вижу практического применения фишки.
Цитата
Из документации: Отложенные функции нельзя использовать в файлах шаблона компонента: template.php и result_modifier.php (так как результаты их выполнения кешируются).
Как хранить большое количество характеристики товара?
8000 свойств, это очень большой перебор, 500 это уже перебор. В рамках битрикса полюбому нужно разбивать на отдельные инфоблоки. Если прям нужен один инфоблок, то нужна другая модель данных, не стандартное решение из учебника.
Тут много решений на самом деле. На вскидку 1) Хранить часть свойств в одном свойстве строка(или в отдельной таблице), как json. В шаблонах каталога просто декодировать и выводить табличку. Минус в том что нужно делать интерфейс редактирования и нет возможности фильтрации, кроме как полнотекстового поиска.
2) Хранить в отдельных таблицах. В Связном на сколько помню были свои таблицы типов товаров, таблицы со свойствами и значениями. В админке они добавили выбор типа товара, и им подгружалась соответсвующая форма редактирования именно для этого типа товара. Я не работал со связным, это они расказывали на какой то конференции(ролик в гугле).
--- На этих цифрах вам полюбому нужно уходить от стандартных свойств битрикса. Я как правило в таких случаях делаю отдельные таблицы, но тут сложность скорей в разработке интерфейса для контенщиков, обычно есть куча тонкостей по нормализации, валидации, плюс синхронизации с кучи разных баз.
Кеширование, Как мне свой вывод материалла пустить в обход кеша страницы?
almi_dev:news.line это не стандартный компонент, по нему вас проконсультирует только сам almi_dev
Но если компонент скопирован с bitrix:news.list, то он не может получать элементы с разных инфоблоков. Если компонент скопирован с bitrix:news.line, то элементы будут общим списком (Читаю по коду, не разу не использовал)
Можно просто несколько раз вызвать компонент bitrix:news.list для разных инфоблоков.
Вообще то в настройках выгрузки в 1с можно указать структуру разделов для выгружаемых каталогов
В разных версиях модуля 1с интерфейс разный, но суть одинаковая и это очень старый функционал.
В каменные века, когда этой фишки не было я делал обработчик, которые не давал перенос элементов по разделам для юзера 1с. И сортировкой элементов по разделам занимался контенщик. Но это на малом количестве товаров и снова же сейчас так делать мало смысла.
Василий написал: картинка сильно увеличивается и не помещается полностью в экран
Это явная ошибка шаблона компонента страницы товара, скрипт должен маштабировать картинку под размер экрана посетителя. Решаеться программистом или ТП конторы которая поставила вам этот шаблон.
"Уменьшать, если большая" в настройках инфоблока, обычно используються для защиты от сверх гиганских картинок которые используют фотографы, одна фотка может быть 20 метров и более 8000 пиксилей по обоим сторонами. И это правило используеться только один раз, в момент загрузки картинки на сайт, потом вообще не на что не влияет.
Генерация картинки для анонсов как правило не нужна. Это устаревший функционал, который не убирают из за совместимости с текущеми проктами. В шаблонах каталога миниатюры должны генериться из детальной на лету. Само поле элемента "Картинка для анонса" нужно только, если картинка анонса должна отличаться от детальной(не по размеру а по контенту).
Кеширование, Как мне свой вывод материалла пустить в обход кеша страницы?
1) У Вас свои комменты, в своей таблице? Расмотрите использование ORM
2) Именование переменных и функций желательно делать более осмысленным.
getComment -> getCommentsForElement Получение множества комментов, а не одного, и комменты могут быть для разных сущностей. Также желателно вынести свой функционал в свой namespace
имя $key обычно используют в для ключей массива, например foreach ($arElementComments as $key => $arElementComment){
3) Все загружаемые файлы желательно вынести в upload, что бы вышло /upload/avatars/ Если файлы генерируються как кеш или миниатюры, их можно без вреда удалить и они не нужны в резервной копии, то в /upload/tmp/
4) Что бы ваш код не кешировался, то он должны быть в не кешируемом файле, ваш кеп. например в component_epilog.php
Стили суб-компонента не подгружаются после кеширования.
В bitrix:catalog нету кеширования как такового, настройки кеша компонента передаються дочерним компонентам, например в bitrix:catalog.section, но в самом bitrix:catalog не используються. Там просто нету кода который использовал бы кеш. Это просто контролер/маршрутизатор.
$APPLICATION->showHead() используеться в общем шаблоне сайта в файле header.php. Этот код в 99.9% случаев не нужно трогать. Да, этот метод должен собирать и выводить css и js файлы в head. Так и задумано.
script.js и style.css в папках шаблонов компонентов подключаються автоматом не зависемо от кеша. Если у вас компонент вызываеться из кешируемого шаблона другого компонента, то нужно также передавать обьект родительского компонента в четвертый аргумент метода IncludeComponent.
Сравните phpinfo для рабочего и одного из нерабочих вариантов. И напишите используемые версии php и версию битрикса. На проде у вас вижу PHP/5.6.32, не должно быть проблем. Проверьте настройки mbstring, раз у вас UTF-8. Желательно не экспериментировать на проде
--- Смотрите именно в phpinfo что бы было mbstring.func_overload = 2 mbstring.internal_encoding = UTF-8
Крайне плохая идея класть в корень сайта компонент с ЧПУ. Может быть вам лучше на главной catalog.section сделать? Если вам нужен целый каталог или разные каталоги в разных дизайнах для обработки ссылок всего инфоблока, то лучше это делать в подразделах, что бы не конфликтовало адресное пространство. А на главной уже выводить catalog.section или news.list или подобные без чпу обработки.
--- Думаю у вас проблема не с модулем как способом подключения php, а с самой версией php. Похоже что у вас не генерируються транслитерация кодов для разделов и товаров. У меня было именно так и именно из за смены версии php, но самих версий не помню.
bitrix;catalog не кешируеться, ваши стили не подгружаються по другой причине.
Описанного бага очень давно нету.
Возможно вы подключили файл стилей в коде шаблона меню, тогда стили не будут подключаться при выводе из кеша. Ваши стили должны быть в style.css рядом с template.php, тогда они подхватяться автоматом. Или должны быть подключены в component_epilog.php, если имя и расположение файла вас не устраивает.
ЧПУ для карточки товара: отвязать URL от категории
Может передадут вес, а может нет. Кто вам даст гарантии? Я не дам. Сеошники если и дают гарантии, то компенсацию фиг выбьеш. Раскидают лопши по ушам и сольються. Если у вас классический магазин/ветрина, то скорее всего 99% ссылок сайла это товары, и когда Вы их резко переадресуете на новые страницы, то старые уходят из поиска, а новые проиндексируються только через какое то время. А это как правило месяца. То есть на месяца у вас проект просто умер. Ну восстанавливаеться, ага, но это потери, не полученная прибыль, плюс расходы на рекламу то не пропадают же.
У меня под контролем топовых СЕО студий переезд отдельного подраздела, ну примерно скажем 5% от массы, все равно заметные просадки всего сайта, в том числе по запросами напрямую не связанных по ключевым словам.
Выбор шаблона ссылок один из самых важных и недооцененных моментов для интернет магазина. На сайте можно любую аварию срочно исправить, а вот поисковая индексация лечиться архидолго.
То есть в "Детальная информация" нету "/catalog/".
Плюс шаблон для раздела не должен пересекаться с товарами и должен быть типа section/#SECTION_CODE#/#SECTION_ID#/
---
Я бы не рекомендовал такие шаблоны, и обратите внимание, что если потом передумаете и выберете другие шаблоны, это Вам будет стоить очень дорого
Главный косяк шаблона в том что, метрика и поисковики могут подумать, что у вас есть некий раздел item/#ELEMENT_CODE#/, а в нем уже лежит item/#ELEMENT_CODE#/ELEMENT_ID#, хоть первый и не индексирумый.
Слешами указывают вложеность разделов/страниц, и поисковики это хорошо хавают.
ЧПУ для карточки товара: отвязать URL от категории
То что Вы хотите реализовать - элементарно. Шаблон нужно поменять в двух местах в настройках инфоблока и в настройках компонента в разделе catalog. На память не помню код шаблонов ASPRO, но врятли они так наложали что бы вы не могли сделать такие шаблоны.
#ELEMENT_CODE# Не фига не уникальный, вам понадобиться замарочиться, что бы следить за уникальностью, возможно дописать немного кода, зависет от интеграций со стороними базами и контенщиков. Как минимум менять коды вручную если названия у товаров одинаковые. Мои контенщики даже и не емеют доступа к редактированию кода элементов и разделов.
Вложеность в разделы, а также полный путь разделов рекомендуеться всеми сеошниками с которыми я работал. Также некоторые средства аналитики могут понимать вложеность чисто по ссылке. Товар может лежать в двух местах, но каноническая ссылка одна. Я как правило делаю переадресации с неканонических ссылок. Есть самаю малость продвинутый маневр, в полном и длинном шаблоне ссылки использовать только ELEMENT_ID, а ELEMENT_CODE игнорить и если коды или раздела или элемента поменялись, то переадресовать на правильную(каноническую) ссылку.
Если вам нужны короткие ссылки для публикаций в стороних сайтах, используйте функционал коротких ссылок, хотя для продвижения наверно не очень. Если прям надо совсем короткие и прям как в основе каталога, то можно #SITE_DIR#catalog/e-#ELEMENT_ID#/, но крайне сомнительная затея.
Кстате, кстате, на прошлом проекте который я переделывал после "опытного разработчика" было так, что файловый кеш уперся в лимит индексных дескрипторов хостинга. Потому что понаделал кучу бесполезных и тормазнутых меню и не настроил мемкеш.
В документации надо красным текстом добавить, что перед сдачей проекта надо проверить работу всех функций сайта с включенным кешом, а не включать кеш после сдачи и смататься. Выключайте кеш наздоровье, но надо знать как он работает. Начинающему проще его не выключать впринципе.
Да, действительно в официальной документации есть вредные советы
На практике выходит, что начинающие разрабы прочитав только одну надпись а не пройдя весь курс тупо забивают на производительность и могут оставить выключеным кеш как компонентов так и глобально, ведь работает же и так... С включенным кешем на этапе разработки может всплыть куча косяков, которые после релиза будет накладно срочно исправлять.
Очень вредный совет, некогда не отключайте кеширование, эта фишка например для аварий на продакшене, когда в кеш записываеться то что не должно, например не учитываються права пользователя и анониму показываеться контент для админа. Вести разработку с отключенным кешем а потом включать тоже бесмысленно. Вы же должны видеть за сколько выполняеться компонент или страница, сколько запросов в базу делаеться. У вас запросто может получиться так, что кеширование включено, но каждый хит мимо кеша.
