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

Рейтинг: 1.1751  
На голосовании
Предложил Пользователь 32566 11.07.2015 18:26:06

Кастомные свойства типа "Файл" в инфоблоках

При обновлении и добавлении элементов инфоблоков нужно убрать дополнительные обработки передаваемых значений свойств типа файл (PROPERTY_TYPE=F), если эти свойства являются кастомными (USER_TYPE != "" ).
Например, в файле /bitrix/modules/iblock/admin/iblock_element_edit.php (строка ~568 ) нужно убрать преобразование значения через функцию CIBlock::makeFilePropArray(...).
Это позволит создавать свои загрузчики файлов, которые будут иметь предсказуемую разработчиком логику. Сейчас же с выпуском обновления Битрикса мой модуль перестал работать из-за того, что передаваемый в значение ID файла:
array("VALUE"=>777); 
с какого-то фига вдруг превратился в:
[VALUE] => Array(
     [name] => 
     [type] => 
     [tmp_name] => 
     [error] => 4
     [size] => 0
)
Если свойство кастомное то на вход функции ConvertToDB должно поступать ровно то, что отправлено через форму редактирования или через какие-либо средства API.

P.S. В данный момент пришлось переключить свой модуль с использования типа "F" на "N", что накладывает ограничение на использование кастомного свойства в штатных шаблонах решений от Битрикса.
Рейтинг: 17.0224  
На голосовании
Предложил Пользователь 32566 06.02.2015 12:15:40

Фэншуй в SEO инструментах для инфоблоков

Чтобы наступил для разработчиков рай нужно:
  1. User-friendly.
    Дать возможность в методах
    CIBlockParameters::GetInheritedPropertyTemplateSectionMenuItems()
    CIBlockParameters::GetInheritedPropertyTemplateElementMenuItems()
    добавлять свои шаблоны подстановки через обработчики событий. Чтобы сеошникам было удобно подставлять шаблоны через вот это меню
  2. Developer-friendly.
    Добавить {=this.ID}, {=parent.ID}, {=iblock.ID} для использования в пользовательских функциях. Почему сразу это не было сделано - непонятно.
Рейтинг: 20.6709  
На голосовании
Предложил Пользователь 32566 26.07.2014 01:07:24

Довести до ума работу метода ConvertFromDB

При разработке собственных свойств инфоблока создается метод ConvertFromDB, назначение которого - преобразовывать значения свойства в требуемый разработчику вид.
Создавая сложные свойства разработчики иногда используют дополнительное поле описания значения свойства - "DESCRIPTION", куда сохраняют сопутствующие значению данные в сериализованном виде.
То есть фактически получается, что значение свойства состоит из кортежа {VALUE,DESCRIPTION}.
Проблема в том, что при выборках CIBlockElement::GetList в метод свойства ConvertFromDB не поступает значение поля "DESCRIPTION" (передается почему-то пустая строка). Что не позволяет правильно сформировать полноценное значение свойства.
Проблема находится в файле: /bitrix/modules/iblock/classes/general/iblockresult.php (строка 196).
Нужно заменить вот это:
if(is_array($this->arIBlockConvProps))
{
   foreach($this->arIBlockConvProps as $strFieldName=>$arCallback)
   {
      if(is_array($res[$strFieldName]))
      {

         foreach($res[$strFieldName] as $key=>$value)
         {
            $arValue = call_user_func_array($arCallback["ConvertFromDB"], array($arCallback["PROPERTY"], array("VALUE"=>$value,"DESCRIPTION"=>"")));
            $res[$strFieldName][$key] = $arValue["VALUE"];
         }
      }
      else
      {
         $arValue = call_user_func_array($arCallback["ConvertFromDB"], array($arCallback["PROPERTY"], array("VALUE"=>$res[$strFieldName],"DESCRIPTION"=>"")));
         $res[$strFieldName] = $arValue["VALUE"];
      }
   }
}
 
На примерно вот это:
if(is_array($this->arIBlockConvProps))
{
   foreach($this->arIBlockConvProps as $strFieldName=>$arCallback)
   {
      $propID = $arCallback["PROPERTY"]["ID"];
      $propCode = $arCallback["PROPERTY"]["CODE"];
      $desc = $res["DESCRIPTION_".$propID];
      if(empty($desc)) $desc = $res["PROPERTY_".$propID."_DESCRIPTION"];
      if(empty($desc)) $desc = $res["PROPERTY_".$propCode."_DESCRIPTION"];
      
      if(is_array($res[$strFieldName]))
      {

         foreach($res[$strFieldName] as $key=>$value)
         {
            $arValue = call_user_func_array($arCallback["ConvertFromDB"], array($arCallback["PROPERTY"], array("VALUE"=>$value,"DESCRIPTION"=>$desc[$key])));
            $res[$strFieldName][$key] = $arValue["VALUE"];
         }
      }
      else
      {
         $arValue = call_user_func_array($arCallback["ConvertFromDB"], array($arCallback["PROPERTY"], array("VALUE"=>$res[$strFieldName],"DESCRIPTION"=>$desc)));
         $res[$strFieldName] = $arValue["VALUE"];
      }
   }
}
То есть передаем в метод ConvertFromDB сопутствующее значению описание DESCRIPTION.

Для чего это всё.

Пример сложного свойства: вставки в ювелирные украшения. Значение представляет собой кортеж {типКамня,каратность,количество}. Тип камня (ID) хранится в поле VALUE, каратность и количество - в DESCRIPTION в сериализованном виде. Данная структура позволяет делать выборки элементов инфоблока по типу камня.
При текущем положении вещей постоянно приходится преобразовывать значения в нужный вид в result_modifier.php.
А если свойство входит в состав какого-то решения из маркетплейса, то разработчик, который использует это решение может только догадываться как преобразовать значения свойства в нормальный вид.

Создан тикет в техподдержку: 512438
Рейтинг: 32.653  
На голосовании
Предложил Пользователь 32566 15.01.2013 22:19:36

Создание шаблона при редактировании типа почтового события

При создании нового типа почтового события почему бы не сделать кнопку добавления шаблона для этого события во вкладке "Шаблоны"?


Даже простая ссылка на страницу создания шаблона ускорит работу.
Рейтинг: 26.9306  
На голосовании
Предложил Пользователь 32566 27.08.2012 11:01:57

Некешируемые области в шаблонах компонентов

Сделайте, наконец, штатный функционал некешируемых областей в шаблонах компонентов.
Сейчас у вас есть функции CMain:: ShowViewContent и CMain::AddViewContent. Но они работают только в направлении (как я понял) шаблон компонента -> шаблон сайта.
Хотелось бы, чтобы оно работало в рамках шаблона компонента.
То есть, например, в template.php вставляли ShowUncachedContent("uncache");
А в component_epilog.php (или в любой другой некешируемой части сайта) задавали контент этой некешируемой области через SetUncachedContent("uncache");

Типичная задача: показывать на странице товара в интернет-магазине "Купить" или "Уже в корзине" в зависимости от статуса товара.
Рейтинг: 22.5112  
На голосовании
Предложил Пользователь 32566 08.06.2012 21:45:36

Избранные задачи

Добавить возможность помечать задачи как избранные и выводить их в специальном блоке чтобы были всегда на виду.
Рейтинг: 19.8432  
На голосовании
Предложил Пользователь 32566 22.05.2012 11:38:46

Добавить параметр FORM_ID в компонент формы добавления элементов инфоблока

Сейчас при нахождении на странице двух и более форм добавления элементов инфоблока форма, которая находится выше по коду перехватывает данные из формы, которая ниже.Как пример: в шапке форма заказа звонка, на странице форма заявки чего-либо.
Это происходит из-за того, что идет проверка на наличие в отправленных данных ключа "iblock_submit" (или "iblock_apply"). У всех форм этот ключ одинаков.
if (check_bitrix_sessid() && (!empty($_REQUEST["iblock_submit"])  
|| !empty($_REQUEST["iblock_apply"]))){...}

В компоненте нужно сделать примерно вот так:
$FORM_ID = $arParams["FORM_ID"];
if (check_bitrix_sessid() && (!empty($_REQUEST["iblock_submit_".$FORM_ID])  
|| !empty($_REQUEST["iblock_apply_".$FORM_ID]))){...}
Тогда данные, переданные из одной формы, не будут попадать в обработку другой форме.

Это касается также и формы регистрации (да, бывает такое, что нужно две формы регистрации на странице - юрики и физики).

  • 30.05.2012 17:15: Блин, и вебформы тоже такие же кривые. Это совсем не серьезно :(
  • 30.05.2012 18:19: Мда, несколько веб-форм на одной странице работают, но оказывается нельзя выводить однотипные веб формы в цикле при их работе по AJAX! Все из-за того, как подсказал коллега, что идендификатор сессии ajax-запроса формируется по номеру строки скрипта o_0 Хорошо, что веб-форм всего 9 (кол-во услуг)...
Рейтинг: 52.2185  
На голосовании
Предложил Пользователь 32566 22.05.2012 09:03:26

Добавить возможность редактировать названия полей (заголовки столбцов) в списке элементов инфоблока



Сейчас это реализовано только на странице редактирования/добавления элемента.
Рейтинг: 31.7104  
На голосовании
Предложил Пользователь 32566 18.05.2012 10:48:08

Задавать заголовки включаемых областей

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


Было бы более "юзерфрендли" делать заголовки типа "Изменить логотип", "Редактировать блок контактов", "Изменить телефон" и т.д.
Можно дополнительным параметром в компонент передавать этот заголовок.
ПС. Ну и для "Добавить область" такая же история.
Рейтинг: 33.4201  
На голосовании
Предложил Пользователь 32566 03.02.2012 15:13:12

CIBlockElement::GetList - выбор по значению свойства в пределах типа инфоблока

Если значения свойств хранятся в отдельной таблице, то выборка:
$res = CIBlockElement::GetList(array("sort"=>"asc"),array("IBLOCK_TYPE"=>"catalog","PROPERTY_BESTSELLER"=>"Y"));
 
сработает неправильно. Выберутся только товары из одного инфоблока.
Это нужно для вывода, например, новинок каталога, когда каталог товаров в крупном магазине реализован через множество инфоблоков, и каждый инфоблок является разделом каталога.
Приходится перебирать все инфоблоки в цикле, что не совсем гут.
Рейтинг: -0.3956  
Ответил Жуков Евгений 03.02.2012 16:46:38
Это единственный выход для такой ситуации.