Сейчас параметр ROWS в настройках своего компонента .parameters.php отвечает только за тип - если он больше 1 будут TEXTAREA но сам не передается при создании:
передаются только cols и т.д.
Просим добавить rows при создании
if(param.ROWS > 1)
{
container.appendChild(BX.create("TEXTAREA", {
props: {cols: param.COLS,name: name, value: value, id: propId},
attrs: {'data-bx-property-id' : param.ID, 'data-bx-comp-prop' : true}
})).oncha nge = BX.proxy(this.OnChageParams, this);
} |
Просим добавить rows при создании
props: {rows: param.ROWS, ...},
|
По заголовку уже все понятно. В catalog.element добавили возможность выводить неактивные элементы, а про news.detail забыли.
Пример использования: можно для администраторов выводить неактивные элементы, дабы они могли посмотреть внешний вид неопубликованных новостей на сайте. Работы на пару строк кода.
Пример использования: можно для администраторов выводить неактивные элементы, дабы они могли посмотреть внешний вид неопубликованных новостей на сайте. Работы на пару строк кода.
Ответил 
Жуков Евгений 02.12.2016 13:45:17
Жуков Евгений 02.12.2016 13:45:17
Это решается через документооборот.
Редакторы, журналисты, блогеры просят!
Заменить это:
Этим:
Дайте возможность визуальному редактору из ЖЛ писать в инфоблоки
Он крайне удобен, значительно экономит время по сравнению с существующим архаичным визуальным редактором, да и просто красив, его не стыдно встраивать в публичную часть для пользователей.
Которые вообще привыкли к редактору вконтакту и когда видят визуальный редактор битрикса..
Заменить это:
Этим:
Дайте возможность визуальному редактору из ЖЛ писать в инфоблоки
Он крайне удобен, значительно экономит время по сравнению с существующим архаичным визуальным редактором, да и просто красив, его не стыдно встраивать в публичную часть для пользователей.
Которые вообще привыкли к редактору вконтакту и когда видят визуальный редактор битрикса..
Визуальный редактор подключения компонента переписывает себя в файле.
Необходимо: исключить перезапись незнакомых переменных
$APPLICATION->IncludeComponent(
"bitrix:news",
"advantages",
array(
"моя_переменная" => 1,
....
"моя_переменная" должна сохраниться, это позволит использовать один шаблон но с разными "метками"(переменными), например новости на главной и новости на странице новостей отличаются совсем чуть-чуть(например шрифт, размер картинок). Т.к. вызовы компонента на разных страницах, и чтобы не создавать разные шаблоны и не проверять какой текущий url можно просто передать переменную, как отображать элементы.
НО: при редактировании компонента в визуальном редакторе он затирает все мои переменные. Уверен можно усложним алгоритм перезаписи компонента упростить работу программиста!
Надеюсь понятно изложил идею(столкнулся с такой проблемой)
Необходимо: исключить перезапись незнакомых переменных
$APPLICATION->IncludeComponent(
"bitrix:news",
"advantages",
array(
"моя_переменная" => 1,
....
"моя_переменная" должна сохраниться, это позволит использовать один шаблон но с разными "метками"(переменными), например новости на главной и новости на странице новостей отличаются совсем чуть-чуть(например шрифт, размер картинок). Т.к. вызовы компонента на разных страницах, и чтобы не создавать разные шаблоны и не проверять какой текущий url можно просто передать переменную, как отображать элементы.
НО: при редактировании компонента в визуальном редакторе он затирает все мои переменные. Уверен можно усложним алгоритм перезаписи компонента упростить работу программиста!
Надеюсь понятно изложил идею(столкнулся с такой проблемой)
Ответил
Жуков Евгений 29.01.2016 16:59:22
Жуков Евгений 29.01.2016 16:59:22
Визуальный редактор сохраняет только те переменные, что описаны в .parameters.php компонента и шаблона. Вам необходимо описать ее в .parameters.php шаблона. Если этого не сделать - ее значение может не повлиять на идентификатор кеша компонента, что приведет к ошибкам в отображении.
Находясь в папке шаблона компонента хотелось бы иметь возможность быстро создавать типовые для шаблона файлы:
.parameters.php
result_modifier.php
component_epilog.php
style.css
script.js
.parameters.php
result_modifier.php
component_epilog.php
style.css
script.js
Сделать постраничную навигацию в компоненте catalog.section.list 
Давно пора!
Давно пора!
Предлагаю передавать ошибки в шаблон вывода ошибок, при его наличии в папке шаблона ткущего компонента, а не выводить компоненту самостоятельно.
Таким образом наличие ошибок можно гибко использовать в публичной части сайта. А не тупо выводить сообщение со стилями.
Таким образом наличие ошибок можно гибко использовать в публичной части сайта. А не тупо выводить сообщение со стилями. Сделайте, наконец, штатный функционал некешируемых областей в шаблонах компонентов.
Сейчас у вас есть функции CMain:: ShowViewContent и CMain::AddViewContent. Но они работают только в направлении (как я понял) шаблон компонента -> шаблон сайта.
Хотелось бы, чтобы оно работало в рамках шаблона компонента.
То есть, например, в template.php вставляли ShowUncachedContent("uncache");
А в component_epilog.php (или в любой другой некешируемой части сайта) задавали контент этой некешируемой области через SetUncachedContent("uncache");
Типичная задача: показывать на странице товара в интернет-магазине "Купить" или "Уже в корзине" в зависимости от статуса товара.
Сейчас у вас есть функции CMain:: ShowViewContent и CMain::AddViewContent. Но они работают только в направлении (как я понял) шаблон компонента -> шаблон сайта.
Хотелось бы, чтобы оно работало в рамках шаблона компонента.
То есть, например, в template.php вставляли ShowUncachedContent("uncache");
А в component_epilog.php (или в любой другой некешируемой части сайта) задавали контент этой некешируемой области через SetUncachedContent("uncache");
Типичная задача: показывать на странице товара в интернет-магазине "Купить" или "Уже в корзине" в зависимости от статуса товара.
Как известно, параметры полей в файле .parameters.php шаблона задаются через массив $arTemplateParameters, в том время как в файле .parameters.php компонента поля задаются через массив $arComponentParameters['PARAMETERS'].
Однако группы в файле .parameters.php шаблона переопределить уже нельзя. Хочешь — не хочешь, а придется использовать те, что были заданы в .parameters.php компонента.
Это создает неудобства при разработке. В результате дополнительные параметры, отвечающие за совершенно разные настройки (!!!), которыми разработчик снабжает шаблон, как правило вынужденно сваливаются в общую группу ADDITIONAL.
Особенно актуально для комплексных компонентов. Например, когда в настройки комплексного компонента forum на уровне шаблона включаются дополнительные настройки для использования своих или сторонних компонентов:
- использование закладок для сторонних соцсетей;
- обратные ссылки на ссылающиеся элементы инфоблоков (при обсуждении какого-либо элемента в форуме);
- отображение всех публикаций по заданному тегу (темы форумов, форумы, группы форумов, элементы и группы разных инфоблоков, сообщения блогов, блоги, соцсети и т. д.);
и т. д.
Однако группы в файле .parameters.php шаблона переопределить уже нельзя. Хочешь — не хочешь, а придется использовать те, что были заданы в .parameters.php компонента.
Это создает неудобства при разработке. В результате дополнительные параметры, отвечающие за совершенно разные настройки (!!!), которыми разработчик снабжает шаблон, как правило вынужденно сваливаются в общую группу ADDITIONAL.
Особенно актуально для комплексных компонентов. Например, когда в настройки комплексного компонента forum на уровне шаблона включаются дополнительные настройки для использования своих или сторонних компонентов:
- использование закладок для сторонних соцсетей;
- обратные ссылки на ссылающиеся элементы инфоблоков (при обсуждении какого-либо элемента в форуме);
- отображение всех публикаций по заданному тегу (темы форумов, форумы, группы форумов, элементы и группы разных инфоблоков, сообщения блогов, блоги, соцсети и т. д.);
и т. д.
Дать возможность для компонента включаемой области изменять заголовок, который выводится в режиме редактирования в контекстном меню компонента.
Сейчас для всех областей заголовки одинаковы "Изменить область".
Иногда приходится несколько включаемых областей размещать на страницы комплексного компонента и тогда это превращается вот в такую неприятность:
Было бы более "юзерфрендли" делать заголовки типа "Изменить логотип", "Редактировать блок контактов", "Изменить телефон" и т.д.
Можно дополнительным параметром в компонент передавать этот заголовок.
ПС. Ну и для "Добавить область" такая же история.
Сейчас для всех областей заголовки одинаковы "Изменить область".
Иногда приходится несколько включаемых областей размещать на страницы комплексного компонента и тогда это превращается вот в такую неприятность:
Было бы более "юзерфрендли" делать заголовки типа "Изменить логотип", "Редактировать блок контактов", "Изменить телефон" и т.д.
Можно дополнительным параметром в компонент передавать этот заголовок.
ПС. Ну и для "Добавить область" такая же история.
Проблема заключается в том, что компонент "bitrix:catalog.section" не реагирует на фильтр, если в параметрах не передан ID/CODE раздела инфоблока. При этом не спасает даже параметр "SHOW_ALL_WO_SECTION", установленный в значение "Y", хотя пару лет назад это решение работало.
Собственно, эта логика прослеживается в исходном коде компонента "bitrix:catalog.section", но такое поведение компонента является неоправданным и усложняет разработку проектов. Объективной необходимости проводить проверку наличия ID/CODE раздела до обработки фильтра нет: эти вещи не являются взаимоисключающими. При этом фильтр по всем элементам (без указания разделов) заказчики требуют довольно часто, и каждый раз кастомизировать компонент - не очень хороший выход.
Предлагаю либо довести компонент "bitrix:catalog.section" до ума, либо создать аналогичный компонент, не требующий жесткого указания раздела. Например, его можно назвать "Элементы инфоблока".
P.S. В поддержке проблемой это признать отказались. В принципе, их можно понять, но разработчикам от этого не легче.
Собственно, эта логика прослеживается в исходном коде компонента "bitrix:catalog.section", но такое поведение компонента является неоправданным и усложняет разработку проектов. Объективной необходимости проводить проверку наличия ID/CODE раздела до обработки фильтра нет: эти вещи не являются взаимоисключающими. При этом фильтр по всем элементам (без указания разделов) заказчики требуют довольно часто, и каждый раз кастомизировать компонент - не очень хороший выход.
Предлагаю либо довести компонент "bitrix:catalog.section" до ума, либо создать аналогичный компонент, не требующий жесткого указания раздела. Например, его можно назвать "Элементы инфоблока".
P.S. В поддержке проблемой это признать отказались. В принципе, их можно понять, но разработчикам от этого не легче.
Ответил
Жуков Евгений 01.09.2014 14:43:43
Жуков Евгений 01.09.2014 14:43:43
Компонент применяет фильтр, даже если раздел не найден (считается, что идет работа с корневым разделом).
Появляется много сторонних модулей и компонентов на маркетплейс. Разбираться с логикой работы каждого и держать это в голове становится все труднее. Предлагаю:
Добавить в файл описания модуля или компонента .description.php поля описания компонента для разработчиков, доступные в интерфейсе.
Либо класть в папку компонента файл с описанием для разработчиков типа read.me
Добавить в файл описания модуля или компонента .description.php поля описания компонента для разработчиков, доступные в интерфейсе.
Либо класть в папку компонента файл с описанием для разработчиков типа read.me
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
