Чому слід переносити проект на bitrix? Перенесення контенту в інфоблоки бітрікс. Знижки на ліцензії

Станіслав Шашалевіч

Настав час, коли власникам бізнесу не треба пояснювати, навіщо потрібний сайт чи інтернет-магазин. Тепер вони це самостійно вбирають на етапі розвитку бізнесу. Настав час пояснювати клієнту: яка ж CMSплатформа найкраще підходить для його бізнесу? А пояснити це набагато складніше, коли клієнт має вже проект на своїй платформі, то переконати його в необхідності переходу на іншу платформу – дуже складне завдання. Але, на наш погляд, із платформою 1С-Бітріксце завдання вирішується значно легше, ніж з іншими e-commerceплатформ.

Тож запрошуємо вас до розгляду 10 причинчому необхідно переходити на 1С-Бітрікс.

1. 1С-інтеграція

Це одна з найприємніших «плюшок» платформи 1С-Бітрікс. У 2007 році «Бітрікс»створив спільне підприємство із компанією "1С" – «1С-Бітрікс». На наш погляд, саме цей факт надав активного розвитку даній платформі. Настала нова ера, коли 1С-інтеграція перетворилася із найскладнішого завдання на чітку схему простих дій.

На просторах інтернету ви можете знайти «страшилки», в яких інтеграція в Бітрікс представляється як щось складне і дороге. Насправді такі «страшилки» вигадують ті, хто не дуже добре знає всі нюанси інтеграції і самої 1С. Проблеми з інтеграцією можуть виникнути лише у таких випадках:

• Шаблон сайту розроблений без розуміння особливостей 1С-інтеграції
• Сама 1С вже добре перепиляна
• Низька кваліфікація розробників

Якщо ж у нас йде стандартний сайт від 1С-Бітрікста стандартна 1С, то проблем з інтеграцією просто не повинно. Унікальність та складність ваших внутрішніх бізнес-процесів додають складності до 1С-інтеграції. Але це не вина Бітрікс- Це особливості вашої компанії.

А на доказ нашої правоти ми надаємо відеоурок, на якому наші фахівці показують, як зробити інтеграцію з1Слише за30 хвилин. І жодних фокусів. Тільки факти!

2. CRM інтеграція

Якщо 1С-інтеграцієювже нікого не здивувати і це є обов'язковим функціоналом будь-якої e-commerceсистеми, то ось CRM-інтеграціятільки набирає обертів. Але й тут Бітрікснамагається бути попереду всіх.

В коробці 1С-Бітріксвже йде стандартний функціонал із синхронізації даних з CRM Bitrix24. Це дозволяє відділу продажів більш ефективно працювати з лідами, угодами та новими контактами. Прямо з коробки ви отримуєте готовий інструмент роботи з продажами.

Дуже злободенна на даний момент тема, яка, до того ж, є головним аргументом щодо перенесення проекту на Бітріксвже цього 2017 року.

З 1 лютого 2017року контрольно-касова технікаповинна відправляти електронні версіїчеків оператору фіскальних даних - нові правила встановлені в 54-ФЗ ст.2 п.2.

На повну силу закон запрацює з 1 липня 2017 року. Кожен інтернет-магазин повинен мати касовий пристрій(ККТ), підключений до Інтернету та з'єднаний з оператором фіскальних даних (ОФД).

Що це означає? Якщо простими словами, то з 1 липня 2017року за кожним замовленням, оплаченим онлайн (не за виставленим рахунком) через ваш інтернет-магазин, потрібно вибивати чек ККМ, заносити його до бази сайту, відправляти в електронному виглядіпокупцю, та ще й безліч даних відразу ж надавати в податкову. І на все це відводиться все 5 хвилин, інакше на вас чекає штраф.

Як вам таке завдання? На наш погляд, дуже нетривіальна. Що нам подобається в БітріксеТак це те, що він оперативно реагує на всі зміни ринку. Він не зациклюється на ідеалізації свого продукту, а просто міряє пульс усіх складових е-commerceта миттєво реагує.

Ось і тут 1С-Бітріксоперативно відреагував і відразу ж запровадив функціонал, який задовольняє всі вимоги 54-ФЗ. Наскільки нам відомо, на даний момент Бітрікс на власному майданчику тестує зв'язку: інтернет-магазин – ККТ – податкові органи. Тому до 1 липнями будемо у всеозброєнні разом з Бітрікс.

Ми вважаємо, що це дуже вагомий аргумент перенесення проекту на платформу 1С-Бітрікссаме в 2017 року- Повна відповідність 54-ФЗ. Думаємо, що у цьому плані будуть проблеми у багатьох платних e-commerceплатформ, не кажучи вже про безкоштовні. Власнику бізнесу буде просто необхідно звернути свою увагу саме на 1С-Бітрікс, щоб надійно закрити питання з 54-ФЗ.

4. Маркетингові інструменти

Ми всі чули про маркетингові здібності 1С-Бітрікс. Хтось тихо заздрить каже, що це головна складова успіху цієї компанії. Але давайте не заздритимемо, а просто перейматимемо досвід Бітрікс. Благо, сама компанія 1С-Бітріксіз задоволенням ділиться усіма своїми інструментами безпосередньо у самій платформі.

Зараз ми розповімо вам про найцікавіші, як нам здається, маркетингових інструментах, які додадуть балів на користь прийняття рішення про перенесення проекту на Бітрікс:

• Маркетинг електронної пошти. Дозволять працювати з покупцями в автоматичному режимі через поштові розсилки. Вже заготовлені сценарії ланцюжків тригерних листів мотивують клієнта до повернення на сайт та оформлення нових замовлень.
• Товарний маркетинг. Мотивація клієнтів акціями та знижками завжди давала позитивний ефект. А Бітрікс пропонує гнучкі можливості налаштування, щоб мати можливість впливати на кожну групу користувачів.

Але маркетинг від Бітрікс- Це не просто інструменти, вшиті в коробку. Це комплекс матеріалів, спрямованих на підвищення освіти клієнта у онлайн-продажах. Це комплекс систематизованих дій, які допоможуть набрати обертів вашому магазину.

5. SEO інструменти

SEO- Було, є і буде важливим інструментом залучення трафіку на сайт. Ми як розробники власного SEOрішення, приділяємо цьому особливу увагу.

На жаль, до 2013 року SEOскладова платформи 1С-Бітріксбула дуже слабо розвинена. Неможливо було гнучко генерувати звичайні мета-теги, а про складніші завдання. Але з 14 версії Бітріксвсе змінилось. Тепер SEOінструменти платформи включають:

• Шаблонізатори мета-тегів
• Розумна генерація карти сайту
• Генерація robots.txt
• Надсилання унікального текстув Яндекс
• І багато іншого

Зараз можна з упевненістю говорити, що платформа 1С-Бітріксстане відмінним помічником для SEO-фахівця.

BigData– це зараз не лише модно, а й необхідно. Покупець вже не оцінить просто пропозицію придбати товари в інтернет-магазині. Покупець оцінить, якщо магазин запропонує те, що йому потрібно. Для цього і призначені подібні послуги.

Компанія Бітріксі в цьому напрямку відреагувала оперативно та запустила свій хмарний сервіс «1C-Бітрікс BigData». Це дозволяє робити персональні пропозиції клієнту, тобто аналізуючи його поведінкові дії за певними алгоритмами, пропонувати необхідний йому товар. Виведення персональних товарів може відбуватися як у публічній частині сайту, так і в розсилках.

Зверніть увагу, що подібний сервіс від Бітріксне просто збільшить ваш продаж, але й позитивно вплине на підвищення лояльності до вашого інтернет-магазину.

7. Партнерська мережа

Партнерська мережа – це те, завдяки чому росте 1С-Бітрікс. Нині у мережі налічується понад 13 000 партнерів. І з кожним днем ​​їх стає дедалі більше.

Що ж така велика мережа дає бізнесу?

По-перше, ви отримуєте можливість підібрати розробника за такими параметрами:

• Бюджет проекту
• Кваліфікація та експертність розробника
• Регіональність

По-друге, відпадає будь-яка прив'язка до конкретного розробника, який із-за самописної системи дозволяє вам диктувати свої умови. Партнерська мережа прибирає подібні обмеження і робить ваш проект відчуженим, тобто його може прийняти практично будь-який партнер 1С-Бітрікс.

Що стосується вибору безпосереднього партнера, то, на наш погляд, це найважливіший та найвідповідальніший етап. Саме від нього залежить, яким вийде ваш проект. Бітрікс, звичайно, намагається якось відфільтрувати і підібрати для вас відповідних розробників, але, як ми думаємо, поки що це не завжди добре виходить. Той самий статус "Золотий партнер"не дає жодних гарантій вашому проекту. Адже, як ми вважаємо, дуже низький поріг входу для отримання цього статусу і варто його підняти.

Хоч це і не тема поточної статті, але все ж таки, виходячи з вище викладеного, ми можемо вам дати пару рекомендацій:

• Кейси партнера. Ретельно ознайомлюйтесь з проектами, які вже реалізував розробник, схожі на вашу тематику. Задавайте уточнюючі питання щодо кейсів. Не соромтесь.
• Експертність. Обов'язково потрібно перевіряти кваліфікацію партнера. Перевірка починається з першого дотику. Грамотними уточнювальними питаннями партнер розкриє ваш проект, а своїми переконливими відповідями на питання розіб'є всі ваші сумніви.

Більш детально цю темуми намагатимемося розкрити у наступних статтях. Проблема дуже важлива. Адже часто через несумлінних партнерів весь негатив виплескується убік Бітрікс. Щоб якось виправдати себе, вигадуються нібито недоробки та упущення самої платформи. Від подібних партнерів страждає вся спільнота 1С-Бітрікс. Саме після таких розробників власники інтернет-магазинів не хочуть працювати з Бітріксвзагалі.

8. E-commerce платформа №1

Як не парадоксально, але це найпростіший і важливий аргумент на користь переходу на Бітрікс.

Виходячи з графіка, видно, що близько 60% ринкукомерційних CMSзараз займає саме компанія 1С-Бітрікс. А 6 з 10, навряд, можуть помилятися. Вони зробили свій вибір, ретельно аналізуючи всі плюси та мінуси продукту. Вам же тепер набагато простіше прийняти правильне рішення, наслідуючи їх приклад.

Хочеться побажати Бітріксущоб він на цьому не зупинявся і постарався не просто утримувати поточну частку ринку, а й збільшив її. А рости є куди: 40% ринку комерційних CMS. безкоштовні системи. 1С-Бітрікспросто повинен створювати такі умови і таку платформу, яку просто захочеться переходити.

9. 1С-Бітрікс.Маркетплейс

Найсмачніше ми вирішили лишити на потім. Створення власного майданчика продажу Маркетплейсу 2011 році відкрило перед 1С-Бітрікснові можливості. Адже завдяки цьому кроку популяризація Бітріксзросла як серед розробників, і у безпосередньо учасників онлайн-продажів. І причин тому кілька:

• Типові рішення - Швидкий старт продажів. Після запуску 1 З-Бітрікс.Маркетплейсбув великий бум на типові шаблонні рішення. Завдяки цьому клієнти реально запускали інтернет-магазини від кількох днів до тижнів, замість багатомісячних та дорогих проектів «з нуля». Це дозволяло їм швидко набратися досвіду в онлайн-продажах і вже більш усвідомлено та професійніше ставитися до розвитку свого проекту.
• Підвищення функціональності 1С-Бітрікс. Тепер те, що не встигає зробити сам Бітріксроблять його партнери. Це розширює можливості платформи та робить їх практично безмежними.
• Підвищення кваліфікації розробників.Майданчик відкрив нові можливості безпосередньо для виконавців. Тим самим сприяла зростанню кваліфікації технічних фахівців у розробці рішень під 1С-Бітрікс.

Зараз Маркетплейсвсе також рясніє готовими рішеннями і модулями. Щоправда, якість багатьох із них залишає бажати кращого. Тому безкоштовно можемо дати вам один корисна порада: перед тим, як придбати рішення, обов'язково протестуйте його роботу на вашому проекті. Обов'язково переконайтеся, що модуль має демо-режим. Якщо такого режиму немає, запитайте у розробника можливість протестувати його рішення. Особисто ми навіть не розглядаємо продукти, які не мають демо-режиму. Теж радимо всім нашим клієнтам. Набувати "кота в мішку" бажання немає. Власника інтернет-магазину треба: запалити, зацікавити та переконати. А демо-режим– саме той інструмент, який може це зробити.

10. Постійний розвиток та оновлення

Як згадувалося вище, 1С-Бітріксретельно стежить за всіма тенденціями та змінами е-commerceринку. Ви отримуєте не просто актуальний тільки сьогодні продукт, як це відбувається з самописними CMS- Ви отримуєте платформу, що постійно розвивається.

Якщо ви отримуєте рік безкоштовних оновлень. Це означає, що протягом цього часу ваш проект завжди буде в актуальному стані. А якщо ви купуєте продукти 1С-Бітрікс через нас, то ви ще й отримуєте бонуси у розмірі 20% від суми замовлення, які можете витратити на придбання наших модулів.

Хочеться відзначити, що у Бітріксє своє певне правило, яке вже довгий часне порушується: два глобальні релізи оновлень на рік. Це означає, що заздалегідь встановлюються конкретні дати та терміни впровадження цих оновлень. У призначені дати проводиться презентація релізу, а після цього планомірне його використання. Така модель роботи є дуже ефективною. Вона мотивує відділ розробки позбавлятися ідеалізації коду та допомагає оперативно давати результат безпосередньо власнику інтернет-магазину.

Ось тут, здається, можна зупинитися. Усього 10 причин, але кожну причину Бітрікс"вистраждав". Кожна причина пройшла випробування часом, невдалими експериментами, що не відбулися гіпотезами. Сподіваємось, що 1С-Бітріксподарує нам нові причини, щоб працювати саме на цій платформі.

За весь час своєї роботи з Бітріксом мені довелося попрацювати з дуже великою кількістю проектів, які хтось розробляв до мене. Тут і дрібні доопрацювання, фікс різних багів та помилки роботи логіки, редизайн сайту та глобальні зміни існуючого функціоналу. І, як і будь-який інший розробник, я терпіти не можу розгрібати чуже сміття, милиці та «тимчасові» латки, які насправді пам'ятають ще 8 редакцію продукту.

Тут я постараюся не акцентувати увагу на стандартних «worst practice» при програмуванні на PHP, типу байдужого ставлення до виборів імен змінних та функцій, зайвих запитів до БД у циклі, відсутності перевірок даних у формах, ігнорування коментарів тощо. Я спробую торкнутися саме моментів, властивих розробці на Бітріксі, які згодом дозволять уникнути обурення та прокльонів на вашу адресу від програміста, якому випало супроводжувати ваш код. І так, нерідко цим програмістом будете ви самі через рік, або більше, коли вже зовсім забудете, навіщо ви вставляли сюди той чи інший милиця.

«Пишіть код так, ніби супроводжуватиме його схильний до насильства психопат, який знає, де ви живете» (с) Джон Ф. Вудс

Перше, і саме, на мій погляд, важливе - заради всього святого, використовуйте папку local. Це просто життєво необхідно при використанні системи контролю версій - все, що вам потрібно - додати папку /bitrix/. Всі. Далі майже вся технологія ведеться тільки в ній. Це помітно спрощує пошук потрібних файлів і компонентів згодом, допомагає не засмічувати репозиторій зайвими файлами, та й взагалі – наводить дерево проекту на більш охайний, «людський» вигляд.

Не модифікуйте ядро. Навіть якщо ви впевнені, що воно не оновлюватиметься. Навіть якщо так швидше. Навіть якщо вам ліньки. Забудьте цю думку як страшний сон. Якщо необхідно змінити логіку роботи стандартного компонента, перенесіть його в новий простір імен /local/components/modify/ та працюйте з ним. Те ж саме стосується модулів, гаджетів та діяльності бізнес-процесів.

Не засмічуйте файл init.php. Поєднуйте функції для роботи з якимсь конкретним модулем або функціоналом у клас, весь цей клас записуйте в окремий файл, а в init.php просто підключайте ці файли та прописуйте обробники подій. Мені зустрічалися файли init.php по 500Kb, де в кашу були змішані функції, визначення констант, класи та ініціалізація обробників. Зрозуміло, коли доводилося розумітися на цих файлах, я сипав прокльонами на своїх попередників.

Наступний пункт не стосується випадку розробки готових рішеньдля Marketplace, коли метою ставиться зробити функціонал, що максимально налаштовується, з публічної частини для кінцевого споживача. Якщо ви працюєте над конкретним проектом, за конкретним ТЗ – не варто намагатися зробити уніфікований шаблон для компонента на всі випадки життя. Особисто я дотримуюся філософії - краще кілька простих шаблонів, що використовуються для різних цілей, ніж один універсальний, але в якому сам чорт потім зломить ногу. Зрозуміло, у кожному конкретному випадку потрібно відштовхуватися від того, що є – техзавдання, варіанти реалізації тощо, але деякі дуже завзято використовують «Бритву Оккама». Як приклад, наведу один проект лізингової компанії, який мені довелося правити. Сам проект, звичайно, був реалізований жахливо, справжній жах був у сторінках розділу каталогу послуг. У кожного з п'яти розділів була власна верстка, на яких відрізнялося положення блоків на сторінці, так і в принципі наявність деяких з них. І для всіх п'яти сторінок використовувався один шаблон з купою if-else, дублюванням викликів компонентів, підключенням стилів та скриптів, які періодично конфліктували один з одним. Як результат – величезний файл, в якому розібратися «без півлітри» було подібно до смерті. Хоча, здавалося б, що заважало зробити 5 різних шаблонів і не створювати труднощів на рівному місці?

Використовуйте API. Не вигадуйте велосипеди там, де не потрібно. Юзайте документацію - весь продукт досить добре описаний, а також кожну функцію можна подивитись детально на bxapi.ru.

Уникайте прямих запитів до бази. Це окремий випадокпопереднього пункту – використовуйте API. Необдумані, незахищені запити можуть призвести до псування, втрати або навіть компрометації даних.

Не використовуйте компоненти з ЧПУ з кореня сайту. Наслідки, як правило, досить сумні, оскільки ЧПУ використовує файл обробника адрес, спроба використовувати його з кореня легко ламає вам адресацію інших компонентів, а також 404 сторінки. Нічого страшного не буде, якщо статті у вас будуть адресуватися щодо папки /articles/, а товари щодо /catalog/.

Підключайте css та js за допомогою API.Досі повсюдно зустрічаю підключення скриптів та стилів за допомогою тегів

За весь час своєї роботи з Бітріксом мені довелося попрацювати з дуже великою кількістю проектів, які хтось розробляв до мене. Тут і дрібні доопрацювання, фікс різних багів та помилки роботи логіки, редизайн сайту та глобальні зміни існуючого функціоналу. І, як і будь-який інший розробник, я терпіти не можу розгрібати чуже сміття, милиці та «тимчасові» латки, які насправді пам'ятають ще 8 редакцію продукту.

Тут я постараюся не акцентувати увагу на стандартних «worst practice» при програмуванні на PHP, типу байдужого ставлення до виборів імен змінних та функцій, зайвих запитів до БД у циклі, відсутності перевірок даних у формах, ігнорування коментарів тощо. Я спробую торкнутися саме моментів, властивих розробці на Бітріксі, які згодом дозволять уникнути обурення та прокльонів на вашу адресу від програміста, якому випало супроводжувати ваш код. І так, нерідко цим програмістом будете ви самі через рік, або більше, коли вже зовсім забудете, навіщо ви вставляли сюди той чи інший милиця.

«Пишіть код так, ніби супроводжуватиме його схильний до насильства психопат, який знає, де ви живете» (с) Джон Ф. Вудс

Перше, і саме, на мій погляд, важливе - заради всього святого, використовуйте папку local. Це просто життєво необхідно при використанні системи контролю версій - все, що вам потрібно - додати папку /bitrix/. Всі. Далі майже вся технологія ведеться тільки в ній. Це помітно спрощує пошук потрібних файлів і компонентів згодом, допомагає не засмічувати репозиторій зайвими файлами, та й взагалі – наводить дерево проекту на більш охайний, «людський» вигляд.

Не модифікуйте ядро. Навіть якщо ви впевнені, що воно не оновлюватиметься. Навіть якщо так швидше. Навіть якщо вам ліньки. Забудьте цю думку як страшний сон. Якщо необхідно змінити логіку роботи стандартного компонента, перенесіть його в новий простір імен /local/components/modify/ та працюйте з ним. Те ж саме стосується модулів, гаджетів та діяльності бізнес-процесів.

Не засмічуйте файл init.php. Поєднуйте функції для роботи з якимсь конкретним модулем або функціоналом у клас, весь цей клас записуйте в окремий файл, а в init.php просто підключайте ці файли та прописуйте обробники подій. Мені зустрічалися файли init.php по 500Kb, де в кашу були змішані функції, визначення констант, класи та ініціалізація обробників. Зрозуміло, коли доводилося розумітися на цих файлах, я сипав прокльонами на своїх попередників.

Наступний пункт не стосується випадку розробки готових рішень для Marketplace, коли метою ставиться зробити функціонал, що максимально настроюється, з публічної частини для кінцевого споживача. Якщо ви працюєте над конкретним проектом, за конкретним ТЗ – не варто намагатися зробити уніфікований шаблон для компонента на всі випадки життя. Особисто я дотримуюся філософії - краще кілька простих шаблонів, що використовуються для різних цілей, ніж один універсальний, але в якому сам чорт потім зломить ногу. Зрозуміло, у кожному конкретному випадку потрібно відштовхуватися від того, що є – техзавдання, варіанти реалізації тощо, але забувати про «Бритву Оккама» таки не варто. Як приклад, наведу один проект лізингової компанії, який мені довелося правити. Сам проект, звичайно, був реалізований жахливо, справжній жах був у сторінках розділу каталогу послуг. У кожного з п'яти розділів була власна верстка, на яких відрізнялося положення блоків на сторінці, так і в принципі наявність деяких з них. І для всіх п'яти сторінок використовувався один шаблон з купою if-else, дублюванням викликів компонентів, підключенням стилів та скриптів, які періодично конфліктували один з одним. Як результат – величезний файл, в якому розібратися «без півлітри» було подібно до смерті. Хоча, здавалося б, що заважало зробити 5 різних шаблонів і не створювати труднощів на рівному місці?

Використовуйте API. Не вигадуйте велосипеди там, де не потрібно. Юзайте документацію - весь продукт досить добре описаний, а також кожну функцію можна подивитись детально на bxapi.ru.

Уникайте прямих запитів до бази. Це окремий випадок попереднього пункту – використовуйте API. Необдумані, незахищені запити можуть призвести до псування, втрати або навіть компрометації даних.

Не використовуйте компоненти з ЧПУ з кореня сайту. Наслідки, як правило, досить сумні, оскільки ЧПУ використовує файл обробника адрес, спроба використовувати його з кореня легко ламає вам адресацію інших компонентів, а також 404 сторінки. Нічого страшного не буде, якщо статті у вас будуть адресуватися щодо папки /articles/, а товари щодо /catalog/.

Підключайте css та js за допомогою API.Досі повсюдно зустрічаю підключення скриптів та стилів за допомогою html-тегів. Використовуйте об'єкт класу \Bitrix\Main\Page\Asset та функції addJs() та addCss(). Це дозволить об'єднувати файли і, згодом, кешувати їх одним натисканням чекбокса в налаштуваннях головного модуля

Ну і насамкінець, помилка стосується не тільки Бітрікса, але вже дуже часто я став зустрічати проблеми, пов'язані з нею. Перевіряйте на порожнечу масив із результатами вибірки. Як приклад, останній раз зустрівся з цією проблемою під час роботи з одним інтернет-магазином. Скарга: сторінки іноді вантажаться по 16 секунд. З чим пов'язано – не зрозуміло. Методом спроб і помилок з'ясував, що сторінки вантажаться непристойно довго лише тоді, коли кошик порожній. Здавалося, з чого? Як з'ясувалося, у кошику при наведенні з'являлося спливаюче вікно, в якому відображалися зображення товару, покладеного в кошик. Ну, що зробив попередній розробник? Взяв результат роботи компонента «маленький кошик» і у файлі result_modifier.php зробив виклик GetList() товарів для вибірки зображень з фільтром з масиву ID товарів, потім з результатів вибірки масив відповідного товару додавав src зображення. У результаті, коли товарів у кошику не було, фільтр йшов порожній, і у вибірку потрапляв ВЕСЬ каталог товарів. Ну а далі цикл по кожному і маємо те, що маємо. Зрозуміло, що на етапі розробки при 15 тестових товарах це було непомітно, і проблеми виникли вже в бойових умовах. Хоча, здавалося б, чого варто поставити перевірку на empty($arResult[‘ITEMS’])…

На цьому я закінчую свій особистий топ "worst practice" щодо розробки на Бітрікс. Якщо хоч комусь дана інформація допоможе уникнути помилок у майбутньому та покращити свій стиль розробки, значить це було недаремно.

Ви можете допомогти і перевести небагато коштів на розвиток сайту

За весь час своєї роботи з Бітріксом мені довелося попрацювати з дуже великою кількістю проектів, які хтось розробляв до мене. Тут і дрібні доопрацювання, фікс різних багів та помилки роботи логіки, редизайн сайту та глобальні зміни існуючого функціоналу. І, як і будь-який інший розробник, я терпіти не можу розгрібати чуже сміття, милиці та «тимчасові» латки, які насправді пам'ятають ще 8 редакцію продукту.

Тут я постараюся не акцентувати увагу на стандартних «worst practice» при програмуванні на PHP, типу байдужого ставлення до виборів імен змінних та функцій, зайвих запитів до БД у циклі, відсутності перевірок даних у формах, ігнорування коментарів тощо. Я спробую торкнутися саме моментів, властивих розробці на Бітріксі, які згодом дозволять уникнути обурення та прокльонів на вашу адресу від програміста, якому випало супроводжувати ваш код. І так, нерідко цим програмістом будете ви самі через рік, або більше, коли вже зовсім забудете, навіщо ви вставляли сюди той чи інший милиця.

«Пишіть код так, ніби супроводжуватиме його схильний до насильства психопат, який знає, де ви живете» (с) Джон Ф. Вудс

Перше, і саме, на мій погляд, важливе - заради всього святого, використовуйте папку local. Це просто життєво необхідно при використанні системи контролю версій - все, що вам потрібно - додати папку /bitrix/. Всі. Далі майже вся технологія ведеться тільки в ній. Це помітно спрощує пошук потрібних файлів і компонентів згодом, допомагає не засмічувати репозиторій зайвими файлами, та й взагалі – наводить дерево проекту на більш охайний, «людський» вигляд.

Не модифікуйте ядро. Навіть якщо ви впевнені, що воно не оновлюватиметься. Навіть якщо так швидше. Навіть якщо вам ліньки. Забудьте цю думку як страшний сон. Якщо необхідно змінити логіку роботи стандартного компонента, перенесіть його в новий простір імен /local/components/modify/ та працюйте з ним. Те ж саме стосується модулів, гаджетів та діяльності бізнес-процесів.

Не засмічуйте файл init.php. Поєднуйте функції для роботи з якимсь конкретним модулем або функціоналом у клас, весь цей клас записуйте в окремий файл, а в init.php просто підключайте ці файли та прописуйте обробники подій. Мені зустрічалися файли init.php по 500Kb, де в кашу були змішані функції, визначення констант, класи та ініціалізація обробників. Зрозуміло, коли доводилося розумітися на цих файлах, я сипав прокльонами на своїх попередників.

Наступний пункт не стосується випадку розробки готових рішень для Marketplace, коли метою ставиться зробити функціонал, що максимально настроюється, з публічної частини для кінцевого споживача. Якщо ви працюєте над конкретним проектом, за конкретним ТЗ – не варто намагатися зробити уніфікований шаблон для компонента на всі випадки життя. Особисто я дотримуюся філософії - краще кілька простих шаблонів, що використовуються для різних цілей, ніж один універсальний, але в якому сам чорт потім зломить ногу. Зрозуміло, у кожному конкретному випадку потрібно відштовхуватися від того, що є – техзавдання, варіанти реалізації тощо, але забувати про «Бритву Оккама» таки не варто. Як приклад, наведу один проект лізингової компанії, який мені довелося правити. Сам проект, звичайно, був реалізований жахливо, справжній жах був у сторінках розділу каталогу послуг. У кожного з п'яти розділів була власна верстка, на яких відрізнялося положення блоків на сторінці, так і в принципі наявність деяких з них. І для всіх п'яти сторінок використовувався один шаблон з купою if-else, дублюванням викликів компонентів, підключенням стилів та скриптів, які періодично конфліктували один з одним. Як результат – величезний файл, в якому розібратися «без півлітри» було подібно до смерті. Хоча, здавалося б, що заважало зробити 5 різних шаблонів і не створювати труднощів на рівному місці?

Використовуйте API. Не вигадуйте велосипеди там, де не потрібно. Юзайте документацію - весь продукт досить добре описаний, а також кожну функцію можна подивитись детально на bxapi.ru.

Уникайте прямих запитів до бази. Це окремий випадок попереднього пункту – використовуйте API. Необдумані, незахищені запити можуть призвести до псування, втрати або навіть компрометації даних.

Не використовуйте компоненти з ЧПУ з кореня сайту. Наслідки, як правило, досить сумні, оскільки ЧПУ використовує файл обробника адрес, спроба використовувати його з кореня легко ламає вам адресацію інших компонентів, а також 404 сторінки. Нічого страшного не буде, якщо статті у вас будуть адресуватися щодо папки /articles/, а товари щодо /catalog/.

Підключайте css та js за допомогою API.Досі повсюдно зустрічаю підключення скриптів та стилів за допомогою html-тегів. Використовуйте об'єкт класу \Bitrix\Main\Page\Asset та функції addJs() та addCss(). Це дозволить об'єднувати файли і, згодом, кешувати їх одним натисканням чекбокса в налаштуваннях головного модуля

Ну і насамкінець, помилка стосується не тільки Бітрікса, але вже дуже часто я став зустрічати проблеми, пов'язані з нею. Перевіряйте на порожнечу масив із результатами вибірки. Як приклад, останній раз зустрівся з цією проблемою під час роботи з одним інтернет-магазином. Скарга: сторінки іноді вантажаться по 16 секунд. З чим пов'язано – не зрозуміло. Методом спроб і помилок з'ясував, що сторінки вантажаться непристойно довго лише тоді, коли кошик порожній. Здавалося, з чого? Як з'ясувалося, у кошику при наведенні з'являлося спливаюче вікно, в якому відображалися зображення товару, покладеного в кошик. Ну, що зробив попередній розробник? Взяв результат роботи компонента «маленький кошик» і у файлі result_modifier.php зробив виклик GetList() товарів для вибірки зображень з фільтром з масиву ID товарів, потім з результатів вибірки масив відповідного товару додавав src зображення. У результаті, коли товарів у кошику не було, фільтр йшов порожній, і у вибірку потрапляв ВЕСЬ каталог товарів. Ну а далі цикл по кожному і маємо те, що маємо. Зрозуміло, що на етапі розробки при 15 тестових товарах це було непомітно, і проблеми виникли вже в бойових умовах. Хоча, здавалося б, чого варто поставити перевірку на empty($arResult[‘ITEMS’])…

На цьому я закінчую свій особистий топ "worst practice" щодо розробки на Бітрікс. Якщо хоч комусь дана інформація допоможе уникнути помилок у майбутньому та покращити свій стиль розробки, значить це було недаремно.

За весь час своєї роботи з Бітріксом мені довелося попрацювати з дуже великою кількістю проектів, які хтось розробляв до мене. Тут і дрібні доопрацювання, фікс різних багів та помилки роботи логіки, редизайн сайту та глобальні зміни існуючого функціоналу. І, як і будь-який інший розробник, я терпіти не можу розгрібати чуже сміття, милиці та «тимчасові» латки, які насправді пам'ятають ще 8 редакцію продукту.

Тут я постараюся не акцентувати увагу на стандартних «worst practice» при програмуванні на PHP, типу байдужого ставлення до виборів імен змінних та функцій, зайвих запитів до БД у циклі, відсутності перевірок даних у формах, ігнорування коментарів тощо. Я спробую торкнутися саме моментів, властивих розробці на Бітріксі, які згодом дозволять уникнути обурення та прокльонів на вашу адресу від програміста, якому випало супроводжувати ваш код. І так, нерідко цим програмістом будете ви самі через рік, або більше, коли вже зовсім забудете, навіщо ви вставляли сюди той чи інший милиця.

«Пишіть код так, ніби супроводжуватиме його схильний до насильства психопат, який знає, де ви живете» © Джон Ф. Вудс

Перше, і саме, на мій погляд, важливе - заради всього святого, використовуйте папку local. Це просто життєво необхідно при використанні системи контролю версій - все, що вам потрібно - додати папку /bitrix/. Всі. Далі майже вся технологія ведеться тільки в ній. Це помітно спрощує пошук потрібних файлів і компонентів згодом, допомагає не засмічувати репозиторій зайвими файлами, та й взагалі – наводить дерево проекту на більш охайний, «людський» вигляд.

Не модифікуйте ядро. Навіть якщо ви впевнені, що воно не оновлюватиметься. Навіть якщо так швидше. Навіть якщо вам ліньки. Забудьте цю думку як страшний сон. Якщо необхідно змінити логіку роботи стандартного компонента, перенесіть його в новий простір імен /local/components/modify/ та працюйте з ним. Те ж саме стосується модулів, гаджетів та діяльності бізнес-процесів.

Не засмічуйте файл init.php. Поєднуйте функції для роботи з якимсь конкретним модулем або функціоналом у клас, весь цей клас записуйте в окремий файл, а в init.php просто підключайте ці файли та прописуйте обробники подій. Мені зустрічалися файли init.php по 500Kb, де в кашу були змішані функції, визначення констант, класи та ініціалізація обробників. Зрозуміло, коли доводилося розумітися на цих файлах, я сипав прокльонами на своїх попередників.

Наступний пункт не стосується випадку розробки готових рішень для Marketplace, коли метою ставиться зробити функціонал, що максимально настроюється, з публічної частини для кінцевого споживача. Якщо ви працюєте над конкретним проектом, за конкретним ТЗ не варто намагатися зробити уніфікований шаблон для компонента на всі випадки життя. Особисто я дотримуюся філософії — краще кілька простих шаблонів, що використовуються для різних цілей, ніж один універсальний, але в якому сам чорт потім зломить ногу. Зрозуміло, у кожному конкретному випадку треба відштовхуватися від того, що є техзавдання, варіанти реалізації тощо, але забувати про «Бритву Оккама» все-таки не варто. Як приклад, наведу один проект лізингової компанії, який мені довелося правити. Сам проект, звичайно, був реалізований жахливо, справжній жах був у сторінках розділу каталогу послуг. У кожного з п'яти розділів була власна верстка, на яких відрізнялося положення блоків на сторінці, так і в принципі наявність деяких з них. І для всіх п'яти сторінок використовувався один шаблон з купою if-else, дублюванням викликів компонентів, підключенням стилів та скриптів, які періодично конфліктували один з одним. Як підсумок — величезний файл, у якому розібратися «без півлітри» було подібно до смерті. Хоча, здавалося б, що заважало зробити 5 різних шаблонів і не створювати труднощів на рівному місці?

Використовуйте API. Не вигадуйте велосипеди там, де не потрібно. Юзайте документацію - весь продукт досить добре описаний, а також кожну функцію можна подивитись детально на bxapi.ru.

Уникайте прямих запитів до бази. Це окремий випадок попереднього пункту - використовуйте API. Необдумані, незахищені запити можуть призвести до псування, втрати або навіть компрометації даних.

Не використовуйте компоненти з ЧПУ з кореня сайту. Наслідки, як правило, досить сумні, оскільки ЧПУ використовує файл обробника адрес, спроба використовувати його з кореня легко ламає вам адресацію інших компонентів, а також 404 сторінки. Нічого страшного не буде, якщо статті у вас будуть адресуватися щодо папки /articles/, а товари щодо /catalog/.

Підключайте css та js за допомогою API.Досі повсюдно зустрічаю підключення скриптів та стилів за допомогою html-тегів. Використовуйте об'єкт класу \Bitrix\Main\Page\Asset та функції addJs () та addCss (). Це дозволить об'єднувати файли і, згодом, кешувати їх одним натисканням чекбокса в налаштуваннях головного модуля

Ну і насамкінець, помилка стосується не тільки Бітрікса, але вже дуже часто я став зустрічати проблеми, пов'язані з нею. Перевіряйте на порожнечу масив із результатами вибірки. Як приклад, останній раз зустрівся з цією проблемою під час роботи з одним інтернет-магазином. Скарга: сторінки іноді вантажаться по 16 секунд. З чим пов'язано – не ясно. Методом спроб і помилок з'ясував, що сторінки вантажаться непристойно довго лише тоді, коли кошик порожній. Здавалося, з чого? Як з'ясувалося, у кошику при наведенні з'являлося спливаюче вікно, в якому відображалися зображення товару, покладеного в кошик. Ну, що зробив попередній розробник? Взяв результат роботи компонента «маленький кошик» і у файлі result_modifier.php зробив виклик GetList () товарів для вибірки зображень з фільтром з масиву ID товарів, потім з результатів вибірки масив відповідного товару додавав src зображення. У результаті, коли товарів у кошику не було, фільтр йшов порожній, і у вибірку потрапляв ВЕСЬ каталог товарів. Ну а далі цикл по кожному і... маємо те, що маємо. Зрозуміло, що на етапі розробки при 15 тестових товарах це було непомітно, і проблеми виникли вже в бойових умовах. Хоча, здавалося б, чого варто поставити перевірку на empty ($arResult[«ITEMS»])…

На цьому я закінчую свій особистий топ "worst practice" щодо розробки на Бітрікс. Якщо хоч комусь дана інформація допоможе уникнути помилок у майбутньому та покращити свій стиль розробки, значить це було недаремно.