Идеи для: Информационные блоки

Рейтинг: 0.6551  
На голосовании
Предложил Дмитрий 25.05.2017 11:07:40

Выбор resizeType в настройках инфоблока

При загрузке PREVIEW_PICTURE  и DETAIL_PICTURE нельзя указать тип масштабирования:
  • BX_RESIZE_IMAGE_EXACT
  • BX_RESIZE_IMAGE_PROPORTIONAL
  • BX_RESIZE_IMAGE_PROPORTIONAL_ALT
Было бы очень удобно, если бы эти функции появились в новых обновлениях. Сейчас приходится использовать события.
Рейтинг: 0.5935  
На голосовании
Предложил Ирбис Александр 13.05.2017 13:57:58

При создании иб проставлять привязку к сайту автоматически

если сайт один,
чтобы не было ошибки "Не введена привязка к сайту"


в интерфейсе админа
постоянно с первого раза не могу сохранить иб
Рейтинг: 28.7379  
На голосовании
Предложил Клочков Илья 10.05.2017 03:07:14

Поддержка загрузки svg

Сейчас Bitrix не поддерживает загрузку файлов в svg формате для детальных картинок разделов, просьба внедрить , создавал обращение (прошло пол года - действий 0)



Номер обращения в разработку: 44135
Рейтинг: 0.5818  
На голосовании
Предложил Masiutin Maxim 05.05.2017 16:15:21

Warning! Cloaking! Не возвращается rss-лента форума поисковикам - важно возвращать

Исохдя из того, что RSS лента может быть довольно объемной, а хиты поисковиков - очень частыми, разработчики системы "Битрикс Управление Сайтом" намеренно сделали такое ограничение, что поисковикам не возвращается RSS.

Нет никакой опции изменить это поведение.

Проблема усугубляется тем, то вместо XML-содержимого RSS (хотя бы пустой XML-заглушки), поисковик получит пустую страницу, содержащую лишь site header & footer в формате html.

Это крайне вредная практика, т.к. поисковики не приветствуют, когда им возвращают одну информацию, а обычным пользвателям - другую. Это может быть расценено поисковиком как cloaking ( https://en.wikipedia.org/wiki/Cloaking ) и сайт может получить вечный бан.

Обращения поисковиков к RSS можно запретить через /robots.txt - указать там URLы или маски, и тогда поисковики не будут обращаться к RSS вообще.


В файле /bitrix/components/bitrix/forum.rss/component.php есть такой код

if (empty($arResult["FORUMS"]) || ($_SESSION["SESS_SEARCHER_ID"] > 0 && CModule::IncludeModule("statistic";))):
return false;

Таким образом, обычные пользователи могут подписываться на обновления RSS на форумах, например на https://www.ritlabs.com/en/forums/rss/rss2/forum/0/

Но если к этому URL обратится поисковик, который зарегистрирован у нас в списке поисковиков (Рабочий стол - Аналитика - Поисковики - Индексация - Список)

то вместо XML-содержимого RSS, поисковик получит пустую страницу, содержащую лишь site header & footer в формате html.


Я решил эту проблему для себя так: закоментировал сравнение на предмет поисковика. Стало так:

в файле /bitrix/components/bitrix/forum.rss/component.php есть такой код

if (empty($arResult["FORUMS"]) /*|| ($_SESSION["SESS_SEARCHER_ID"] > 0 && CModule::IncludeModule("statistic";))*/):
return false;

... но при обновлении Битрикс это может создать проблемы.

Необходимо внести это изменение в стандартный код Битрикс Управление Сайтом.

Аналогичный код есть и в /bitrix/modules/forum/include.php, там тоже идёт сравнение на поисковик перед авторизацией.

Также есть сравнение на поисковики при показе баннеров - там тоже безусловно вырезаются баннеры поисковикам - это граничит с cloaking.

Можно добавить параметр вызова $APPLICATION->IncludeComponent("bitrix:forum", который бы указывал отдавать rss поисковикам, или нет, например:

<?$APPLICATION->IncludeComponent("bitrix:forum","",Array(
      "DISABLE_RSS_FOR_SEARCH_ENGINES" => "N",

(по умолчанию этот параметр можно сделать"Y", чтобы сохранить существующую функциональность) , а кому НУЖНо отдавать RSS поисковикам, передаст "N".
Рейтинг: 0.5278  
На голосовании
Предложил Masiutin Maxim 05.05.2017 16:09:10

Поддержка параметра SET_LAST_MODIFIED во всех типах информационных блоков и в форумах

У комплексного компонента Новости "bitrix:news" есть очень полезный параметр SET_LAST_MODIFIED, который возвращает страницу с уже установленным заголовком Last-Modified. В этот заголовок он записывает самое последнее время и дату самого свежего элемента, отображенного на странице, будть то список элементов или один элемент. Заголовок Last-Modified позволяет разгрузить сайт следующим образом: если страница не изменилась, можно возвращать не всю страницу целиком, а лишь ответ not-modified, если клиент прислал If-Modified-Since, а также можно использовать reverse-proxy на сайте для кеширования динамических страниц публичного резела, чтобы не формировать их повторно системой Битрикс, а быстро отдавать из прокси.

К сожалению, для других типов информационных блоков (FAQ, и т.п.) не реализован параметр SET_LAST_MODIFIED и не устанавливается Last-Modified. Через шаблоны просто так Last-Modified не установишь, поскольку если шаблон сформировал странцу, которая попала в управляемый кеш, то эти данные не выполнятся, не установится Last-Modified. Поэтому надо устанавливать Last-Modified не из шаблона, а из компонента. Копироавть компонент в пространство имён не хочется, т.к. при обновлении продукта Битркс Управление сайтов возникнут вопросы по обновлению скопированного компонтента - он останется старым.

Будет замечатьельно для всех типов информационных блоков (FAQ, и т.п.) иметь поддержку параметра SET_LAST_MODIFIED, а также имть её поддержку для форумов.
Рейтинг: 1.2229  
На голосовании
Предложил Masiutin Maxim 04.05.2017 19:29:52

Ускорить отображение списка элементов информационного блока за счет устранения запроса текста детального просмотра

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

 

Текст детального просмотра целиком нужен лишь при детальном отображении лишь одного элемента новости. Когда мы выводим спискок элементов, например список новостей, то весь текст детального просмотра не нужен, а нужен лишь признак его наличия, чтобы принять решение, отобразить ли URL на детальный просмотр.
Однако, при формировании списка, из базы одним запросом извлекаются все тексты детального просмотра всех элементов, отображаемых на экране. Это приводит не только к излишней перекачке данных, но и забивает большими размерами кеш SQL-запросов MySQL.
Проблема усугубляется тем обстоятельством, что нет никакого параметра, который бы позволял избежать загрузки текста детального просмотра при формировании списка.

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



Изменяем /bitrix/components/bitrix/news.list/component.php

Там есть список принудительно добавляемых параметров. Ищем такую строку
$arSelect = array_merge($arParams["FIELD_CODE"], array(
из этого списка убираем  "DETAIL_TEXT" и "DETAIL_TEXT_TYPE"

после этого списка добавляем такой код:

   if ($arParams["LIST_CHECK_DETAIL_TEXT_PRESENCE_ONLY"]=="Y";)
   {
$arSelect[]="HAS_DETAIL_TEXT";
   } else
   {
$arSelect[]="DETAIL_TEXT";
    $arSelect[]="DETAIL_TEXT_TYPE";
   }

То есть при наличии LIST_CHECK_DETAIL_TEXT_PRESENCE_ONLY == Y, будем запрашивать только признак, иначе – как раньше, по старой схеме, целиком текст.

Мы добавили запрос нового вычисляемого поля HAS_DETAIL_TEXT – осталось ввести его поддержку.

В /bitrix/modules/iblock/classes/mysql/iblockelement.php, там где идёт перевод названий параметров в названия колонок базы данных, добавляем такую строчку после «"DETAIL_TEXT_TYPE"=>"BE.DETAIL_TEXT_TYPE",»:

"HAS_DETAIL_TEXT"=>"((BE.DETAIL_TEXT IS NOT NULL) AND (BE.DETAIL_TEXT<>''))",

Во всех наших шаблонах, где есть примерно такой код:
   <?if(!$arParams["HIDE_LINK_WHEN_NO_DETAIL"] || ($arItem["DETAIL_TEXT"] && $arResult["USER_HAVE_ACCESS"])):?>
 <h3>"><?echo $arItem["NAME"]?></h3>
  <?else:?>
просто заменяем "DETAIL_TEXT" на "HAS_DETAIL_TEXT"

также в файлах, которые передают параметры шаблонам (news.php), добавляем передачу нашего параметра:
   "LIST_CHECK_DETAIL_TEXT_PRESENCE_ONLY" => $arParams["LIST_CHECK_DETAIL_TEXT_PRESENCE_ONLY"],

И при вызове комплексного компонента новостей, также указываем наш параметр:

   "LIST_CHECK_DETAIL_TEXT_PRESENCE_ONLY" => "Y",

простое и надёжное изменение привело к существенному повышению производительности, уменьшило скорость формирования списка новостей, и самое главное, разгрузило кеш базы
Рейтинг: -0.0075  
Новая
Предложил Masiutin Maxim 04.05.2017 18:22:26

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

В /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-дисков
Рейтинг: 0.3934  
На голосовании
Предложил Masiutin Maxim 03.05.2017 16:55:26

Комплексный компонент FAQ "bitrix:support.faq" не поддерживает время начала и окончание активности записи, однако при обращении к базе MySQL идёт проверка дат - в запросе идёт вызов Now() что не даёт серверу СУБД кешировать запрос и замедляет работу

Комплексный компонент FAQ "bitrix:support.faq" не поддерживает время начала и окончание активности записи, однако при обращении к базе MySQL идёт проверка дат - в запросе идёт вызов Now() что не даёт серверу СУБД кешировать запрос и замедляет работу

Разместить здесь (http://idea.1c-bitrix.ru/) это пожелание мне посоветовал старший специалист техподдержки Свиридов Юрий, на моё обращение №1456195.

Комплексный компонент FAQ "bitrix:support.faq" ( https://dev.1c-bitrix.ru/user_help/service/support/components_2/faq/support_faq.php )
базируется на информационных блоках, а те, в свою очередь, позволяют для новостей задавать период начала и окончания отображения новости.


При этом для новостей предусмотрен параметр "CHECK_DATES". Если его задать “N”, то bitrix:news не буде проверять, вписывается ли текущее время Now() в диапазон дат активности новости. Если при вызове bitrix:news задать "CHECK_DATES" в значение “Y”, то SQL-запросы к базе будут в строке SEL ECT содержать вызов функции now().  Результаты таких запросов MySQL не будет помещать в кеш запросов MySQL Query Cache (из-за функции Now() - https://dev.mysql.com/doc/refman/5.7/en/query-cache-operation.html ) - и повторная отправка в СУБД таких запросов не будут выполняться быстрее. Поэтому, если нужна скорость, можно при вызове компонента bitrix:news задать параметру "CHECK_DATES" значение “N”, и тогда отображение новостей на сайте будет происходить намного быстрее, но не будут проверяться автоматически время активности новости.

Для компонента FAQ нельзя задать периоды активности записи, а также нельзя передать "CHECK_DATES", но при этом для отображения элементов и списков FAQ, CMS Битрикс всё равно проверяет диапазоны дат и использует функцию Now(). В отличие от новостей, вызов Now() для FAQ нельзя отключить штатными средствами. Элементы и списки FAQ не кешируются в MySQL, из-за чего отображаются медленно, даже несмотря на адаптивный кеш – запрос к базе идёт каждый раз ПЕРЕД проверкой адаптивного кеша.

Исходя из вышесказанного, учитывая, что проверка дат в FAQ не нужна, но она проводится, отключить её нельзя, и необснованно препятствуется кеширование этих завпросов в MySQL Query Cache, предлагаю считать это багом, с тем, чтобы разработчики его исправили, исключив из запросов SEL ECT при построении элементов FAQ выовы Now() и вообще сравнение времени.

Вот как я предлагаю доработать компонент информационных блоков для более полной возможности отключения проверки дат через вызов Now(), в частности, для информационных блоков. Доработать очень легко:

Добавляем передачу параметра ACTIVE_DATE в $arFilter в файлы /bitrix/components/bitrix/support.faq.section.list и /bitrix/components/bitrix/support.faq.element.list и /bitrix/components/bitrix/support.faq.element.detail

Таким образом, после добавления строчки 'ACTIVE_DATE" => ($arParams["CHECK_DATES"]=="Y";) ? 'Y' : 'N',
массив будет иметь следующий вид:

$arFilter = Array(
'IBLOCK_ID' => $arParams['IBLOCK_ID'],
'GLOBAL_ACTIVE' => 'Y',
'IBLOCK_ACTIVE' => 'Y',
'ELEMENT_SUBSECTIONS' => 'N',
'CNT_ACTIVE' => 'Y',
"ACTIVE_DATE" => ($arParams["CHECK_DATES"]=="Y";) ? 'Y' : 'N',
);

Параметр "ACTIVE_DATE" не везде поддерживался в значении “N”, надо также добавить его поддержку в /bitrix/modules/iblock/classes/mysql/iblockelement.php а также в iblockrss.php, iblock.php, iblocksection.php
Для этого надо найти все места, где есть упоминания now() или $DB->GetNowFunction() и обернуть их в сравнение ($arFilter["ACTIVE_DATE"]!="N"?, таким образом, код после обертывания в сравнение, будет примерно следущим:
".($arFilter["CNT_ACTIVE"]=="Y"?
"AND BE.ACTIVE='Y'".
($arFilter["ACTIVE_DATE"]!="N"?

" AND (BE.ACTIVE_TO >= ".$DB->CurrentDateFunction()." OR BE.ACTIVE_TO IS NULL)
AND (BE.ACTIVE_FROM <= ".$DB->CurrentDateFunction()." OR BE.ACTIVE_FROM IS NULL)
"
:"";)
:
"";)."


(в iblocksection.php таких место как минимум три)

Кроме того, в /home/site/public_html/bitrix/modules/iblock/classes/general/ во всех файлах, где есть формирование фильтра с добавлением константы "ACTIVE_DATE" => "Y", нужно также добавить сравнение:

$arFilter = array(
……………….
"ACTIVE" => "Y",
"ACTIVE_DATE" => ($arFilter["CHECK_DATES"]=="N"||$arFilter["ACTIVE_DATE"]=="N";)?"N":"Y",
);

Это изменение надо сделать во всех файлах в bitrix/modules/iblock/, в часности в /bitrix/modules/iblock/iblock.php


Как более общий случай - есть такая идея: запросы, в которых есть вызовы Now() и других функций, которые препятствуют кешированию, разбивать на два: в первом запросе мы получаем лишь ID на основе Now, а во втором запросе получаем данные на основе полученных ID. Второй запрос MySQL закеширует, а первый будет всегда выполняться очень быстро за счет индекса. Такие два запроса вместе будут выполняться намного быстрее, чем один сложный запрос, если база находится на локальной машине и временем связи с сервером можно пренебречь из-за несущественности.

Вот пример, как можно это сделать в методе GetList в /bitrix/modules/iblock/classes/mysql/iblockelement.php

Добавляем функцию проверки SQL-запроса на предмет наличия команд, препятствующих кешированию:
function query_cannot_be_cached($query)
{
 return preg_match("/\b(?:AES_DECRYPT|AES_ENCRYPT|BENCHMARK|CONNECTION_ID|CONVERT_TZ|CURDATE|CURRENT_DATE|CURRENT_TIME|CURRENT_TIMESTAMP|CURRENT_USER|CURTIME|DATABASE|ENCRYPT|FOUND_ROWS|GET_LOCK|IS_FREE_LOCK|IS_USED_LOCK|LAST_INSERT_ID|LOAD_FILE|MASTER_POS_WAIT|NOW|PASSWORD|RAND|RANDOM_BYTES|RELEASE_ALL_LOCKS|RELEASE_LOCK|SLEEP|SYSDATE|UNIX_TIMESTAMP|USER|UUID|UUID_SHORT)\b *\(/i", $query);
}



и изменяем код метода GetList:
$strSql = "
SEL ECT ".$el->sSelect."
FR OM ".$el->sFrom."
WHERE 1=1 ".$el->sWhere."
".$el->sGroupBy."
".$el->sOrderBy."
LIMIT ".$nTopCount."
";
if (query_cannot_be_cached($strSql))
{
$strSql = "
// упрощенный вариант SEL ECT – получаем только ID
SEL ECT BE.ID AS ID"."
FR OM ".$el->sFrom."
WHERE 1=1 ".$el->sWhere."
".$el->sGroupBy."
".$el->sOrderBy."
LIM IT ".$nTopCount."
";
$res = $DB->Query($strSql);
$id_array=array();
while ($row = $res->Fetch())
{
array_push($id_array, $row["ID"]);
}
if (count($id_array)>0)
{
// если вернулся хотя бы один ID, запускаем второй запрос
$strSql = "
SELECT ".$el->sSelect."
FR OM ".$el->sFrom."
WH ERE BE.ID IN (".implode(',', $id_array).";)"."
";
$res = $DB->Query($strSql);
} else
{
// just return that $res
}
} else
{
// если в запросе нет вызовов функций, препятствующих кеширвоанию такого запроса на сервере, то отправляем его целиком как есть
$res = $DB->Query($strSql);
}


Убедиться в том, что запросы с NOW() не кешируются, можно следующим образом:
1.       В MySQL должен быть разрешен кеш запросов (show global status like 'Qcache_inserts' должен возвращать результат больше нуля)
2.       В модуле „Производительность» (монитор производительности) включите запись SQL-запросов («Вести журнал SQL запросов») – «включить монитор».
3.       Затем на сайте из публичного обратиться к справочнику (FAQ) – должен сработать код $APPLICATION->IncludeComponent("bitrix:support.faq",
4.       Посмотреть в журнале, какой SQL-запрос запишется в журнал, связанный с извлечением данных из таблицы информационных блоков. В этом запросе будут фигурировать now ().
5.       Посмотреть скорость выполнение этого запроса.
6.       Скопировать текст запроса и несколько раз выполнить его в поле «SQL запрос к базе данных» https://www.ritlabs.com/bitrix/admin/sql.php?lang=ru&del_query=Y – скорость при последующих обращениях не увеличится.
7.       Сохранить запрос в SQL-файл, в начале и в конце поставить по вызову show global status like 'Qcache_not_cached';
8.       Запустить SQL-файл через командную строку (mysql <with-now.sql) – значение Qcache_not_cached увеличится на единицу, что подтверждает что запрос не кешируется.
9.       Отредактируйте вручную запрос, уберите now(), сохраните его в другой файл, например without-sql.
10.   Скопируйте запрос без now() и вставьте его в «SQL запрос к базе данных» https://www.ritlabs.com/bitrix/admin/sql.php?lang=ru&del_query=Y – скорость при последующих обращениях увеличится за счет кеша MySQL.
11.   Запустить SQL-файл через командную строку (mysql <without-now.sql) – значение Qcache_not_cached не увеличится единицу, что подтверждает, что запрос кешируется и выполняется быстро.

Вот содержимое файла with-now-sql:


use my_database_name;

show global status like 'Qcache_not_cached';

SELECT SQL_CACHE
  BE.ID as ID,
  BE.IBLOCK_ID as IBLOCK_ID,
  BE.IBLOCK_SECTION_ID as IBLOCK_SECTION_ID,
  BE.NAME as NAME,
  IF(
EXTRACT(HOUR_SECOND FR OM
BE.ACTIVE_FROM)>0,
DATE_FORMAT(
  BE.ACTIVE_FROM,
  '%d.%m.%Y %H:%i:%s'
;),
DATE_FORMAT(
  BE.ACTIVE_FROM,
  '%d.%m.%Y'
;)
  ) as ACTIVE_FROM,
  DATE_FORMAT(
BE.TIMESTAMP_X,
'%d.%m.%Y %H:%i:%s'
  ) as TIMESTAMP_X,
  B.DETAIL_PAGE_URL as DETAIL_PAGE_URL,
  B.LIST_PAGE_URL as LIST_PAGE_URL,
  BE.DETAIL_TEXT as DETAIL_TEXT,
  BE.DETAIL_TEXT_TYPE as DETAIL_TEXT_TYPE,
  BE.PREVIEW_TEXT as PREVIEW_TEXT,
  BE.PREVIEW_TEXT_TYPE as PREVIEW_TEXT_TYPE,
  BE.PREVIEW_PICTURE as PREVIEW_PICTURE,
  L.DIR as LANG_DIR,
  BE.SORT as SORT,
  BE.CODE as CODE,
  BE.XML_ID as EXTERNAL_ID,
  B.IBLOCK_TYPE_ID as IBLOCK_TYPE_ID,
  B.CODE as IBLOCK_CODE,
  B.XML_ID as IBLOCK_EXTERNAL_ID,
  B.LID as LID
FR OM
  b_iblock B
  INNER JOIN b_lang L ON
B.LID = L.LID
  INNER JOIN b_iblock_element BE ON
BE.IBLOCK_ID = B.ID
WHERE
  1 = 1
  AND (
(BE.IBLOCK_ID = '8')
AND (
  EXISTS (
SELECT
  IBLOCK_ID
FR OM
  b_iblock_site
WHERE
  IBLOCK_ID = B.ID
  AND (SITE_ID = 'ru')
  )
;)
AND (BE.ACTIVE = 'Y')
AND (
  (
BE.ACTIVE_TO >= now()
OR BE.ACTIVE_TO IS NULL
  )
  AND (
BE.ACTIVE_FROM <= now()
OR BE.ACTIVE_FROM IS NULL
  )
;)
  )
  AND (
BE.WF_STATUS_ID = 1
AND BE.WF_PARENT_ELEMENT_ID IS NULL
  )
  AND (
B.ID IN (
  SELECT
IBLOCK_ID
  FR OM
b_iblock_group IBG
  WH ERE
IBG.GROUP_ID IN (2)
AND IBG.PERMISSION >= 'R'
AND (
  IBG.PERMISSION = 'X'
  OR B.ACTIVE = 'Y'
;)
;)
OR (
  B.RIGHTS_MODE = 'E'
  AND EXISTS (
SELECT
  ER.ELEMENT_ID
FR OM
  b_iblock_element_right ER
  INNER JOIN b_iblock_right IBR ON
IBR.ID = ER.RIGHT_ID
  INNER JOIN b_user_access UA ON
UA.ACCESS_CODE = IBR.GROUP_CODE
AND UA.USER_ID = 0
WH ERE
  ER.ELEMENT_ID = BE.ID
  AND IBR.OP_EREAD = 'Y'
  )
;)
  )
ORDER BY
  BE.ACTIVE_FROM DESC,
  BE.SORT ASC,
  BE.ID DESC;

show global status like 'Qcache_not_cached';
Рейтинг: 0.5976  
На голосовании
Предложил Чурсин Андрей 03.05.2017 14:24:36

Одинаковые символьные коды для ЧПУ

Если 2 одинаковых товара/услуги в разных разделах тогда ЧПУ с символьным кодом не сработает корректно!!!
Нужно дописать функционал "строгой проверки ссылки на элемент" и проверять раздел элемента для определения ELEMENT_ID.

p.s. По этой теме много недовольства при импорте товаров из других CMS, где символьный код использовался в url
Рейтинг: 0.2545  
На голосовании
Предложил Konstantin Obuhov 28.04.2017 12:47:13

Свои настройки SEO инфоблока для каждого сайта

Сейчас если у вас сайт на 2х языках и каждая версия - отдельная версия сайта, а инфоблок каталога товаров один, то SEO настройки инфоблока каталога также один для всех сайтов, что совершенно неверно.

При такой ситуации мета-теги на англ. версии сайта всегда будут на русском языке.
Рейтинг: 0  
На голосовании
Предложил Селиверстов Сергей 27.04.2017 11:31:52

О повешение входящих сообщений

Здравствуйте, Пожелания в программе сделайте всплывающие окна! Часто не видно что кто то написал сообщения (звука нету на компьютере) и отследить сообщения не удается. в Результате клиент уходит не дождавшись ответа
Рейтинг: 4.8563  
На голосовании
Предложил Дубровин Павел 04.04.2017 09:53:06

SEO-параметры для подразделов

Сейчас можно задать SEO-даннные для раздела и применить их для всех подразделов, но было бы очень здорово иметь возможность задавать SEO-параметры отдельно для всех подразделов сразу отдельно от SEO-данных самого раздела.
Рейтинг: 0.7148  
На голосовании
Предложил Белоконь Дмитрий 22.03.2017 18:25:31

Добавить возможность проводить индексацию highload-блоков модулем поиска

Идея достаточно объемная, но, думаю, востребованная.
HL-блокам не хватает немного функционала стандартных инфоблоков и тогда продукт станет массовым и удобным:
1) Шаблон пути на страницу списка элементов хл-блока
2) Шаблон пути на детальную страницу элемента хл-блока
3) Участвует ли хл-блок в модулей поиска
4) Участие в модули поиска конкретного пользовательского поля хл-блока
Рейтинг: 0.1887  
Ответил Долганин Антон 27.03.2017 13:53:39
Нюанс в том, что хл-блоки не нацелены на массу (если рассуждать в разрезе маркетинга). Это очень специфичный инструмент, который разработчик (даже не клиент) должен применять осознанно.

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

Это все конечно решается выведением хл-блоков в ряд к инфоблокам, но такое не планируется.
Рейтинг: 1.3917  
На голосовании
Предложил Саянц Антон 20.03.2017 13:27:42

Правильный фильтр в bitrix:catalog.section, фильтр подразделов

Здравствуйте.
Хотел я сделать фильтр внутри раздела, по его подразделам.
Но это не возможно:!: потому, что мешает строка 786, в коде компонента bitrix:catalog.section :
$rsElements = CIBlockElement::GetList($arSort, array_merge($arrFilter, $arFilter), false, $arNavParams, $arSelect);

Пожалуйста, поменяйте местами array_merge($arrFilter, $arFilter) - чтобы работали пользовательские фильтры передаваемые, через стандартное API. Пример:

$arrFilter = array('!PROPERTY_sap_flag' => 1, 'SECTION_ID' => [3392, 3388]);

Из-за текущей не правильной строки, перекрывается фильтр по разделам с ключом SECTION_ID.

Пришлось кастомизировать компонент, и терять обновления :cry:

Правильная строка для копипаста:

$rsElements = CIBlockElement::GetList($arSort, array_merge($arFilter, $arrFilter), false, $arNavParams, $arSelect);
 
Рейтинг: -0.2404  
На голосовании
Предложил Lacrimarum 10.03.2017 11:20:36

Хорошо бы иметь возможность добавлять формы в детальный просмотр элемента

В настоящее время, в детальный просмотр элемента инфоблока нельзя добавлять никакие компоненты, а хотелось бы иметь возможность добавления хотя бы стандартной формы обратной связи. Чтобы не обращаться за такой доработкой каждый раз к программистам, а иметь готовое решение для веб-мастеров, занимающихся поддержкой сайтов.
Рейтинг: 0.7581  
На голосовании
Предложил Дмитрий 10.02.2017 13:28:02

Сортировка свойств элемента drag and drop

Было бы очень удобно, если появилась бы возможность сортировки свойств при создании/редактировании элементов по типу "drag and drop". Сейчас нужно переходить в настройку формы редактирования. Сделайте как в Битрикс24 у лидов и счетах.
Рейтинг: 1.4417  
На голосовании
Предложил Дмитрий 10.02.2017 13:23:08

Сортировка свойств инфоблока drag and drop

Было бы очень удобно, если появилась бы возможность сортировки свойств в инфоблоке по типу "drag and drop". Сейчас выставлять нумерацию очень неудобно, особенно если свойств у инфоблока много.