1. Изменять все стандартное/Изменять содержимое папки bitrix
Изменение всего, что лежит в папке /bitrix/ - табу.
Если вам нужно изменить шаблон компонента - копируйте его в шаблон сайта.
Если вам нужно изменить компонент - используйте result_modifier.php, component_epilog.php (про них я подробно писал в этой статье), напишите свой компонент, в конце концов.
Если вам нужно изменить модуль - медицина бессильна пишите свой, наследуйтесь от стандартных.
Если вы не послушаетесь и дадите слабину хотя бы в одном – можете попрощаться с беззаботным обновлением платформы. А такая необходимость рано или поздно настанет. Не говоря о том, что искать файлы будет сложнее.
Для пользовательских модулей/компонентов/шаблонов/обработчиков должна использоваться папка /local/.
Добавляйте папку /bitrix/ в .gitignore. Если в вашем git репозитории есть файлы /bitrix/, значит, скорее всего, что-то вы делаете не так. Вы можете подумать, что есть исключения. Да, но прибегать к созданию чего-либо в папке Bitrix нужно только если по-другому никак.
2. Получать данные в template.php
Никогда, слышите, никогда не делайте этого! Я говорю о CIBlockElement::GetList (и подобных им функциях) в template.php.
Если вам нужно получить какие-то дополнительные данные используйте result_modifier.php или component_epilog.php. Серьезно. Все что Вам нужно - лишь создать файл в папке шаблона. Это займет не на много больше времени, чем писать код в самом шаблоне.
Шаблон должен быть использован только для вывода информации. Ни для чего больше. Если вычисления (получение дополнительных данных, их модификация) находятся в шаблоне, вы становитесь сильно зависимы от порядка выполнения кода.
Допустим, необходимо посчитать общее количество просмотров всех статей на странице и вывести значение. Если вы разместите вычисления в цикле вывода статей, полученное значение можно будет использовать только после последней статьи. Простая задача по переносу блока наверх страницы превратится в ад.
3. Неверное подключение скриптов и стилей сайта
Откройте свой сайт, найдите основной шаблон и откройте файл header.php.
Если вы видите что-то похожее - гоните Вашего разработчика взашей.
В Битриксе вполне неплохой механизм автоматического объединения и минификации скриптов, кроме того, Битрикс умеет перемещать JS в конец страницы, благодаря чему сайт быстрее грузится. Если кто вдруг не знал, вся эта годнота включается в настройках Главного модуля:
А теперь барабанная дробь. Ничего не получится, если вы подключали скрипты и стили дедовским способом.
Соберите скрипты из шаблона сайта, поместите их в JS файл, а потом подключите его с помощью AddHeadScript().
Тоже самое касается и стилей. Если вам необходимо подключить стили, вынесите их в отдельный файл, а потом используйте SetAdditionalCSS().
В итоге получится нечто похожее:
...или, если вы используете D7, так:
4. Неверное подключение скриптов и стилей компонента
Если с предыдущим пунктом все более-менее просто, исправить эту проблему гораздо сложнее. Давайте разбираться.
Допустим, для главной страницы сайта необходимо разработать слайдер с баннерами. Ок. Что может быть проще.
И Вы правильно подумали, что переносить стили (и скрипты) в основной шаблон сайта (/local/templates/[ваш сайт]/template_styles.css и /local/templats/[ваш сайт]/script.js) не стоит - иначе они будут подключаться на каждой странице.
Но многие разработчики просто помещают css и js в файл template.php шаблона компонента и на этом успокаиваются. Правильным же подходом будет создание файлов script.js и style.css в папке шаблона. Они подключатся автоматически и избавят от головной боли при разработке.
5. Отключение кеширования
Кеширование позволяет значительно снизить нагрузку на БД. Это более остро чувствуется при росте аудитории (и соответственно запросов к БД).
Обычная ситуация: верстальщику не нравится, что изменения стилей отображаются не сразу и он решает отключить кеширование отдельного компонента. Работа кипит, сроки горят и он (верстальщик) просто забывает включить кеширование обратно. Проходит время и страницы сайта начинают грузиться все дольше и дольше.
Мой совет: перед сдачей проекта прогнать сайт через монитор производительности. Он покажет ошибки в разработке и вам не придется искать проблемные компоненты вручную.
6. Вложенные циклы при получении элементов инфоблока
Очень часто при разработке нового компонента возникает необходимость получать данные из двух (или больше) связанных Инфоблоков.
Давайте рассмотрим пример: нужно получить список всех деталей, подходящих ко моделям автомобилей.
$dbModels = CIBlockElement::GetList(
array(
'SORT' => 'ASC',
'NAME' => 'ASC',
),
array(
'IBLOCK_ID' => MODELS_IBLOCK,
'ACTIVE' => 'Y',
),
false,
false,
array(
'ID',
'NAME',
)
);
while ($arModels = $dbModels->GetNext()) {
$dbItem = CBIBlockElement::GetList(
array(
'SORT' => 'ASC',
'NAME' => 'ASC',
),
array(
'IBLOCK_ID' => ITEMS_IBLOCK,
'ACTIVE' => 'Y',
'PROPERTY_MODELS_VALUE' => $arModels['ID'],
),
false,
false,
array(
'NAME',
'PROPERTY_COUNT',
'PROPERTY_PRICE',
)
);
while ($arItem = $dbItem->GetNext()) {
// TODO: какая-то работа
}
}
Код упрощен для простоты восприятия, матерые разработчики найдут в нем сразу несколько ошибок;)
Суть в чем: чем больше на сайте будет моделей, тем больше будет SQLзапросов с получением данных о запчастях. Более правильным был бы такой вариант:
$dbModels = CIBlockElement::GetList(
array(
'SORT' => 'ASC',
'NAME' => 'ASC',
),
array(
'IBLOCK_ID' => MODELS_IBLOCK,
'ACTIVE' => 'Y',
),
false,
false,
array(
'ID',
'NAME',
)
);
while ($arModels = $dbModels->GetNext()) {
$modelIDs[] = $arModels['ID'];
}
$dbItem = CBIBlockElement::GetList(
array(
'SORT' => 'ASC',
'NAME' => 'ASC',
),
array(
'IBLOCK_ID' => ITEMS_IBLOCK,
'ACTIVE' => 'Y',
'PROPERTY_MODELS_VALUE' => $modelIDs,
),
false,
false,
array(
'NAME',
'PROPERTY_COUNT',
'PROPERTY_PRICE',
)
);
while ($arItem = $dbItem->GetNext()) {
// TODO: какая-то работа
}
В этом случае, вне зависимости от количества элементов инфоблока, будет всего 2 SQL запроса: получение моделей и получение деталей. А уже дальше в цикле должна быть проведена работа по распределению деталей на соответственные модели автомобилей.
Вообще, подобных ошибок очень много:
- Использование сортировки там, где она не нужна;
- Получение всех полей и свойств, даже если они не используются;
- Программная реализация постраничной навигации (вместо механизма Битрикс);
- Получение данных без учета активности элемента, раздела или дат активности и тд.
Перечислять все ушло бы очень много времени.
7. Бездумная разработка компонентов Bitrix
Не самым лучшим решением будет разрабатывать сайт целиком на самописных компонентах. Мотивация может быть разная: «Стандартный компонент делает слишком мало», «Стандартный компонент делает слишком много», «Шаблон слишком массивный, а в данных не разобраться», «Работает не так как я хочу», «Работает так как я хочу, но не очень».
Почему не стоит делать это? По целому ряду причин:
- От ошибок никто не застрахован. Но в случае стандартных компонентов можно расcчитывать, что их рано или поздно исправят, а ваша (если вы разработчик) ответственность закончится после сдачи проекта.
- Компоненты Битрикс в некоторых случаях сложны и запутаны. Сделано это ради гибкости. Уверен, если делать упор на универсальность, в конечном итоге компонент получится похожим на стандартный (а то и будет еще запутаннее:)).
- Если в будущем изменится структура данных, логика работы, а бОльшая часть сайта была написана сторонними разработчиками, поддержка проекта превратится в настоящий ад с постоянным переписыванием десятка компонентов.
В общем, прежде чем приступить к созданию очередного компонента, задайте себе вопрос: «А не возникнет ли проблем у Заказчика через год или два?».
Вместо заключения
Конечно, это лишь малая часть тех ужасов, с которыми приходится сталкиваться, получая очередной проект на поддержку. Я постарался собрать самые часто встречаемые.
