Зразковий section php. Сповідь бітрікс хейтера

). Кожен тег (section)повинен мати пару (/section). Обов'язковими параметрами є nameі loop. Ім'я циклу (section) може бути будь-яким, що складається з літер, цифр та знаків підкреслення. Цикли (section)можуть бути вкладеними та імена вкладених (section) мають бути унікальними між собою. Змінна loop(Зазвичай - масив значень) визначає кількість ітерацій циклу. Під час друку змінних усередині секції, ім'я секції має бути вказано поруч із ім'ям змінної усередині квадратних дужок . (sectionelse)виконується у тому випадку, якщо параметр loopне містить значень.

Ім'я атрибуту	Тип	Обов'язковий	За замовчуванням	Опис
name	string	Так	n/a	Назва секції
loop	mixed	Так	n/a	Значення, що визначає кількість ітерацій циклу.
start	integer	Ні	0	Індекс позиції, з якої починається цикл. Якщо значення негативне, початкова позиція обчислюється від кінця масиву. Наприклад, якщо змінної циклу 7 елементів і значення атрибута start дорівнює -2, то початковий індекс буде 5. Невірні значення (значення, поза масивом) автоматично обрізаються до найближчого вірного значення.
step	integer	Ні	1	Значення кроку, який використовується для проходу масивом. Наприклад, step=2 вказує обхід масиву елементами 0,2,4... Якщо крок негативний, то обхід масиву буде у зворотному напрямку.
max	integer	Ні	1	Максимальна кількість ітерацій циклу.
show	boolean	Ні	true	Вказує, показувати чи ні цю секцію

Note

Починаючи з Smarty 1.5.0, синтаксис змінних властивостей сесій був змінений з (%sectionname.varname%) на ($smarty.section.sectionname.varname). Старий синтаксис все ще підтримується, але ви побачите приклади нового синтаксису.

index використовується для відображення поточного індексу масиву, починаючи з нуля (або з атрибуту start, якщо він був вказаний) і збільшуючись на одиницю (або значення атрибута step, якщо він був вказаний).

Технічне зауваження

Якщо атрибути step і start не вказані, index аналогічний атрибуту секції iteration, крім того, що починається з 0, а не з 1.

iteration використовується для відображення поточного номера циклу ітерації.

Note

Це значення залежить від властивостей start, step і max, на відміну властивості index . З іншого боку, ітерації починаються з одиниці, а чи не з нуля, як індекси. rownum - це синонім до властивості iteration, вони працюють однаково.

7.38. властивість (section) iteration

assign("custid", $id); ?> (section name=cu loop=$custid start=5 step=2) iteration=($smarty.section.cu.iteration) index=($smarty.section.cu.index) id=($custid)
(/section)

Результат виконання цього прикладу:

Iteration=1 index=5 id=3005
iteration=2 index=7 id=3007
iteration=3 index=9 id=3009
iteration=4 index=11 id=3011
iteration=5 index=13 id=3013
iteration=6 index=15 id=3015

Цей приклад використовує властивість iteration виведення заголовка таблиці через кожні п'ять рядків (використовує (if) з оператором mod - залишок від розподілу).

(section name=co loop=$contacts) (if $smarty.section.co.iteration % 5 == 1) (/if) (/section)

	Name>	Home	Cell	Email
view	($contacts.name)	($contacts.home)	($contacts.cell)	($contacts.email)

Стаття, в якій розглядається HTML-елемент section із категорії sectioning.

Призначення елемента section

Елемент section використовується для створення секції у документі, яка групує певний тематичний контент разом. Для кожної секції у документі слід зазначати її назву (тему). Це зазвичай здійснюється за допомогою заголовків (елементів h1 - h6).

Заголовок секції

Вміст секції.

Елементи section зазвичай застосовуються в наступних випадках:

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

Таким чином, елемент section варто застосовувати для деякого контенту тільки в тому випадку, якщо він має заголовок і є частиною чогось іншого.

Застосування елемента section

Наприклад, розглянемо фрагмент коду сторінки, що містить статтю з коментарями. Кожен із коментарів, залишених користувачем на сторінці, містить певний завершений контент і, отже, може розглядатися як елемент article . Проте, у водночас всі коментарі представляють деяку тематичну групу, отже їх можна помістити елемент section , тобто. Цей елемент згрупує всі ці коментарі на сторінці разом.

Назва статті

Коментарі

Заголовок коментаря

Текст коментаря...

Заголовок коментаря

Текст коментаря...

Назва статті Коментарі Тема коментару Заголовок коментаря

Наприклад, розглянемо застосування елементів section для створення розділів усередині елемента article:

Назва книги

Перша глава

Другий розділ

Третій розділ

Додаток A

Додаток B

Наведений вище приклад матиме таку структуру (outline):

Назва книги Перший розділ Другий розділ Третій розділ Додаток A Додаток B

Обмеження при використанні елемента section

Елемент section в HTML 5 є універсальним елементом для групування вмісту, тобто. його не слід використовувати для обертання будь-якого контенту, що сподобався. Його основне призначення - це додавання семантики в документ і створення його структури (outline).

Коли автору необхідно згрупувати контент, тільки для того, щоб застосувати до нього стилі або попрацювати з ним у сценарії JavaScript, йому в цьому випадку найкраще скористатися елементом div . Елемент div на відміну елемента section , не додає семантики в документ і бере участь у створенні його структури (outline).

Відмінність між елементами section та article

Елементи section і article хоч і здаються здавалося б дуже схожими, але мають різне семантичне значення. Елемент article призначений для групування контенту, який є чимось завершеним, самостійним і який може розглядатися окремо від решти вмісту сторінки. А елемент section несе в собі інший семантичний зміст, він призначений для угруповання контенту, який є складовою чогось іншого.

Але як автору дізнатися, що являє собою певний контент на сторінці? Давайте розглянемо це з прикладу фрагмента статті. Фрагмент - це частина статті і, отже, для угруповання його контенту необхідно використовувати елемент section . Але цей же фрагмент, вже залишений як коментар, буде чимось цілим, завершеним. Отже, у цьому контексті для його угруповання можна використовувати елемент article . Але міркувати, звісно, можна й навпаки. Тому, який елемент використовуватиме угруповання контенту, у більшості випадків залежить від вашої суб'єктивної думки як автора. Але найголовніше у цьому підході підтримуватись обраної позиції. Тому чим автор буде послідовнішим у створенні структури, тим він зможе більше сенсу в неї вкласти.

Шаблони в бітриксі можна розділити на кілька типів:

Шаблони звичайних та комплексних компонентів 2.0
Шаблони сайту
Шаблони інших сутностей (поштових відправлень, випусків розсилок, веб-форм, генераторів експортів та ще багато чого)

У шаблонах компонентів є можливість використовувати шаблонизаторы. В принципі можна підключити будь-який шаблонизатор, але з коробки допоміжних інструментів немає. Якщо комусь треба, є у мене пара посилань на розширення для twig і blade, які працюють і цілком собі використовуються на продакшені. Але й тут бітріксоїди перекрутилися. Шаблонізатор можна використовувати лише з компонентами. Підключити шаблонизатор до рендерера шаблону сайту або інших сутностей не вийде, т.к. немає там жодного рендерера.

У шаблонах компонентів дратує ще момент із їх розміщенням. Компонент підключається за допомогою нехитрої конструкції
$APPLICATION->IncludeComponent("bitrix:catalog.section", "template_name", );
Як другий параметр йде назва шаблону компонента. Так ось залежно від різних умов, розташування цього шаблону може бути в найнесподіваніших місцях:

bitrix/components/bitrix/catalog.section/templates/template_name
local/components/bitrix/catalog.section/templates/template_name
bitrix/templates/.default/components/bitrix/catalog.section/template_name
bitrix/templates/site_template/components/bitrix/catalog.section/template_name
local/templates/.default/components/bitrix/catalog.section/template_name
local/templates/site_template/components/bitrix/catalog.section/template_name
bitrix/components/bitrix/catalog/templates/.default/bitrix/catalog.section/template_name
local/templates/site_template/components/bitrix/catalog/.default/bitrix/catalog.section/template_name

І це ще я не всі варіанти перерахував…

Шаблон сайту можна розглядати як набір файлів: header.php, footer.php (так, у сайту обов'язково вони повинні бути), description.php (системний опис шаблону сайту), template_styles.css (стилі шаблону сайту), директорію з шаблонами компонентів та Ще група менш значущих файликів. І все. І ніяк на це не вплинути нічого з цим не зробити. Неможливо підчепити шаблонизатор.

Про інші шаблони і говорити нема чого. Вони або просто зберігаються в БД у вигляді верстки з включенням до неї якихось «змінних» даних, або це тупий php файл, який виконує всю роботу, від вибірки параметрів з БД до виведення інформації. Наприклад, можна подивитися на генератор YML файлу для маркету. Немає ніякого сенсу викладати його сюди просто тому, що він досить великий, близько 2к рядків. Кому потрібно, той нагуглить, лежить він у /bitrix/modules/catalog/load/yandex_run.php

Файлова природа

Як стало ясно вище, у бітріксі з архітектурою все не дуже добре. Але є бітрикс і ще один важливий аспект архітектури.
Бітрікс – це на половину файлова CMS. Дуже багато речей управляються за допомогою якихось файлів:

Потрібна сторінка - створи файл
Потрібен набір сторінок - створи файл та підключи там компонент, що працює з інфоблоками
Потрібно задати title для сторінки - відредагуй файл
Потрібно задати title для всіх сторінок розділу - створи спеціальний файл.section.php у корені цього розділу
Потрібно відредагувати права – редагуй файл.access.php
Налаштування до ініціалізації системи - у файлі dbconn.php, .settings.php та .settings_extra.php
result_modifier.php, component_epilog.php, init.php, .parameters.php, .description.php ....

І таких спеціальних файликів по бітрікс розкидане безліч. З одного боку, це дає певну гнучкість під час роботи з системою. З іншого - це може перетворитися на муку як для розробника, так і для менеджера сайту. Файли сторінок іноді перетворюються на кашу з php коду, верстки, і компонентів, що підключаються. В результаті візуальний редактор може некоректно розпарсувати цей файл, і при редагуванні він запросто може екранувати теги php в деяких місцях, що призведе до непрацездатності сторінки. Ви скажете – не треба писати php код у таких файлах? Так я знаю. Але бітрікс дуже часто і безальтернативно змушує так вчинити.
Та і в голові потрібно пам'ятати постійно інформацію про те, що це за файли такі, і які дані вони можуть містити. У різних файлах повинні бути різні дані з різною структурою, і потрібно її пам'ятати для кожного варіанту. У документації шукати це щоразу – важка праця.

На додаток до вищесказаного

Можна нескінченно скаржитися на те, як все погано влаштовано у бітріксі. На мою думку, всі ці скарги можна охарактеризувати одним словосполученням – «якось не до кінця». І справді, якщо раптом бітріксоїди анонсують якусь фішку, то вони її релізують якось не повністю, не доробляють, не доводять до пуття. Прикладів – маса:

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

У двох словах спробую охарактеризувати решту проблем, з якими доводиться стикатися щодня.

Адмінка

Якщо хтось працював із адмінкою, створював свої сторінки в адміністративній частині так, як це пропонує робити бітрікс, той мене зрозуміє. Це просто пекло. Для тих, хто не в курсі – бітрікс пропонує для кожної сторінки використовувати файл із локшиною. Наприклад, сторінка детального перегляду замовлення в адмінці у виконанні розробників бітрикса займає over 4к рядків. У мене IDE починає підгальмовувати під час перегляду вмісту цього файлу. Там тобі і php, і js, і html. Добре хоч, SQL позбулися, хоча я впевнений, що на інших адміністративних сторінках він є.
І що заважало зробити роботу адміністративних сторінок за допомогою тих самих компонентів – не зрозуміло. Кастомізувати більшість адміністративних сторінок просто немає жодної можливості. У випадку з компонентами це можна було б зробити за дві секунди.
До речі, добрі люди зробили модуль, який допоможе вам у побудові адміністративних сторінок

js-фреймворк

У бітрікс є js складова, яка виконує роль якогось клієнтського фреймворку. Ніхто з розробників не любить його з кількох причин:

він майже не документований
він монструозний
він багато в чому дублює звичний багатьом jquery

Бітрікс дуже часто використовує його у своїх компонентах, цим викликаючи ще більше гніву розробників. Ядро цієї бібліотеки в мініфікованому вигляді становить 85кб, що дуже багато. Уникнути його підключення не вийде, якщо ви хочете використовувати всі можливості бітрикса (композит, asset-management).

Дух копіпасти

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

Asset-management та CDN

Дуже мені подобається в бітріксі спосіб управління ресурсами. В принципі можна зареєструвати набір певних «бібліотек». Кожна бібліотека - це набір файлів css/js, який може залежати від якихось інших бібліотек. Якщо підключити якусь бібліотеку на сторінку, перед її підключенням будуть дозволені всі залежності та всі залежні бібліотеки будуть вставлені на сторінку. Все як би добре, тільки кожен ресурс буде вставлений у вигляді окремого файлу в тег script або link. І завдяки цьому існують сайти, у яких підключено по 30-50 скриптів та стільки ж файлів стилів.
Гівне питання, сказали в бітріксі, і зробили чарівну галочку, яка об'єднує всі ці файли в один. І з'явилися сайти, де замість 50 скриптів стало 2, кожний по 300-500кб. Якийсь час тому це об'єднання працювало з помилками і об'єднувало одні й ті самі ресурси кілька разів, але зараз начебто виправили.
І тут бітріксоїди викрутилися - прикрутили можливість вивантажити всі ресурси на CDN сервер. Який вічно відвалюється.
З'явився Google Pagespeed Insights, який рекомендував опустити всі ресурси в нижню частину сторінки. І в бітріксі знову зробили чарівну галочку, яка тупо опускає всі ресурси в body, якщо вони не позначені спеціальним атрибутом.
А ще вони разом із коробкою розповсюджують мініфіковані версії своїх скриптів, які підключаються при використанні ще однієї чарівної галочки в адмінці.
Загалом ніяких вам scss, ніяких TypeScript. Хочете грамотно керувати ресурсами - не використовуйте вбудовану систему бітрикса, юзайте webpack, який можна спокійно подружити з бітриксом.

Багатосайтовість / багатомовність

Це, напевно, найстрашніший головний біль розробника, який триває з моменту зародження продукту. Не можна просто так взяти і створити багатомовний сайт. А якщо вам потрібен багатомовний каталог з різними цінами та валютами - то це перетворюється на борошно, за яке потрібно ще й викласти кругленьку суму (на покупку додаткової ліцензії для чергової мовної версії сайту доведеться розщедритися).
Якщо ви створюєте багатомовний та багатовалютний сайт, то будьте готові до того, що бітрикс буде дуже агресивно чинити опір цьому. Налаштування багатосайтовості децентралізовані по всій адмінці. Кожна сутність в адмінці має залежність від мовної версії сайту. Якісь сутності можуть взагалі не підтримувати залежності від сайту/мови, а якісь мають лише однозначну прив'язку до мови, так що доведеться цю сутність продублювати і потім підтримувати.
У базовому варіанті, щоб змусити інфоблок працювати кількома мовами, вам доведеться створити дубль цього інфоблоку. Але на практиці ніхто цього не робить, і намагається вигадати свої способи зберігання однієї сутності централізовано, розносячи її мовнозалежні атрибути за іншими сховищами.
Не можна встановити дефолтну мову при локалізації. Якщо у вас є мовна змінна, що описує якусь фразу російською, і цієї мовної змінної немає в англійському виконанні, то на англійському сайті буде показано порожній рядок, і ніяк на це не можна вплинути (у багатьох випадках можна було б залишити російську фразу щоб не було порожнеч).

Механізм управління правами

Дуже замудрили з цією підсистемою. Часто буває складно розібратися, чому ти видав права перегляду якоїсь сутності, а користувач не може ними скористатися. Наприклад, щоб дати право на редагування інфоблоку, потрібно дати доступ до директорії /bitrix/admin, видати права для конкретного інфоблоку та видати права у головному модулі. Занадто багато операцій потрібно зробити, щоб видати права на одну сутність. А якщо прав не вистачає, то без колупання у вихідниках ніяк не вийде зрозуміти – чому.

Конфігурування

У бітриксі немає централізованого хаба, який дозволив би керувати налаштуваннями системи. Налаштування знову децентралізовані по всій системі. Опції є в налаштуваннях модуля, в налаштуваннях компонентів, в COption (не винесені в адмінку). В адмінці опції одного модуля можуть бути рознесені по 3-4м різним сторінкам, які знаходяться в різних місцях. urlrewrite можна правити через адмінку! Тепер і.settings і.settings_extra. Іноді зовсім не ясно, які з них пріоритетніші, дуже часто не вистачає пояснень для опцій, незрозумілі взаємозв'язки. Немає нативного способу розшарувати конфігурацію між розробниками.
Установки бувають дуже нелогічними. Іноді доходить до абсурду… подивіться компонент бігдати – хіба його зможе налаштувати непідготовлена людина?

Інтеграція з 1С

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

Доопрацювання обміну з 1С – це теж окрема тема. За організацію обміну каталогом відповідає клас \CIBlockCMLImport.- 5.7к рядків. Один з головних методів, який найчастіше вимагає розширення - \CIBlockCMLImport::ImportElement, містить більше 1к рядків. Досить раз успадкуватись, кілька разів оновити продукт протягом тривалого часу, і можна отримати непрацюючий обмін з 1С. Тому часто розробники не лізуть у цей клас і намагаються якось влізти у процес імпорту за допомогою обробників подій. Працювати з обробниками подій у бітріксі, особливо в модулі інфоблоків – теж не дуже приємне заняття, хоча б через те, що однотипні події влаштовані не однорідно, а деяких подій просто не вистачає.
Загалом із цим справи також сумно, як і раніше.

Неузгодженість

Мені часом здається, що розробники різних модулів не особливо спілкуються між собою. Вивчаючи вихідники ядра натикаєшся на дуже різноманітні рішення, які можна було б виконати на одному движку, але вони реалізовані чомусь по-різному.
Для прикладу можна взяти властивості елементів інфоблоків та UserFields. І та й інша сутність за фактом є додатковим полем для іншої сутності. Вона має тип, має значення та опис. Значення зберігається в окремій таблиці БД, мають приблизно схожий інтерфейс доступу до даних. Тож чому б не зробити для них однаковий інтерфейс?
Ось наприкінці березня оновився модуль sale до останньої версії і там також обіцяли довільні властивості для замовлень. Невже там тепер новий, третій інтерфейс роботи з розширеними властивостями сутності?

Бітрікс24

Це взагалі окрема тема розмови. На ґрунті цієї системи часто виникає плутанина. Є 2 варіанти виконання Б24 - SaaS та Standlone. Є маркетплейс для Б24, але в ньому містяться програми лише для SaaS версії! Якщо у вас коробкова версія, куплена за 200 шматків, ви не зможете поставити таку популярні програми, як конструктор документів, та й взагалі ви не зможете на свій Бітрікс24 поставити жодну програму з маркетплейсу для Бітрікс24. Ось такий феномен.
Натомість у вашому Бітрікс24 буде доступний маркетплейс від звичайної версії. Там рішень набагато більше, але вони сконцентровані переважно навколо Управління Сайтом, а не Б24.

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

До речі, доопрацьовувати компоненти в коробковій версії Б24 - це завдання. Компоненти, що генерують js код, який за допомогою ajax звертається до php коду, який у відповідь генерує html+js. Це пекло суміш, в яку дуже не хочеться занурюватися.

Документація

Документація з бітриксу відстає розвитку продукту на 1-1.5 року. Код дуже слабко покритий phpDoc"ами, і часто коментар перед класом стоїть виключно "для галочки", будучи автоматично згенерованим в IDE.
Сам стиль викладу документації в офіційних джерелах часто буває надто «вільним», а вміст деяких статей у документації може не мати жодного відношення до самого бітрікса.
Курс розробника має дуже багато інформації, проте формат, у якому розробника знайомлять із можливостями системи, не дає того рівня сприйняття, який потрібно. Якщо ви зайдете в Cookbook Symfony, то все розкладено по поличках, розписані всі необхідні аспекти в залежності від версії. Тоді як у бітрікс курс навчання розробника містить незрозуміло за яким принципом структуровану інформацію по старому і новому ядру, яка подається спочатку окремо, а потім упереміш, від чого у початківців виникає головний біль.

Організація процесу розробки

Через специфічність системи не так просто організувати зручний процес розробки. Не найсвіжіша версія редакції Бізнес (що була під рукою) після встановлення займає, вдумайтеся, майже 530 мегабайт
$ du -s *|sort -nr|cut -f 2-|while read a;do du -hs $a;done 523M bitrix 204K upload 64K bitrixsetup.php 56K desktop_app 20K readme.html 20K license.html 4,0K .config 4,0K urlrewrite.php 4,0K readme.php 4,0K license.php 4,0K install.config 4,0K index.php
З цього обсягу добра половина - це бінарники та настановники, які загалом не потрібні для версійного контролю. Взагалі, прийнято не версіонувати бітриксове ядро. Розробники Бітрікса хіба що самі гарантують цілісність ядра, керують самі залежностями версій різних модулів під час оновлень. Але це несе в собі відразу, як мінімум, один великий мінус - неможливо однією командою з версійного контролю розгорнути проект, що повністю працює, доводиться збирати його частинами: вихідники ядра діставати з бітриксового бекапа, а вихідники розробників - з git.
З базою теж все не гаразд. Якщо самі ви можете використовувати міграції під час розробки, то бітрикс накочує оновлення до бази за допомогою звичайних скриптів, які ви не можете контролювати. Тому при оновленнях все одно доведеться перекидати бекапи баз від центрального хоста до інших розробників.
Добрі люди, знову ж таки, пиляють інструменти, які допомагають це все організувати, але змусити бітрикс дотримуватися цих правил на жаль досі не вдається.
Офіційно бітрикс дозволяє мати дві копії одного дистрибутива. Один – для продакшена, другий – для розробки. Якщо у вас кілька розробників на одному проекті - то ви, як би, поза законом) Насправді, досить відрубати машині з бітриксом вхідні та вихідні підключення з/на www.bitrixsoft.com, і тоді можна наклепати скільки завгодно багато копій розробки, просто вони не зможуть самостійно оновлюватись.

Колеги

І останнє питання, яке хотілося б торкнутися.
У зв'язку з тим, що бітрікс має низький поріг входження, серед компаній, які надають послуги на цьому ринку дуже багато некваліфікованих кадрів. Мені довелося побачити багато різних проектів за свою кар'єру (сумарно більше сотні), виконаних на 1С-Бітрікс. Можу з упевненістю сказати, що 95% із них було виконано «тяп-ляп». Дуже рідко траплялися проекти, до розробки яких відчувався підхід, але це були одиниці. Це все дуже сумно.

Висновки

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

Які тут можна дійти висновків. Бітрікс - украй складна система у зв'язку з тим, що має непродуману архітектуру, безліч вад, які так і продовжують жити в продукті протягом тривалого часу. З іншого боку, Бітрікс - це досить проста система, яка для старту вимагає набагато менший рівень кваліфікації, на відміну від фреймворків.
Підтримка цього продукту - дуже невдячне заняття порівняно з такими продуктами, як Symfony, Laravel, Yii. Продукт дуже любить вставляти палиці в колеса як недосвідченим, так і досвідченим розробникам, що, своєю чергою, може відбиватися і на вартості послуг досвідчених розробників під Бітрікс.

Чи шкодую я, що так багато часу витратив на роботу з цією системою? Скоріше так ніж ні. Розумніше було б витратити цей час на вивчення чогось більш правильного і більш логічного (ніж я намагаюсь активно займатися зараз). Але так уже вийшло, що не було кому мене спрямувати в правильне русло на початку мого шляху.

Якщо ви - початківець php розробник, то віддайте перевагу Бітрікс вивчення фреймворків, таких як Symfony, Laravel, Yii, ZendFramework. Повірте, у майбутньому це з лишком окупиться. Освоївши будь-який з цих фреймворків вам не важко буде в майбутньому розробляти щось під Бітрікс. Якщо у вас немає вибору, то вивчайте Бітрікс, але у вільний час краще все-таки намагатися поринути у світ фреймворків, щоб поставити мізки на місце.

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

Якщо ви – замовник, то не вірте маркетологам Бітрікса. Нічого не буде так легко, як розповідають у презентах бітрікса. І не звинувачуйте в цьому своїх розробників, вони тут не до чого. Якщо ви хочете створити великий і складний інтернет-магазин рівня ельдорадо/мвідео/спортмайстер, то, можливо, Бітрікс буде не найкращим вибором.

UPD.Очевидно, що статтю прочитали співробітники бітрикса. У розділі про маркетинг я писав, що в розділі Архітектура в курсі розробника Бітрікс написані маркетингові заклики. Тепер їх там нема. Навіть опечаталися, мабуть, поспішали дуже.

Дякую за спостережливість та пильне око:)

Теги:

1с-бітрікс
cms
web-розробка
комор
hatebitrix
скиглики на хабрі
візьми себе в руки

Додати теги