Комплексный компонент FAQ "bitrix:support.faq" не поддерживает время начала и окончание активности записи, однако при обращении к базе MySQL идёт проверка дат - в запросе идёт вызов Now() что не даёт серверу СУБД кешировать запрос и замедляет работу
Разместить здесь (http://idea.1c-bitrix.ru/) это пожелание мне посоветовал старший специалист техподдержки Свиридов Юрий, на моё обращение №1456195.
При этом для новостей предусмотрен параметр "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', массив будет иметь следующий вид:
Параметр "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", нужно также добавить сравнение:
Это изменение надо сделать во всех файлах в 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;
Если 2 одинаковых товара/услуги в разных разделах тогда ЧПУ с символьным кодом не сработает корректно!!! Нужно дописать функционал "строгой проверки ссылки на элемент" и проверять раздел элемента для определения ELEMENT_ID.
p.s. По этой теме много недовольства при импорте товаров из других CMS, где символьный код использовался в url
Сейчас если у вас сайт на 2х языках и каждая версия - отдельная версия сайта, а инфоблок каталога товаров один, то SEO настройки инфоблока каталога также один для всех сайтов, что совершенно неверно.
При такой ситуации мета-теги на англ. версии сайта всегда будут на русском языке.
Здравствуйте, Пожелания в программе сделайте всплывающие окна! Часто не видно что кто то написал сообщения (звука нету на компьютере) и отследить сообщения не удается. в Результате клиент уходит не дождавшись ответа
Сейчас можно задать SEO-даннные для раздела и применить их для всех подразделов, но было бы очень здорово иметь возможность задавать SEO-параметры отдельно для всех подразделов сразу отдельно от SEO-данных самого раздела.
Идея достаточно объемная, но, думаю, востребованная. HL-блокам не хватает немного функционала стандартных инфоблоков и тогда продукт станет массовым и удобным: 1) Шаблон пути на страницу списка элементов хл-блока 2) Шаблон пути на детальную страницу элемента хл-блока 3) Участвует ли хл-блок в модулей поиска 4) Участие в модули поиска конкретного пользовательского поля хл-блока
Нюанс в том, что хл-блоки не нацелены на массу (если рассуждать в разрезе маркетинга). Это очень специфичный инструмент, который разработчик (даже не клиент) должен применять осознанно.
Про индексацию поиском хл-блоков думали, но тут главная проблема, что непонятно что считать детальной страницей элемента. В хл-блоках отсутствует даже понятие заголовка элемента (что важно для поиска) - заголовком может быть любое поле, или не быть им вовсе.
Это все конечно решается выведением хл-блоков в ряд к инфоблокам, но такое не планируется.
Здравствуйте. Хотел я сделать фильтр внутри раздела, по его подразделам. Но это не возможно:!: потому, что мешает строка 786, в коде компонента bitrix:catalog.section :
Пожалуйста, поменяйте местами array_merge($arrFilter, $arFilter) - чтобы работали пользовательские фильтры передаваемые, через стандартное API. Пример:
В настоящее время, в детальный просмотр элемента инфоблока нельзя добавлять никакие компоненты, а хотелось бы иметь возможность добавления хотя бы стандартной формы обратной связи. Чтобы не обращаться за такой доработкой каждый раз к программистам, а иметь готовое решение для веб-мастеров, занимающихся поддержкой сайтов.
Было бы очень удобно, если появилась бы возможность сортировки свойств при создании/редактировании элементов по типу "drag and drop". Сейчас нужно переходить в настройку формы редактирования. Сделайте как в Битрикс24 у лидов и счетах.
Было бы очень удобно, если появилась бы возможность сортировки свойств в инфоблоке по типу "drag and drop". Сейчас выставлять нумерацию очень неудобно, особенно если свойств у инфоблока много.
Про индексацию поиском хл-блоков думали, но тут главная проблема, что непонятно что считать детальной страницей элемента. В хл-блоках отсутствует даже понятие заголовка элемента (что важно для поиска) - заголовком может быть любое поле, или не быть им вовсе.
Это все конечно решается выведением хл-блоков в ряд к инфоблокам, но такое не планируется.