Примерен раздел php. Изповедта на един хейтър на Bitrix

). Всеки етикет (раздел)трябва да има двойка (/раздел). Задължителните параметри са имеИ цикъл. Името на цикъла (раздела) може да бъде всичко, състоящо се от букви, цифри и долна черта. Цикли (раздел)могат да бъдат вложени и имената на вложените секции трябва да са уникални един за друг. Променлива цикъл(обикновено масив от стойности) определя броя на повторенията на цикъла. Когато отпечатвате променливи в рамките на раздел, името на раздела трябва да бъде посочено до името на променливата в квадратни скоби. (друга секция)се изпълнява, ако параметърът цикълне съдържа стойности.

Име на атрибут	Тип	Задължително	По подразбиране	Описание
име	низ	да	няма	Име на раздел
цикъл	смесен	да	няма	Стойност, която указва броя повторения на цикъла.
започнете	цяло число	Не	0	Индексът на позицията, от която ще започне цикълът. Ако стойността е отрицателна, тогава началната позиция се изчислява от края на масива. Например, ако променливата на цикъла има 7 елемента и стойността на началния атрибут е -2, тогава началният индекс ще бъде 5. Невалидните стойности (стойности извън масива) автоматично се изрязват до най-близката валидна стойност.
стъпка	цяло число	Не	1	Стойността на стъпката, използвана за преминаване на масива. Например стъпка=2 показва обхождането на масива от елементи 0,2,4... Ако стъпката е отрицателна, тогава масивът ще бъде обходен в обратна посока.
макс	цяло число	Не	1	Максималният брой повторения на цикъла.
шоу	булево	Не	вярно	Показва дали да се покаже този раздел или не

Забележка

От Smarty версия 1.5.0 синтаксисът на променливата на свойството на сесията е променен от (%sectionname.varname%) на ($smarty.section.sectionname.varname). Старият синтаксис все още се поддържа, но ще видите само примери за новия синтаксис.

index се използва за показване на текущия индекс на масива, като се започне от нула (или началния атрибут, ако е зададен такъв) и се увеличава с единица (или стойността на атрибута стъпка, ако е зададен такъв).

Техническа бележка

Ако атрибутите стъпка и начало не са посочени, тогава индексът е същият като атрибута на секцията за итерация, с изключение на това, че започва от 0, а не от 1.

iteration се използва за показване на текущия номер на итерация на цикъла.

Забележка

Тази стойност не зависи от свойствата start, step и max, за разлика от свойството index. Освен това итерациите започват от единица, а не от нула като индексите. rownum е синоним на свойството итерация, те работят еднакво.

Пример 7.38. итерация на свойство (секция).

присвояване ("custid", $id); ?> (име на раздел=cu loop=$custid start=5 стъпка=2) iteration=($smarty.section.cu.iteration) index=($smarty.section.cu.index) id=($custid)
(/раздел)

Резултатът от изпълнението на този пример:

Итерация=1 индекс=5 id=3005
итерация=2 индекс=7 id=3007
итерация=3 индекс=9 id=3009
итерация=4 индекс=11 id=3011
итерация=5 индекс=13 id=3013
итерация=6 индекс=15 id=3015

Този пример използва свойството итерация за отпечатване на заглавката на таблицата на всеки пет реда (използвайки (if) с оператора mod).

(име на раздел=co loop=$contacts) (ако $smarty.section.co.iteration % 5 == 1) (/ако) (/раздел)

	Име>	У дома	клетка	електронна поща
изглед	($contacts.name)	($contacts.home)	($contacts.cell)	($contacts.email)

Статия, която разглежда HTML елемента раздел от категорията разделяне.

Предназначение на елемента на сечението

Елементът section се използва за създаване на раздел в документ, който групира заедно някакво тематично съдържание. За всеки раздел в документа трябва да се посочи неговото име (тема). Това обикновено се прави с помощта на заглавия (елементи h1 - h6).

Заглавие на раздел

Съдържание на раздела...

Елементите на секциите обикновено се използват в следните случаи:

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

По този начин елементът section трябва да се използва само за някакво съдържание, ако има заглавие и е част от нещо друго.

Използване на елемента section

Например, разгледайте фрагмент от код на страница, съдържащ статия с коментари. Всеки от коментарите, оставени от потребител на страница, съдържа някакво пълно съдържание и следователно може да се счита за елемент на статия. Но в същото време всички коментари представляват определена тематична група и следователно могат да бъдат поставени в елемента раздел, т.е. този елемент ще групира всички тези коментари на страницата заедно.

Заглавие на статията

Коментари

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

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

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

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

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

Например, обмислете използването на елементи на секции за създаване на секции в елемент на статия:

Заглавие на книга

Първа глава

Глава втора

Глава трета

Приложение А

Приложение Б

Горният пример ще има следната схема:

Заглавие на книгата Първа глава Втора глава Трета глава Приложение A Приложение B

Ограничения при използване на елемента section

Елементът section в HTML 5 не е универсален елемент за групиране на съдържание, т.е. не трябва да се използва за обвиване на съдържание, което харесвате. Основната му цел е да добави семантика към документа и да създаде неговата структура (контур).

Когато автор трябва да групира съдържание само за да го стилизира или манипулира в JavaScript, елементът div е най-добрият залог. Елементът div, за разлика от елемента section, не добавя семантика към документа и не участва в създаването на неговата структура (контур).

Разлика между елементите на секция и статия

Елементите раздел и статия, въпреки че на пръв поглед изглеждат много сходни, имат различно семантично значение. Елементът article е предназначен да групира съдържание, което е пълно, самостоятелно и може да се разглежда отделно от останалото съдържание на страницата. Елементът section има различно семантично значение; той е предназначен да групира съдържание, което е част от нещо друго.

Но как един автор знае какво е съдържанието на дадена страница? Нека да разгледаме това, използвайки пример от фрагмент от статия. Фрагментът е част от статия и следователно изисква елемент на раздел за групиране на съдържанието му. Но същият този фрагмент, вече оставен като коментар, ще представлява нещо цяло, завършено. Следователно в този контекст можете да използвате елемента article, за да го групирате. Но, разбира се, може да се твърди и обратното. Следователно кой елемент да използвате за групиране на съдържание зависи в повечето случаи от вашето субективно мнение като автор. Но най-важното в този подход е да запазите избраната позиция. Следователно, колкото по-последователен е авторът в създаването на структурата, толкова повече смисъл ще може да вложи в нея.

Шаблоните в Bitrix могат да бъдат разделени на няколко типа:

Редовни и сложни 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 файловия генератор за пазара. Няма смисъл да го публикувам тук, просто защото е доста голям, около 2k реда. Който има нужда може да го гугълне, има го в /bitrix/modules/catalog/load/yandex_run.php

Естество на файла

Както стана ясно по-горе, в Bitrix архитектурата не е много добра. Но Bitrix има и друг важен аспект от своята архитектура.
Bitrix е CMS с половин файл. Много неща се контролират с помощта на някои файлове:

Нуждаете се от страница - създайте файл
Имате нужда от набор от страници - създайте файл и свържете там компонент, който работи с инфоблокове
Трябва да зададете заглавие на страницата - редактирайте файла
Трябва да зададете заглавие за всички страници на раздел - създайте специален файл.section.php в корена на този раздел
Трябва да редактирате правата - редактирайте файла .access.php
Настройки преди инициализация на системата - във файла dbconn.php, .settings.php и .settings_extra.php
result_modifier.php, component_epilog.php, init.php, .parameters.php, .description.php ....

И има огромен брой такива специални файлове, разпръснати из Bitrix. От една страна, това дава известна гъвкавост при работа със системата. От друга страна, това може да се превърне в мъчение както за разработчика, така и за мениджъра на сайта. Страничните файлове понякога се превръщат в бъркотия от PHP код, оформление и компоненти на добавки. В резултат на това визуалният редактор може да анализира неправилно този файл и при редактиране може лесно да избяга от PHP таговете на някои места, което ще доведе до неработеща страница. Казвате - няма нужда да пишете PHP код в такива файлове? Да, знам. Но Bitrix много често и без алтернатива ви принуждава да направите това.
И трябва постоянно да поддържате информация в главата си за това какви файлове са и какви данни могат да съдържат. Различните файлове трябва да съдържат различни данни с различна структура и трябва да ги запомните за всяка опция. Търсенето на това в документацията всеки път е трудна работа.

В допълнение към горното

Можете безкрайно да се оплаквате колко лошо работи всичко в Bitrix. Според мен всички тези оплаквания могат да бъдат характеризирани с една фраза - „някак си не напълно“. И наистина, ако Bitrixoids внезапно обявят някаква функция, тогава те по някакъв начин не я пускат напълно, не я завършват, не я довеждат до ума. Има много примери:

внедрен ORM - все още не е завършен, не може да се използва напълно
Направихме автозареждач, работи само на модули, а не по стандарти
направи възможно свързването на шаблонна машина, но не можете да я използвате навсякъде и не напълно
и т.н. и така нататък.

Накратко ще се опитам да характеризирам оставащите проблеми, с които се сблъсквам всеки ден.

Админ

Ако някой е работил с админ панела, създавал е страниците си в административната част по начина, по който Bitrix предлага да го направи, ще ме разбере. Това е просто ад. За тези, които не са запознати, Bitrix предлага да използвате файл с юфка за всяка страница. Например, страницата за подробен преглед на поръчка в админ панела, направена от разработчиците на Bitrix, заема над 4k реда. Моето IDE започва да се забавя, когато преглеждам съдържанието на този файл. Имате php, js и html. Добре, че се отърваха от SQL, въпреки че съм сигурен, че го има на други административни страници.
И какво пречи на административните страници да работят с едни и същи компоненти не е ясно. Просто няма начин да персонализирате повечето административни страници. В случай на компоненти това може да стане за нула време.
Между другото, добри хора са направили модул, който ще ви помогне да изградите административни страници

js рамка

Bitrix има js компонент, който действа като вид клиентска рамка. Никой от разработчиците не го харесва по няколко причини:

почти не е документиран
той е чудовищен
до голяма степен дублира jquery, познат на мнозина

Bitrix много често го използва в своите компоненти, като по този начин предизвиква още повече гняв сред разработчиците. Ядрото на тази библиотека в минимизиран вид е 85kb, което не е малко. Не можете да избегнете свързването му, ако искате да използвате всички възможности на Bitrix (композитен, управление на активи).

Копи-пейст дух

Напоследък все по-рядко, но все пак доста често, Bitrix ви принуждава да копи-пейстнете нещо. Ако искате да промените работата на компонент, копирайте го и го поставете. Ако искате да създадете свой собствен шаблон за качване, копирайте и поставете системния и го завършете. Ако искате да направите почти същия шаблон, който имате, копирайте го и го поставете и го променете малко. И те дори говорят за това в курсове за начинаещи разработчици. Нямам думи.

Управление на активи и CDN

Много харесвам начина, по който Bitrix управлява ресурсите. По принцип е възможно да се регистрира набор от специфични "библиотеки". Всяка библиотека е набор от css/js файлове, които може да зависят от някои други библиотеки. Ако свържете библиотека към страница, тогава преди да я свържете, всички зависимости ще бъдат разрешени и всички зависими библиотеки ще бъдат вмъкнати в страницата. Всичко изглежда наред, само всеки ресурс ще бъде вмъкнат като отделен файл в скрипта или етикета за връзка. И благодарение на това има сайтове, които имат свързани 30-50 скрипта и същия брой стилови файлове.
Това е кофти въпрос, казаха в Bitrix и направиха магическа отметка, която комбинира всички тези файлове в едно. И се появиха сайтове, където вместо 50 скрипта имаше 2, всеки по 300-500kb. Преди време това сливане работеше с грешки и обединяваше едни и същи ресурси няколко пъти, но сега изглежда е поправено.
И тогава Bitrixoids се измъкнаха от пътя им - те добавиха възможност за качване на всички ресурси на CDN сървър. Което винаги отпада...
След това се появи Google Pagespeed Insights, който препоръчва преместване на всички ресурси в долната част на страницата. И в Bitrix отново направиха магическа отметка, която глупаво пропуска всички ресурси в тялото, ако не са маркирани със специален атрибут.
Те също така разпространяват минимизирани версии на своите скриптове заедно с кутията, които се свързват, когато използвате друго магическо поле за отметка в админ панела.
Като цяло, няма scss за вас, няма TypeScript. Ако искате да управлявате ресурсите компетентно, не използвайте вградената система Bitrix, използвайте webpack, който лесно може да се сдвои с Bitrix.

Мултисайт/многоезичен

Това е може би най-лошото главоболие за разработчик, което продължава от самото начало на продукта. Не можете просто да създадете многоезичен уебсайт. И ако имате нужда от многоезичен каталог с различни цени и валути, това се превръща в брашно, за което също трябва да платите солидна сума (ще трябва да отделите пари за закупуване на допълнителен лиценз за следващата езикова версия на сайт).
Ако създавате многоезичен и многовалутен уебсайт, бъдете подготвени за факта, че Bitrix ще се съпротивлява много агресивно на това. Настройките за много сайтове са децентрализирани в административния панел. Всеки субект в админ панела има собствена зависимост от езиковата версия на сайта. Някои обекти може изобщо да не поддържат зависимости сайт/език, докато други имат само недвусмислена връзка с езика, така че този обект ще трябва да бъде дублиран и след това поддържан.
В основната версия, за да накарате един информационен блок да работи на няколко езика, ще трябва да създадете дубликат на този информационен блок. Но на практика никой не прави това и се опитва да измисли свои собствени начини за централно съхранение на един обект, разпределяйки неговите зависещи от езика атрибути към други съоръжения за съхранение.
Не можете да зададете езика по подразбиране по време на локализация. Ако имате езикова променлива, която описва някаква фраза на руски, и тази езикова променлива не е в английската версия, тогава на английския сайт ще бъде показан празен ред и това не може да бъде повлияно по никакъв начин (в много случаи можете оставете руската фраза, за да няма празнини).

Механизъм за управление на правата

Те бяха много умни с тази подсистема. Често е трудно да разберете защо сте предоставили права за преглед на даден обект, но потребителят не може да ги използва. Например, за да дадете право за редактиране на информационен блок, трябва да дадете достъп до директорията /bitrix/admin, да предоставите права за конкретен информационен блок и да предоставите права в основния модул. Трябва да се извършат твърде много операции за издаване на права за един обект. И ако няма достатъчно права, тогава без да се ровите в изходния код, няма начин да разберете защо.

Конфигурация

Bitrix няма централизиран хъб, който би ви позволил да управлявате системните настройки. Настройките отново са децентрализирани в цялата система. Опциите са налични в настройките на модула, в настройките на компонента, в COption (не се поставя в админ панела). В админ панела опциите за един модул могат да бъдат разпределени в 3-4 различни страници, които са разположени на напълно различни места. urlrewrite може да се редактира през админ панела! Сега също .settings и .settings_extra. Понякога изобщо не е ясно кои от тях са с по-висок приоритет, много често няма достатъчно обяснения за варианти и връзките са неясни. Няма собствен начин за споделяне на конфигурация между разработчиците.
Настройките могат да бъдат много нелогични. Понякога се стига до абсурд... вижте компонента bigdata - може ли необучен човек да го настрои?

Интеграция с 1C

Това е елементът от списъка с функции на Bitrix, на които доста голям брой клиенти си падат. Bitrix обещава да създаде двупосочна интеграция на сайта с 1C с 2 кликвания, което незабавно ще доставя съдържание и документи от една система в друга.
Да, наистина е така, но с няколко уговорки.
Първо, за да направите интеграцията „извън кутията“ без допълнителни усилия, трябва да направите всичко точно както е написано в документацията на Bitrix - изградете каталог на сайта според правилата, които Bitrix предлага и изградете каталога в 1C които Bitrix изисква. В идеалния случай създайте всичко от нулата и тогава може би всичко ще работи за вас от кутията.
Второ, Bitrix не е съвместим с всички 1C конфигурации извън кутията. Струва си първо да се провери
Трето, няма идеален свят. Обикновено клиент, който иска уебсайт, вече има бизнес на дребно, което означава, че вече има 1C, което е огромно сметище. И този боклук трябва да бъде изхвърлен на сайта. И за да не се окаже, че сайтът е същият боклук, механизмът за обмен трябва да бъде значително подобрен.
Много често изискванията на клиента се различават значително от визията на продукта, който екипът на Bitrix е формирал, а след това усъвършенстването на механизма за обмен може да бъде доста скъпо, сравнимо по трудоемкост с разработването на уникален модул за обмен за конкретен случай.
Ето защо не е необходимо да си правите илюзии, че ще можете лесно да интегрирате сайта си с 1C. Всичко това са машинации на търговци.

Усъвършенстването на обмена с 1C също е отделна тема. Класът \CIBlockCMLImport отговаря за организирането на обмена на каталог - 5.7k реда. Един от основните методи, който най-често изисква разширение, е \CIBlockCMLImport::ImportElement, който съдържа повече от 1k реда. Достатъчно е да го наследите веднъж, да актуализирате продукта няколко пъти за дълъг период от време и можете да получите неработещ обмен с 1C. Следователно разработчиците често не се занимават с този клас и се опитват по някакъв начин да влязат в процеса на импортиране, използвайки манипулатори на събития. Работата с манипулатори на събития в Bitrix, особено в модула за информационни блокове, също не е много приятно изживяване, дори само защото събитията от един и същи тип не са подредени равномерно и някои събития просто не са достатъчни.
Като цяло нещата са тъжни както преди.

Непоследователност

Понякога ми се струва, че разработчиците на различни модули всъщност не комуникират помежду си. Когато изучавате изходните кодове на ядрото, се натъквате на много разнородни решения, които могат да бъдат внедрени на един двигател, но по някаква причина те са внедрени по различен начин.
Например, можете да вземете свойствата на елементите на информационния блок и UserFields. И двата обекта всъщност са допълнително поле за друг обект. Има вид, значение и описание. Стойността се съхранява в отделна таблица(и) на базата данни; те имат приблизително подобен интерфейс за достъп до данни. Така че защо да не направим същия интерфейс за тях?
В края на март модулът за продажба беше актуализиран до последната версия и също така обещаха произволни свойства за поръчки. Има ли наистина нов, трети интерфейс за работа с разширени свойства на обекта?

Битрикс24

Това като цяло е отделна тема за обсъждане. Често възниква объркване поради тази система. Има 2 опции за B24 - SaaS и Standlone. Има пазар за B24, но той съдържа приложения само за SaaS версията! Ако имате версия в кутия, закупена за 200 хиляди, няма да можете да инсталирате такива популярни приложения като дизайнера на документи и като цяло няма да можете да инсталирате никакви приложения от пазара за Bitrix24 на вашия Bitrix24. Това е такъв парадокс.
Вместо това пазарът от обикновената версия ще бъде достъпен във вашия Bitrix24. Там има много повече решения, но те са съсредоточени главно около Site Management, а не B24.

Bitrix24, както ми казаха в отдела за техническа поддръжка, е холистична система. Ако пречите на работата на стандартни системни компоненти, тогава бъдете готови, че тази функционалност ще се счупи при последващи актуализации. Bitrix няма да разчита на вас да финализирате компонентите на портала и това въпреки факта, че те официално препращат клиентите си към партньори

Между другото, модифицирането на компонентите в кутията на B24 е доста трудна задача. Компоненти, които генерират js код, който чрез ajax осъществява достъп до php код, който генерира html+js в отговор. Това е адска смес, в която наистина не искате да се гмуркате.

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

Документацията на Bitrix изостава от развитието на продукта с 1-1,5 години. Кодът е много слабо обхванат от phpDocs и често коментарът преди класа е само за показ, като се генерира автоматично в IDE.
Самият стил на представяне на документацията в официалните източници често е твърде „свободен“ и съдържанието на някои статии в документацията може да няма нищо общо със самия Bitrix.
Курсът за разработчици има много информация, но форматът, в който програмистът се запознава с възможностите на системата, не осигурява необходимото ниво на възприятие. Ако отидете на Symfony Cookbook, всичко е изложено там, всички необходими аспекти са описани в зависимост от версията. Докато в Bitrix курсът за обучение на разработчици съдържа по неясен начин структурирана информация за старите и новите ядра, която се представя първо отделно, а след това се смесва, което създава главоболие на начинаещите.

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

Поради спецификата на системата не е толкова лесно да се организира удобен процес на разработка. Не най-новата версия на изданието Business (което беше под ръка) след инсталацията заема, помислете за това, почти 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 web . config 4.0K urlrewrite.php 4.0K readme.php 4.0K license.php 4.0K install.config 4.0K index.php
От този обем добрата половина са двоични файлове и инсталатори, които по принцип не са необходими за контрол на версиите. Най-общо казано, обичайно е да не се прави версия на ядрото на Bitrix. Самите разработчици на Bitrix гарантират целостта на ядрото и управляват зависимостите на версиите на различни модули по време на актуализации. Но това веднага носи поне един голям недостатък - невъзможно е да разгърнете напълно работещ проект с един екип от контрола на версиите; трябва да го сглобите на части: вземете изходните кодове на ядрото от резервното копие на Bitrix и изходните кодове на разработчиците от git .
И с основата не вървят нещата. Ако вие сами можете да използвате миграции по време на разработката, тогава Bitrix прехвърля актуализации в базата данни с помощта на обикновени скриптове, които не можете да контролирате. Следователно, когато актуализирате, все още ще трябва да прехвърляте резервни копия на базата данни от централния хост за разработка към други разработчици.
Добрите хора отново са инструменти за рязане, които помагат да се организира всичко това, но за съжаление все още не е възможно да принудите Bitrix да следва тези правила.
Официално Bitrix ви позволява да имате 2 копия на една дистрибуция. Единият е за производство, вторият е за развитие. Ако имате няколко разработчици на един проект, значи сте като че ли извън закона) Всъщност достатъчно е да прекъснете на машината с Bitrix входящите и изходящите връзки от/към www.bitrixsoft.com и тогава вие могат да занитват толкова копия на разработката, колкото искате, те просто няма да могат да се актуализират сами.

Колеги

И последният въпрос, който бих искал да засегна.
Поради факта, че Bitrix има ниска бариера за навлизане, има много неквалифициран персонал сред компаниите, които предоставят услуги на този пазар. Виждал съм много различни проекти по време на кариерата си (общо повече от сто), завършени на 1C-Bitrix. Мога да кажа с увереност, че 95% от тях са направени по "бъг" начин. Много рядко попадахме на проекти, чието разработване имаше усет за подход, но това бяха само няколко. Всичко това е много тъжно.

заключения

Разбира се, всички недостатъци не могат да бъдат разгледани в една статия. Всеки ден се сблъсквате с някакви дребни неща, които пречат на работата ви всеки ден. Но е просто невъзможно да се вземат предвид всички такива малки неща и вероятно няма нужда.

Какви изводи могат да се направят тук? Bitrix е изключително сложна система поради факта, че има лошо замислена архитектура и много недостатъци, които продължават да живеят в продукта дълго време. От друга страна, Bitrix е доста проста система, която изисква много по-ниско ниво на квалификация, за да започнете, за разлика от рамките.
Поддръжката на този продукт е много неблагодарна задача в сравнение с продукти като Symfony, Laravel, Yii. Продуктът наистина обича да поставя спиците в колелата както на неопитни, така и на опитни разработчици, което от своя страна може да се отрази в цената на услугите на опитни разработчици на Bitrix.

Съжалявам ли, че прекарах толкова много време в работа с тази система? По-скоро да, отколкото не. Би било по-разумно да прекарам това време в изучаване на нещо по-правилно и по-логично (което се опитвам активно да правя сега). Но така се случи, че нямаше кой да ме насочи в правилната посока в началото на моя път.

Ако сте начинаещ PHP разработчик, тогава ще предпочетете да изучавате рамки като Symfony, Laravel, Yii, ZendFramework пред Bitrix. Повярвайте ми, в бъдеще ще се отплати повече от това. След като усвоите някоя от тези рамки, няма да ви е трудно да разработите нещо за Bitrix в бъдеще. Ако нямате избор, тогава изучавайте Bitrix, но в свободното си време е по-добре да опитате да се потопите в света на рамките, за да поставите мозъка си на място.

Ако сте разработчик с опит в Bitrix, но без опит в други рамки, тогава не забравяйте да се потопите в друг свят; ще откриете много нови и полезни знания, които ще ви помогнат да напишете много по-добри решения за 1C-Bitrix. Опитайте се да използвате решения от други рамки във вашите проекти, за щастие това не е трудно да се направи благодарение на компонентния подход на последния и композитора.

Ако сте клиент, тогава не се доверявайте на търговците на Bitrix. Нищо няма да бъде толкова лесно, колкото казват в презентациите на Bitrix. И не обвинявайте разработчиците си за това, те нямат нищо общо с това. Ако искате да създадете голям и сложен онлайн магазин на ниво Eldorado/Mvideo/Sportmaster, тогава Bitrix може да не е най-добрият избор.

UPD.Ясно е, че статията е прочетена от служители на Bitrix. В раздела за маркетинга написах, че в раздела Архитектура на курса за разработчици на Bitrix се пишат маркетингови призиви. Сега ги няма. Даже са го запечатали, явно са бързали.

Благодаря за наблюдението и зоркото око :)

Тагове:

1s-битрикс
cms
уеб разработка
дървена стая
hatebitrix
паплачи на главината
Стегни се

Добави тагове