Когда внутри комплексного компонента вызываются несколько включаемых областей, то при наведении курсора на комплексный компонент - сразу не ясно какая из них нужная:
В параметры компонента можно добавить дополнительный параметр, отвечающий за текст кнопки редактирования, а затем сделать что-то вроде:
Тогда сразу становится понятным, какая из включаемых областей за что отвечает в комплексном компоненте:
Добавить глобальную настройку 404 ошибки для стандартных компонентов ядра в настройки сайта. - Устанавливать статус 404; - Показ специальной страницы; - Страница для показа (по умолчанию /404.php).
При разработке своих компонентов или шаблонов на основе каких-то базовых приходится часто добавлять параметры (компонента или шаблона).
Добавление таких параметров в файл .parameters.php занимает определенное время особенно с учетом добавления описания даже на одном языке. Но, если этого не делать, а задавать значения новых параметров напрямую через вызов компонента, то приходится уже избегать редактирования параметров компонента через графический интерфейс, чтобы не затереть их. А если к настройке фронтэнда допущены другие лица, то вероятность случайного удаления этих параметров еще больше.
Было бы лучше, если бы такие неуказанные в .parameters.php параметры выводились в графическом режиме редактирования параметров компонента отдельным списком типа "Неуказанные параметры" в виде пар Код => Значение и пересохранялись при сохранении. Ну и возможность их изменения и удаления через ГУИ из кода вызова будет кстати.
Компонент корзина(sale.basket.basket) написан край как неудачно! И не только он...
В js идет построение верстки, но mvc и шаблонное проектирование вообще против такой парадигмы программирования! js должно только менять значения, а не конструировать верстку. Для js можно оставлять id в верстке и их же передавать массивом в js для дальнейшей работы с данными.
Сейчас же, для банальной стилизации компонента приходится его переписывать почти на половину! Предлагаю разработчикам пересмотреть стиль написания стандартных шаблонов, для уменьшения стоимости работы по персонализации их CMS, а соответственно и увеличения популярности для конечных клиентов!
p.s. там же, в sale.basket.basket/class.php видел строки ужаса, где ресайзят картинки! в ЯДРЕ компонента, РЕСАЙЗ картинок, и только на 110x110px!
В коде компонента вывода списка элементов (например, catalog.section), в месте, где происходит обращение к БД на выборку элементов, сливаются воедино два фильтра - тот, что задан в коде компонента, и внешний, который может быть задан разработчиком без влезания в код.
Сейчас это выглядит так:
array_merge($arrFilter, $arFilter)
$arrFilter - это преднастроенный в коде компонента фильтр.
Такая последовательность (ввиду логики работы array_merge) не позволяет переопределять параметры фильтрации, заложенные в коде компонента. Они всегда будут перезаписывать то, что пришло извне!
Особенно это обидно, когда нужно вывести стандартным компонентом неактивные элементы. Фактически - это сейчас сделать невозможно, надо копировать компонент, делать его кастомным, лишаться обновлений и т.д. И все ради простейшей задачи.
А дело-то всего лишь в последовательности переменных...
А почему до сих пор не реализованы опции для товара в стандартном функционале? Даже в joomshoping'е есть, а у нас битрикс все таки. Считаю необходимым внедрение функционала дополнительных опций (как в шаблоне битроник) в поставку стандартного ИМ начиная с редакции малый бизнес.
Если в построении URL используется #SECTION_CODE_PATH#, то компонент bitrix:catalog.section.list начинает генерировать ОЧЕНЬ большое количество запросов.
например, при выводе списка из 40 разделов, генерируется 176 запросов.
Если разделов много, то может быть и 1000 запросов.
Необходимо сделать кеширование URL к разделу (по примеру фасетного индекса для умного фильтра) и брать закешированные данные.
)Нынешний визредактор во многом уступает старому. В частности при выборе компонента приходится ориентироваться только на его русскоязычное название. Идентификатор компонента нельзя увидеть ни при наведении курсора, ни при нажатии на компонент в правом меню. Приходится располагать компонент в рабочем поле и смотреть настройки.
То же с поиском. Если я нашёл в документации компонент (условно говоря bitrix:sale.personal.section), я его никак не найду в списке компонентов.
Сейчас нигде не выводится краткое описание компонента, кроме настроек. Хотя это описание в первую очередь нужно для выбора компонента, потом оно уже не нужно.
Предлагаемые изменения:
выводить название компонента в подсказке при наведении курсора на иконку компонента (как в меню, так и в рабочем поле визуального редактора)
то же, но при нажатии на компонент. где-то внизу должно выводиться название
описание должно появляться во всплывающей подсказке
в поиске компонентов поиск должен идти также по идентификаторам
В поставке Битрикс24 очень много компонентов и частей системы, которые могут помочь, но они очень неюзабельный со стороны других разработчиков.
Пример 1: нет компонента привязки к сущности crm. Да можно вывернуться через system.field.edit, но корявенько получается. Пример 2: есть компонент выбора пользователя и даже intranet.user.selector.new, но на практике просто взять и использовать нельзя, потому как он требует еще немножко магии
Какие части системы хотелось бы видеть в качестве штатных компонентов:
1) Компонент выбора сотрудников/подразделений. Тут все просто - по аналогии с "набором тегов" в ленте (с красивым выпадающим окошком) выбрать из структуры, найти из экстранет пользователей, выбрать группы и т.п. Важно сразу учесть несколько моментов: - Нужно иметь возможность не учитывать права доступа (т.е. выбирать всех пользователей экстранет) - Давать возможность выбора только определенных сущностей (например только подразделения, только группы, только внешних пользователей)
А на выходе в нужную REQUEST-переменну клал массив по аналогии с лентой (например U1, SG202 и т.п.)
2) Компонент выбора сущности CRM (опять же с возможностью отключения прав доступа)
Это не полный список, но уже качественно улучшит качество разрабатываемых решений (во-первых единый интерфейс, а во-вторых не надо будет костылить с select2 и подобными) и одновременно увеличит скорость разработки (не надо будет писать с 0, когда есть уже готовое)
Добрый день. Возник момент с кастомным кешированием в своем компоненте. Согласно этому курсу (https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=43&LESSON_ID=3053), подключение шаблона можно размещать как в кешируемой области, так и вне её. При подключении шаблона в кешируемой области собственного компонента со сложным кешированием шаблон не отрабатывает вообще - сразу выводится html-кеш. Разница в том, что в стандартных компонентах используется метод StartResultCache и при этом template.php кешируется полностью и выводится как html-кеш. При этом из кеша на хите достаются переменные VARS из файла кеша и передаются в component_epilog.php, что не происходит, если строить свое кеширование согласно вышеуказанному курсу. Покопавшись в исходниках, выяснил, что в метод startResultCache() вшит также метод includeComponentEpilog(), которого нет в классах кастомного кеширования и в документации. При этом входящие данные для него от родительского компонента в своем дочернем компоненте получить нельзя, так как свойство, в котором хранится путь и данные для метода includeComponentEpilog() лежат в родительском свойстве __component_epilog, которое имеет модификатор доступа private и недоступен в потомке. В связи с этим кастомное кеширование получается неполноценным, т.к. для использования в шаблонах component_epilog, нужно подключение шаблона обязательно выводить из кешируемой области. Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.