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

Рейтинг: 0.6473  
На голосовании
Предложил Пользователь 269 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';
Рейтинг: 3.806  
На голосовании
Предложил Пользователь 274166 03.05.2017 14:24:36

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

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

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

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

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

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

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

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

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

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

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

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

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

Это все конечно решается выведением хл-блоков в ряд к инфоблокам, но такое не планируется.
Рейтинг: 14.7809  
На голосовании
Предложил Пользователь 114664 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  
На голосовании
Предложил Пользователь 22398 10.03.2017 11:20:36

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

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

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

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

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

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