7 смертних гріхів розробки на 1С-Бітрікс

1. 1. Змінювати все стандартне / Змінювати вміст папки Bitrix Зміна за все, що лежить в папці / bitrix...
2. 3. Неправильне підключення скриптів і стилів сайту
3. 4. Неправильне підключення скриптів і стилів компонента
4. 5. Відключення кешування
5. 6. Вкладені цикли при отриманні елементів Інфоблоки
6. 7. Бездумна розробка компонентів Bitrix
7. замість висновку

1. Змінювати все стандартне / Змінювати вміст папки Bitrix

Наша взаимовыгодная связь https://banwar.org/

Зміна за все, що лежить в папці / 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чітивать, що їх рано чи пізно виправлять, а ваша (якщо ви розробник) відповідальність закінчиться після здачі проекту.
• Компоненти Бітрікс в деяких випадках складні і заплутані. Зроблено це задля гнучкості. Упевнений, якщо робити упор на універсальність, в кінцевому підсумку компонент вийде схожим на стандартний (а то і буде ще заплутаніше :)).
• Якщо в майбутньому зміниться структура даних, логіка роботи, а більша частина сайту була написана сторонніми розробниками, підтримка проекту перетвориться на справжнє пекло з постійним переписуванням десятка компонентів.

Загалом, перш ніж приступити до створення чергового компонента, задайте собі питання: «А чи не виникне проблем у Замовника через рік або два?».

замість висновку

Звичайно, це лише мала частина тих жахів, з якими доводиться стикатися, отримуючи черговий проект на підтримку. Я постарався зібрати самі часто зустрічаються.