В версии инфоблоков 16.5.4 вышла прекрасная функциональность для работы с разделами на новом ядре D7.
Правда документации пока нет (но ничего страшного) и можно было бы существенно увеличить возможности новой реализации:
1) Метод compileEntityByIblock мог бы возвращать не полное название класса, а объект этого класса. При этом его работа была бы эффективнее. Сравните 2 подхода:
Против
Мне кажется решение под номером 2 выглядит практичнее.
2) Предлагаю расширить модель SectionTable (или ее производные типа Section1Table) на runtime параметр: ELEMENT_COUNT - который бы доставал активные элементы, привязанные к соответствующему разделу.
Кейс: нужно отобразить только те разделы, где есть активные элементы.
Решение предлагаемое из коробки - составление своего runtime-поля для каждого getList/getRow (где оно требуется).
Если добавить штатное решение как SELECT поле и просто передавать его в массиве полей или соответственно по условию, то код будет выглядеть элегантнее и проще, а другие подобные поля, можно будет посмотреть и сделать по аналогии.
Правда документации пока нет (но ничего страшного) и можно было бы существенно увеличить возможности новой реализации:
1) Метод compileEntityByIblock мог бы возвращать не полное название класса, а объект этого класса. При этом его работа была бы эффективнее. Сравните 2 подхода:
use \Bitrix\Main\Loader;
use \Bitrix\Iblock\Model\Section as SectionFactory;
Loader::IncludeModule('iblock');
$sSection = SectionFactory::compileEntityByIblock(1);
$oEntity = new $sSection;
var_dump($oEntity->getMap()); |
Против
use \Bitrix\Main\Loader;
use \Bitrix\Iblock\Model\Section as SectionFactory;
Loader::IncludeModule('iblock');
$oEntity = SectionFactory::compileEntityByIblock(1);
var_dump($oEntity->getMap()); |
Мне кажется решение под номером 2 выглядит практичнее.
2) Предлагаю расширить модель SectionTable (или ее производные типа Section1Table) на runtime параметр: ELEMENT_COUNT - который бы доставал активные элементы, привязанные к соответствующему разделу.
Кейс: нужно отобразить только те разделы, где есть активные элементы.
Решение предлагаемое из коробки - составление своего runtime-поля для каждого getList/getRow (где оно требуется).
Если добавить штатное решение как SELECT поле и просто передавать его в массиве полей или соответственно по условию, то код будет выглядеть элегантнее и проще, а другие подобные поля, можно будет посмотреть и сделать по аналогии.
Удивительно что еще не реализовано и вроде как никто не предложил такую идею. А такая возможность была бы очень часто полезной.
Сейчас подраздел может лежать только в одной родительской категории, а элементы - могут быть привязаны к нескольким категориям. Вот хотелось бы, чтобы и разделы можно было привязывать к нескольким родителям...
Сейчас подраздел может лежать только в одной родительской категории, а элементы - могут быть привязаны к нескольким категориям. Вот хотелось бы, чтобы и разделы можно было привязывать к нескольким родителям...
Как видно на скриншоте, к изображению раздела нельзя добавить описание DESCRIPTION, но как показала практика - это бывает нужно. Да и странно - для картинок элементов инфоблока такая возможность есть.
Клиент очень матерился - промазал и снес огромный раздел каталога, и его ни о чем не спросили, никакого алерта не вылетело... Пришлось восстанавливать бэкап.
Поправьте пожалуйста, срочно!
Поправьте пожалуйста, срочно!
Ответил 
21.03.2014 20:18:10
21.03.2014 20:18:10
Штатный функционал, всегда спрашивает перед удалением.
При использовании множественного участия в разделах, конечный путь к элементу в настоящее время строится через раздел, у которого наименьший ID. Хорошо, что URL товара при этом 1, но неудобно что нельзя назначить в каком именно разделе.
Желательно добавить функционал назначения "основного" раздела через пользовательское св-во или другим методом.
По мотивам .
Желательно добавить функционал назначения "основного" раздела через пользовательское св-во или другим методом.
По мотивам .
У меня огромный каталог с миллиономами элементов и десятками тясячами разделов. Очень часто приходится переносить разделы\элементы из одного раздела в другой. Очень неудобно искать нужный раздел в выпадющем селекте дерева разделов( Как-то надо удобнее сделать.
Идея:
Сделать возможность более тонкой настройки разделов в инфоблоках, как минимум - настройка обязательности полей для разных уровней. например, на каком-то уровне картинка является обязательной, а на другом - ее в принципе не может быть.
Как максимум - дать возможность настройки формы редактирования для разделов разных уровней, чтобы при добавлении раздела уровня 1 показывалась одна форма, раздела 2-го уровня - другая и т.д.
Кому и зачем нужно:
Собственно, раз похожее поведение есть в элементах инфоблока (свойства, привязанные к разделу), логично сделать так же и для разделов. Часто клиенты хотят иерархию в каталоге, например "город-магазин-тип обуви". При этом у города хотят карту обязательную, у магазина - обязательную фотографию а у типа обуви - обязательное указание сезона. Приходится создавать все поля, отменять у всех обязательность и проверять на заполненность на уровне обработки события сохранения. Задача несложная, просто муторная и частая.
Сделать возможность более тонкой настройки разделов в инфоблоках, как минимум - настройка обязательности полей для разных уровней. например, на каком-то уровне картинка является обязательной, а на другом - ее в принципе не может быть.
Как максимум - дать возможность настройки формы редактирования для разделов разных уровней, чтобы при добавлении раздела уровня 1 показывалась одна форма, раздела 2-го уровня - другая и т.д.
Кому и зачем нужно:
Собственно, раз похожее поведение есть в элементах инфоблока (свойства, привязанные к разделу), логично сделать так же и для разделов. Часто клиенты хотят иерархию в каталоге, например "город-магазин-тип обуви". При этом у города хотят карту обязательную, у магазина - обязательную фотографию а у типа обуви - обязательное указание сезона. Приходится создавать все поля, отменять у всех обязательность и проверять на заполненность на уровне обработки события сохранения. Задача несложная, просто муторная и частая.
Добавить возможность в CIBlockSection::GetList выбирать поля RATING_TOTAL_VALUE, RATING_TOTAL_VOTES, RATING_TOTAL_POSITIVE_VOTES, RATING_TOTAL_NEGATIVE_VOTES, RATING_USER_VOTE_VALUE и сортировать по этим полям, аналогично тому, как это реализовано в
CIBlockElement::GetList.
CIBlockElement::GetList.
Сделать уже по умолчанию поле "Краткое описание раздела" (с виз. редактором) в разделах инфоблока. По аналогии с полем инфоблока "Полное описание".
Сейчас установить настройку использовать или нет древовидный классификатор элементов по разделам можно лишь для типа инфоблока.
Это неудобно тем, что в одном типе могут содержаться инфоблоки, для которых необходимо выборочное использование или отсутствие древовидного классификатора. В таких случаях приходится создавать для каждого нового инфоблока отдельный тип и общая структура загромождается.
Предлагаю реализовать настройку возможности устанавливать использование древовидного классификатора не только для типа, но и для каждого инфоблока в отдельности. Например:
Это неудобно тем, что в одном типе могут содержаться инфоблоки, для которых необходимо выборочное использование или отсутствие древовидного классификатора. В таких случаях приходится создавать для каждого нового инфоблока отдельный тип и общая структура загромождается.
Предлагаю реализовать настройку возможности устанавливать использование древовидного классификатора не только для типа, но и для каждого инфоблока в отдельности. Например:
Редко но бывает надо импортировать в инфоблоки CSV с глубиной вложенности разделов (значительно) больше 3х, например 6. В этом случае приходится времено делать такое извращение (а потом всё возвращать назад) - в файле /bitrix/modules/iblock/admin/data_import.php выставлять переменную $NUM_CATALOG_LEVELS=6. Тогда в форме импорта появляются "группа уровня 4/5/6" . Если бы переменную $NUM_CATALOG_LEVELS можно было бы регулировать через константы или настройки модуля инфоблоков, то не пришлось бы модифицировать системный файл или ради одной циферки городить огород с вынесением этого файла в своё пространство.
типа того:
типа того:
$NUM_CATALOG_LEVELS=3;if(defined('NUM_CATALOG_LEVELS') && (intval(NUM_CATALOG_LEVELS)>3)){ $NUM_CATALOG_LEVELS=NUM_CATALOG_LEVELS;} |
Ответил 
Жуков Евгений 30.01.2014 14:05:22
Жуков Евгений 30.01.2014 14:05:22
Глубина вложенности в csv-импорте/экспорте торгового каталога изначально регулировалась настройками модуля.
Глубина вложенности csv-импорта/экспорта модуля инфоблоков вынесена в настройки модуля, начиная с версии 14.0.5
Глубина вложенности csv-импорта/экспорта модуля инфоблоков вынесена в настройки модуля, начиная с версии 14.0.5
Здравствуйте!
Часто получается, что одна и та же структура групп может использоваться в разных инфоблоках (например, товары разного типа, со своими специфическими свойствами, но сгруппированные по единой системе классификации).
В результате есть 2 пути:
- тупо повторять структуру в каждом инфоблоке;
- использовать решение
У первого и второго есть свои плюсы и минусы.
Что я предлагаю:
- группировку элементов одного инфоблока группами другого;
- чтобы это включалось в настройках "дочернего" инфоблока (например, пункт "Использовать группы инфоблока" со списком инфоблоков в выпадающем меню, исключая текущий и другие с такой же настройкой).
См. на скрине настроек инфоблока пункт "Использовать разделы другого инфоблока":
В результате внешне группировка инфоблоков должна работать как обычно, причем как в публичном, так и в административном интерфейсах вне зависимости от того, чьи группы -- "свои" или "заимствованные" -- инфоблок использует.
Функционал создания и редактирования групп тоже должен функционировать везде -- и в тех инфоблоках, которые имеют свои группы, и в тех, которые не имеют свои группы и используют группы других инфоблоков. Только в последнем случае, разумеется, группы будут создаваться и редактироваться не "свои", а "заимствованные".
Часто получается, что одна и та же структура групп может использоваться в разных инфоблоках (например, товары разного типа, со своими специфическими свойствами, но сгруппированные по единой системе классификации).
В результате есть 2 пути:
- тупо повторять структуру в каждом инфоблоке;
- использовать решение
У первого и второго есть свои плюсы и минусы.
Что я предлагаю:
- группировку элементов одного инфоблока группами другого;
- чтобы это включалось в настройках "дочернего" инфоблока (например, пункт "Использовать группы инфоблока" со списком инфоблоков в выпадающем меню, исключая текущий и другие с такой же настройкой).
См. на скрине настроек инфоблока пункт "Использовать разделы другого инфоблока":
В результате внешне группировка инфоблоков должна работать как обычно, причем как в публичном, так и в административном интерфейсах вне зависимости от того, чьи группы -- "свои" или "заимствованные" -- инфоблок использует.
Функционал создания и редактирования групп тоже должен функционировать везде -- и в тех инфоблоках, которые имеют свои группы, и в тех, которые не имеют свои группы и используют группы других инфоблоков. Только в последнем случае, разумеется, группы будут создаваться и редактироваться не "свои", а "заимствованные".
Добавить настройку кнопок панелей инструментов визуального редактора для редактирования html содержимого описания разделов. Сейчас по умолчанию выводятся все инструменты при редактировании описания раздела.
Мы очень часто создаем "системные" инфоблоки, хранящие некие вспомогательные данные для работы сайта. И очень часто в эти инфоблоки информацию нужно добавлять по-особенному. Например, нельзя добавлять разделы второго уровня - только первого уровня. Или вообще инфоблок может содержать только иерархию разделов, без элементов.
Таким образом, предложения по доп. настройкам инфоблоков:
Таким образом, предложения по доп. настройкам инфоблоков:
- Ограничение максимальной вложенности разделов
- Запрет на создание элементов - только разделы (очень удобно для хранения всяческих иерархий данных)
- Запрет на добавление элементов не в конечные по вложенности разделы
- Если инфоблок не содержит разделов (исходя из настроек типа инфоблока) - то не выводить лишнюю вкладку в настройках инфоблока - "Поля разделов"
В настоящий момент невозможна установка вывода новостей (публикаций) только из определенного раздела. В итоге приходится создавать страницу с комплексным компонентом а в добавок и отдельные страницы для каждого раздела через компонент news.list.
Хотелось бы, чтобы была возможность настройки использования или отмены древовидного классификатора элементов по разделам для каждого отдельного инфоблока, а не только для целого типа инфоблоков.
Сталкивался с этой задачей неоднократно. И неоднократно видел одно и тоже типовое решение - пользовательские свойства разделов. Мне кажется это не совсем корректно, что у элементов можно задать произвольное количество любых свойств, а у разделов такой возможности нет.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
