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

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

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

Кто-то видел сайт без использования это модуля? В каждом компоненте все проверяют подключен ли он, зачем столько лишнего кода.    

Подключать на уровне ядра сразу как main

Прошу добавить в штатные заготовки для инфоблоков на вкладки SEO
Возможность подставлять по  META KEYWORDS, тэги из собственно элементов вкладки SEO
Это же очевидно! =) но этого нет =(

При загрузке PREVIEW_PICTURE  и DETAIL_PICTURE нельзя указать тип масштабирования:

• BX_RESIZE_IMAGE_EXACT
• BX_RESIZE_IMAGE_PROPORTIONAL
• BX_RESIZE_IMAGE_PROPORTIONAL_ALT
  

Было бы очень удобно, если бы эти функции появились в новых обновлениях. Сейчас приходится использовать события.

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


в интерфейсе админа
постоянно с первого раза не могу сохранить иб

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



Номер обращения в разработку: 44135

Исохдя из того, что 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".

У комплексного компонента Новости "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, а также имть её поддержку для форумов.

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

 

Текст детального просмотра целиком нужен лишь при детальном отображении лишь одного элемента новости. Когда мы выводим спискок элементов, например список новостей, то весь текст детального просмотра не нужен, а нужен лишь признак его наличия, чтобы принять решение, отобразить ли 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",

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

В /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-дисков