Идеи пользователя

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

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

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

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

Если установлен совместный показ разделов и элементов ИБ, в списке  сейчас создание раздела происходит через выпадающее меню по стрелке. Это  очень неудобно, если нужно создать несколько разделов.
Зачем сделана такая экономия - непонятно. На экране FullHD места много.

Режим "совместный" - значит нет "главенства" элементов или разделов.
Предлагаю сделать кнопку отдельной.

Или как-то настраиваемой, как и режим отображения.

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

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

Речь про \Bitrix\Iblock\InheritedProperty\SectionValues() и \Bitrix\Iblock\InheritedProperty\ElementValues()

Странно, но в секциях инфоблока нет системного поля "теги".
просьба добавить его.

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

ЧПУ умного фильтра не работает в компоненте новостей.
Все потому, что при обработке ЧПУ в файле component.php комплексного компонента news ничего неизвестно о шаблоне пути #SMART_FILTER_PATH#.
Т.е. компонент не в курсе, что шаблон может содержать разделитель "/".
Решается все добавлением 1 строки в место, где компонент определяет $componentPage:

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

К примеру у производителя товара есть дистрибьютеры и у дистрибьютеров есть разные отделы, нам необходимо вывести контакты этих отделов, для этого приходится создавать отдельных инфоблок и делать привязку по элементу, вместо того чтобы создать составное свойство и указать для него поля "название отдела", "телефон", "e-mail".

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

Есть пример решения http://marketplace.1c-bitrix.ru/solutions/simai.complexprop/ , он работает адекватно, но хотелось бы чтобы свойства добавленные в составное свойство, не были видны пользователю при редактировании элемента.

нужен фильтр по торговым предложениям (например "SKUFILTER_NAME"=>"arrSKUFilter"), чтобы можно было отображать в каталоге только нужные предложения в товарах, как это можно сделать через API - CCatalogSKU::getOffersList

Создать возможность менять наименования стандартных полей инфоблока в таблицах списков. На данный момент в карточке редактирования элемента наименования полей и свойств можно настроить как угодно, но в общем списке эта возможность до сих пор не реализована. Речь идёт именно о стандартных полях: картинка для анонса, наименование, превью, детальный текст и т.п.

Без этого происходит путаница. Часто инфоблоки создаются совсем для иных целей, как справочники. Яркий пример - слайдер. Обычно нужны только поля Наименование (для описания слайда) и предварительное фото - сам слайд. При этом они должны быть соответственно подписаны, например "Название слайда" и "Слайд", чтобы сторонний пользователь (только первый раз зашедший в админку) сразу всё понял.  

В карточке элемента возможно удалить всё ненужное и поменять названия полей, а вот на странице списка можно только убрать всё ненужное и сделать правильную сортировку. Изменить названия полей нельзя. И картинка слайдера так и останется "Картинкой для анонса". В результате человек в карточке элемента видит одно, а на странице списка совсем другое. И это ещё не самый худший вариант.

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

В связи с блокировкой в Украине сервисов Яндекса, прошу рассмотреть возможность добавления второго альтернативного внешнего сервиса для перевода символьного кода заголовков элементов и разделов инфоблоков.
Или, как вариант, если возможно, сделать перевод на стороне сервера (чаще всего они заграницей и под блокировку не подпадают)

---
Аналогично, прошу поддержать идею Гугл-карты, как альтернативны заблокированной Яндекс-карте, на странице "Скорость сайта": https://idea.1c-bitrix.ru/24453/

ps
У меня VPN-то включен и проблемы нет, а вот у клиентов есть проблема

В /bitrix/components/bitrix/news.detail/component.php есть безусловный вызов CIBlockElement::CounterInc($arResult["ID"]);, который, в свою очередь, формирует и посылает в базу данных запрос примерно такого содержания:
UPD ATE b_iblock_element
SE T
  TIMESTAMP_X = TIMESTAMP_X,
  SHOW_COUNTER_START = ifnull(
SHOW_COUNTER_START,
now()
  ),
  SHOW_COUNTER = ifnull(SHOW_COUNTER, 0) + 1
WHERE
  ID = 6515


Таким образом, в таблице b_iblock_element увеличивается переменная SHOW_COUNTER.

Эта переменная далеко не всем нужна.

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

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

Предлагаю в параметры компонентов информационных блоков добавить еще один - "DISABLE_SHOW_COUNTERS". Если его значение равно „Y” – то счетчики не увеличиваются.

В /bitrix/components/bitrix/news.detail/component.php оборачиваем в условие вызов метода увеличения счетчкика. Код получится следующий:

if (!(array_key_exists("DISABLE_SHOW_COUNTERS", $arParams) && ($arParams["DISABLE_SHOW_COUNTERS"]=="Y";)))
{
          CIBlockElement::CounterInc($arResult["ID"]);
}

В шаблонах, там, где идёт наследование параметров, добавляем и этот параметр. Например, в detail.php, там, где идёт следующий код
<?$ElementID = $APPLICATION->IncludeComponent(
   "bitrix:news.detail",
   "",
   Array(
"DISPLAY_DATE" => $arParams["DISPLAY_DATE"],


добавляем наш новый параметр:

"DISABLE_SHOW_COUNTERS" => $arParams["DISABLE_SHOW_COUNTERS"],


а также добавляем его в те места нашего кода, где мы вызываем компонент информационных блоков, например в

   <?$APPLICATION->IncludeComponent(
   "bitrix:news",

добавляем

"DISABLE_SHOW_COUNTERS" => "Y",




Поддержка нового параметра проблем совместимости со старым кодом не вызвала, доработка кода – минимальная, а выигрыш – существенный: избавились от ненужного обращения к базе, тем более не просто обращения, а операции записи. Это, помимо прочего, удлинит жизнь SSD-дисков

Например, добавлять: ". Страница N из NN" в title. По аналогии и в description.