1C Битрикс — известная и хорошая система управления сайтом. Но ее исправная работа во многом зависит от действий технических специалистов. Есть некоторые распространенные ошибки, которые допускаются при разработке сайтов на Битрикс. Они достаточно очевидны и лежат на поверхности, но к сожалению, не все уделяют им внимание. Непрофессионал может просто не заметить эти моменты, но всего несколько ошибок могут существенно усложнить жизнь проекта в будущем.
1. Не соблюдение структуры CMS
В документации есть подробное описание реализации базовых задач, например, таких как изменение результирующего массива данных компонента. Когда разработчик пренебрегает внутренними правилами, он обрекает на головную боль тех, кто будет разбираться в его творчестве в дальнейшем.
2. Модификация обновляемых областей
Сам факт существования такой проблемы нам остаётся непонятным. Однако всё чаще встречаются проблемные проекты после обновления системы что-то да отваливается. Привести к такому поведению могло, например, изменение кода файлов в каталоге /bitrix/components/bitrix. Стоит помнить: все шаблоны кастомизируются только после создания копии оного в каталоге /bitrix/templates/#template#/components/#area#/, для кастомизации компонента используются файлы result_modifier.php и component_epilog.php, новые компоненты создаются в новой области, #bitrix# — только для встроенных компонентов.
3. Запросы в цикле
Эта проблема больше относится к построению алгоритмов как таковых, но частенько благодаря таким ошибкам Битрикс обвиняют в прожорливости. Например, при использовании bitrix:news.list мы не смогли получить все необходимые данные элементов, привязанных к элементам обрабатываемого инфоблока, оперируя только настройками компонента. Следовательно, нам нужно выполнить ряд дополнительных запросов используя API битрикса. Тут и встречается проблема вида:
foreach ($arResult as $k => $arItem) {
$rs = CIBlockElement::GetList($arSort, $arFilter);
while ($ar = $rs->GetNext())
$arResult[$k][«EXAMPLE»] = $ar;
}
Такой подход серьёзно увеличит количество запросов к базе.
Исправленный код:
$ids = array();
foreach ($arResult as $arItem)
$ids[] = $arItem[«example_id»];
$arFilter = array(«ID» => $ids);
$rs = CIBlockElement::GetList($arSort, $arFilter);
while ($ar = $rs->GetNext())
$arResult[«EXAMPLE»][$ar[«ID»]] = $ar;
4. Вызов компонента в шаблоне
Встречается довольно часто. Например, при подключении комментариев к статьям или вызове формы заявки. Это ведёт к ошибкам работы управляемого кеша. Если статья не изменялась, компонент будет считать, что содержимое необходимо грузить из кеша, соответственно, комментарии не будут обновлены.
5. Лишние свойства
Как ни странно, прежде чем создавать свойства инфоблока, стоит изучить все возможности самих инфоблоков. Сам по себе этот инструмент имеет увесистый набор параметров, в отличие от highload blocks. Например, количество показов элемента дополнительно считать необходимости нет.
6. Папка lang, файл .section.php и им подобные
И хотя они не влияют на работу ресурса как таковую, пренебрегать ими не стоит. Проект должен оставаться расширяемым и понятным для простых пользователей, пользующихся админ разделом. Например, незатейливая подпись «товар» в шаблоне каталога потребует времени программиста, когда магазин решит выйти на международный рынок.
7. Кеширование
Помимо очевидного, настройки кеширования готовых компонентов, любые подключаемые файлы и собственные компоненты, осуществляющие запросы к базе данных, должны кешировать результаты. Для этого в API есть специальный класс.
Главный вывод заключается в том, что внимательность к деталям очень важна в работе технического специалиста. Пропустив пару-тройку «незначительных» моментов, вы можете столкнуться с ненужными проблемами для проекта в будущем. Фрилансеры могут себе такое позволить, профессионалы — нет. Ответственность за будущую работу проекта лежит на разработчике в полной мере, и подобные нюансы ее только усиливают.
