Nümunə bölmə php. Bitrix nifrətçisinin etirafı

). Hər bir etiket (bölmə) bir cüt olmalıdır (/bölmə). Tələb olunan parametrlərdir ad Və döngə. Dövrün (bölmənin) adı hərflərdən, rəqəmlərdən və alt xəttdən ibarət hər hansı bir şey ola bilər. Velosipedlər (bölmə) iç-içə ola bilər və yuvalanmış bölmələrin adları bir-birinə unikal olmalıdır. Dəyişən döngə(adətən dəyərlər massivi) döngənin iterasiyalarının sayını müəyyən edir. Bölmə daxilində dəyişənləri çap edərkən, bölmə adı kvadrat mötərizə içərisində dəyişən adının yanında qeyd edilməlidir. (başqa bölmə) parametr olduqda icra edilir döngə dəyərləri ehtiva etmir.

Atribut adı	Növ	Tələb olunur	Defolt	Təsvir
ad	simli	Bəli	yox	Bölmə adı
döngə	qarışıq	Bəli	yox	Döngənin təkrarlarının sayını təyin edən dəyər.
başlamaq	tam	Yox	0	Döngənin başlayacağı mövqenin indeksi. Dəyər mənfi olarsa, başlanğıc mövqeyi serialın sonundan hesablanır. Məsələn, döngə dəyişəninin 7 elementi varsa və başlanğıc atributunun dəyəri -2-dirsə, başlanğıc indeksi 5 olacaq. Etibarsız dəyərlər (massivdən kənarda olan dəyərlər) avtomatik olaraq ən yaxın etibarlı dəyərə kəsilir.
addım	tam	Yox	1	Massivdən keçmək üçün istifadə olunan addım dəyəri. Məsələn, addım=2 massivin 0,2,4 elementləri ilə keçidini göstərir... Əgər addım mənfi olarsa, o zaman massiv əks istiqamətdə keçiləcək.
maks	tam	Yox	1	Döngə təkrarlamalarının maksimum sayı.
göstərmək	boolean	Yox	doğru	Bu bölmənin göstərilib-göstərilmədiyini göstərir

Qeyd

Smarty 1.5.0 versiyasından etibarən, sessiya xassəsinin dəyişən sintaksisi (%sectionname.varname%)-dan ($smarty.section.sectionname.varname) kimi dəyişdirilib. Köhnə sintaksis hələ də dəstəklənir, lakin siz yalnız yeni sintaksis nümunələrini görəcəksiniz.

index, sıfırdan başlayaraq (yaxud biri göstərilibsə başlanğıc atributundan) başlayaraq və bir artırılaraq (və ya müəyyən edilibsə, addım atributunun dəyəri) massivin cari indeksini göstərmək üçün istifadə olunur.

Texniki Qeyd

Əgər addım və başlanğıc atributları göstərilməyibsə, indeks 1 deyil, 0-dan başlaması istisna olmaqla, iterasiya bölməsi atributu ilə eynidir.

iterasiya dövrənin cari iterasiya nömrəsini göstərmək üçün istifadə olunur.

Qeyd

Bu dəyər indeks xassəsindən fərqli olaraq başlanğıc, addım və maksimum xassələrdən müstəqildir. Həmçinin, iterasiyalar sıfır kimi indekslərdən deyil, birdən başlayır. rownum iterasiya xassəsinin sinonimidir, onlar eyni işləyir.

Misal 7.38. xassə (bölmə) təkrarlanması

təyin ("custid",$id); ?> (bölmə adı=cu loop=$custid start=5 addım=2) iterasiya=($smarty.section.cu.iteration) index=($smarty.section.cu.index) id=($custid)
(/bölmə)

Bu nümunəni işlətməyin nəticəsi:

İterasiya=1 indeks=5 id=3005
iterasiya = 2 indeks = 7 id = 3007
iterasiya=3 indeks=9 id=3009
iterasiya=4 indeks=11 id=3011
iterasiya=5 indeks=13 id=3013
iterasiya=6 indeks=15 id=3015

Bu nümunə cədvəl başlığını hər beş sətirdən bir çap etmək üçün iterasiya xüsusiyyətindən istifadə edir (mod operatoru ilə (əgər) istifadə edir - bölmənin qalan hissəsi).

(bölmə adı=co loop=$kontaktlar) (əgər $smarty.section.co.iteration % 5 == 1) (/əgər) (/bölmə)

	Adı>	Ev	Hüceyrə	E-poçt
görünüşü	($contacts.name)	($contacts.home)	($contacts.cell)	($contacts.email)

Bölmə kateqoriyasından bölmə HTML elementini araşdıran məqalə.

Bölmə elementinin məqsədi

Bölmə elementi sənəddə bəzi aktual məzmunu birləşdirən bölmə yaratmaq üçün istifadə olunur. Sənəddə hər bir bölmə üçün onun adı (mövzusu) göstərilməlidir. Bu, adətən başlıqlardan (h1 - h6 elementləri) istifadə edilir.

Bölmə başlığı

Bölmə məzmunu...

Bölmə elementləri adətən aşağıdakı hallarda istifadə olunur:

bölmə daxilində bölmələri qeyd etmək. Məsələn, məqalədəki fəsilləri, dialoq qutusundakı nişanları, dissertasiyadakı bölmələri və s.
bir neçə bölməni bir tematik qrupda qruplaşdırmaq. Məsələn, saytdakı ən son xəbərləri qruplaşdırmaq, məqaləyə şərhlər və s.

Beləliklə, bölmə elementi yalnız başlığı varsa və başqa bir şeyin bir hissəsidirsə, bəzi məzmun üçün istifadə edilməlidir.

Bölmə elementindən istifadə

Məsələn, şərhləri olan məqalədən ibarət səhifə kodu fraqmentini nəzərdən keçirək. İstifadəçinin səhifədə qoyduğu şərhlərin hər biri tam məzmuna malikdir və buna görə də məqalə elementi sayıla bilər. Lakin, eyni zamanda, bütün şərhlər müəyyən bir tematik qrupu təmsil edir və buna görə də onlar bölmə elementinə yerləşdirilə bilər, yəni. bu element səhifədəki bütün bu şərhləri bir yerdə qruplaşdıracaq.

Məqalənin başlığı

Şərhlər

Şərh başlığı

Şərh mətni...

Şərh başlığı

Şərh mətni...

Məqalə başlığı Şərhlər Şərh başlığı Şərh başlığı

Məsələn, məqalə elementində bölmələr yaratmaq üçün bölmə elementlərindən istifadə etməyi düşünün:

Kitabın adı

Birinci fəsil

İkinci fəsil

Üçüncü Fəsil

Əlavə A

Əlavə B

Yuxarıdakı nümunədə aşağıdakı kontur olacaq:

Kitabın adı Birinci Fəsil İkinci Fəsil Üçüncü Fəsil Əlavə A Əlavəsi B

Bölmə elementindən istifadə zamanı məhdudiyyətlər

HTML 5-də bölmə elementi məzmunu qruplaşdırmaq üçün universal element deyil, yəni. bəyəndiyiniz hər hansı məzmunu bağlamaq üçün istifadə edilməməlidir. Onun əsas məqsədi sənədə semantika əlavə etmək və onun strukturunu (konturunu) yaratmaqdır.

Müəllif məzmunu sadəcə üslub etmək və ya JavaScript-də manipulyasiya etmək üçün qruplaşdırmalı olduqda, div elementi onların ən yaxşı bahisidir. Div elementi bölmə elementindən fərqli olaraq sənədə semantika əlavə etmir və onun strukturunun (konturunun) yaradılmasında iştirak etmir.

Bölmə və məqalə elementləri arasındakı fərq

Bölmə və məqalə elementləri ilk baxışda çox oxşar görünsələr də, fərqli semantik məna daşıyırlar. Məqalə elementi tam, müstəqil və səhifə məzmununun qalan hissəsindən ayrıca baxıla bilən məzmunu qruplaşdırmaq üçün nəzərdə tutulub. Bölmə elementi başqa bir şeyin bir hissəsi olan məzmunu qruplaşdırmaq üçün nəzərdə tutulmuşdur.

Bəs müəllif səhifədəki bəzi məzmunun nə olduğunu necə bilir? Bir məqalə fraqmentindən nümunə götürərək buna baxaq. Fraqment məqalənin bir hissəsidir və ona görə də onun məzmununu qruplaşdırmaq üçün bölmə elementi tələb olunur. Amma artıq şərh kimi buraxılmış həmin fraqment bütöv, tam bir şeyi təmsil edəcək. Buna görə də, bu kontekstdə onu qruplaşdırmaq üçün məqalə elementindən istifadə edə bilərsiniz. Amma təbii ki, başqa cür mübahisə etmək olar. Buna görə də, məzmunu qruplaşdırmaq üçün hansı elementdən istifadə etmək əksər hallarda müəllif kimi subyektiv fikrinizdən asılıdır. Ancaq bu yanaşmada ən vacib şey seçilmiş mövqeyi saxlamaqdır. Odur ki, müəllif struktur yaratmaqda nə qədər ardıcıl olarsa, ona bir o qədər çox məna verə bilər.

Bitrix-də şablonları bir neçə növə bölmək olar:

Adi və Kompleks 2.0 Komponent Şablonları
Veb sayt şablonları
Digər qurumlar üçün şablonlar (poçt göndərişləri, bülletenlər, veb formalar, ixrac generatorları və daha çox)

Komponent şablonları hətta şablon mühərriklərindən istifadə etmək imkanına malikdir. Prinsipcə, hər hansı bir şablon mühərriki birləşdirə bilərsiniz, lakin qutudan heç bir köməkçi alət yoxdur. Kimə lazımdırsa, məndə işləyən və istehsalda kifayət qədər istifadə olunan budaq və bıçaq üçün uzantılara bir neçə keçidim var. Ancaq hətta burada Bitrixoidlər azğınlaşdılar. Şablon mühərriki yalnız komponentlərlə istifadə edilə bilər. Şablon mühərrikini vebsayt şablonunun və ya digər obyektlərin rendererinə qoşmaq mümkün olmayacaq, çünki orada render yoxdur.

Komponent şablonları ilə bağlı başqa bir zəhlətökən şey onların yerləşdirilməsidir. Komponent sadə dizayndan istifadə edərək bağlanır
$APPLICATION->IncludeComponent("bitrix:kataloq.bölmə", "şablon_adı", );
İkinci parametr komponent şablonunun adıdır. Beləliklə, müxtəlif şərtlərdən asılı olaraq, bu şablonun yeri ən gözlənilməz yerlərdə ola bilər:

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

Mən hələ bütün variantları sadalamamışam...

Sayt şablonu fayllar toplusu kimi qəbul edilə bilər: header.php, footer.php (bəli, saytda bunlar olmalıdır), description.php (sayt şablonunun sistem təsviri), template_styles.css (sayt şablon üslubları), komponent şablonları və daha az əhəmiyyətli faylların başqa bir qrupu olan qovluq. Hamısı budur. Və heç bir şəkildə ona təsir edə bilməzsiniz, bu barədə heç nə edə bilməzsiniz. Şablon mühərrikini götürmək mümkün deyil.

Digər şablonlar haqqında deyiləcək bir şey yoxdur. Onlar ya sadəcə olaraq verilənlər bazasında bəzi “dəyişən” verilənlərin daxil olduğu layout şəklində saxlanılır, ya da verilənlər bazasından parametrlərin götürülməsindən tutmuş məlumatın nümayişinə qədər bütün işləri görən axmaq bir PHP faylıdır. Məsələn, bazar üçün YML fayl generatoruna baxa bilərsiniz. Sadəcə, kifayət qədər böyük, təxminən 2 min sətir olduğu üçün onu burada yerləşdirməyin mənası yoxdur. Ehtiyacı olan hər kəs google-da axtara bilər, /bitrix/modules/catalog/load/yandex_run.php-də var

Fayl təbiəti

Yuxarıda aydın olduğu kimi, Bitrix-də arxitektura çox yaxşı deyil. Lakin Bitrix-in arxitekturasının başqa bir vacib cəhəti də var.
Bitrix yarım fayllı CMS-dir. Bəzi fayllardan istifadə etməklə çox şey idarə olunur:

Səhifə lazımdır - fayl yaradın
Sizə bir sıra səhifələr lazımdır - bir fayl yaradın və orada infobloklarla işləyən komponenti birləşdirin
Səhifə üçün başlıq təyin etməlisiniz - faylı redaktə edin
Bölmənin bütün səhifələri üçün başlıq təyin etməlisiniz - bu bölmənin kökündə xüsusi file.section.php yaradın.
Hüquqları redaktə etməlisiniz - .access.php faylını redaktə edin
Sistemin işə salınmasından əvvəl parametrlər - dbconn.php, .settings.php və .settings_extra.php faylında
result_modifier.php, component_epilog.php, init.php, .parameters.php, .description.php ....

Bitrix-ə səpələnmiş çox sayda belə xüsusi fayl var. Bu, bir tərəfdən sistemlə işləyərkən müəyyən rahatlıq verir. Digər tərəfdən, bu həm tərtibatçı, həm də sayt meneceri üçün əzaba çevrilə bilər. Səhifə faylları bəzən PHP kodu, tərtibat və plug-in komponentlərinin qarışıqlığına çevrilir. Nəticədə, vizual redaktor bu faylı səhv təhlil edə bilər və onu redaktə edərkən bəzi yerlərdə PHP teqlərindən asanlıqla qaça bilər ki, bu da səhifənin işləməməsinə səbəb olacaq. Deyirsiniz - belə fayllara PHP kodu yazmağa ehtiyac yoxdur? Bəli bilirəm. Ancaq Bitrix çox tez-tez və heç bir alternativ olmadan sizi bunu etməyə məcbur edir.
Və onların hansı növ fayllar olduğu və hansı məlumatları ehtiva edə biləcəyi barədə daima başınızda məlumat saxlamalısınız. Fərqli fayllar müxtəlif strukturlara malik fərqli məlumatları ehtiva etməlidir və hər seçim üçün onları yadda saxlamalısınız. Bunu hər dəfə sənədlərdə axtarmaq çətin işdir.

Yuxarıda göstərilənlərə əlavə olaraq

Bitrix-də hər şeyin necə pis işlədiyindən sonsuz şikayət edə bilərsiniz. Fikrimcə, bütün bu şikayətləri bir ifadə ilə xarakterizə etmək olar - “nə qədər də tam deyil”. Və həqiqətən də, əgər Bitrixoidlər birdən-birə hansısa xüsusiyyəti elan edərlərsə, o zaman birtəhər onu tamamilə buraxmırlar, bitirmirlər, ağlına gətirmirlər. Çoxlu nümunələr var:

həyata keçirilmiş ORM - hələ tamamlanmayıb, tam istifadə edilə bilməz
Avtomatik yükləyici hazırladıq, o, standartlara uyğun deyil, yalnız modullarda işləyir
şablon mühərriki birləşdirməyə imkan verdi, ancaq hər yerdə istifadə edə bilməzsiniz və tamamilə deyil
və s. və s.

Bir sözlə, hər gün qarşılaşmalı olduğum qalan problemləri xarakterizə etməyə çalışacağam.

Admin

Əgər kimsə admin paneli ilə işləmişsə, öz səhifələrini inzibati hissədə Bitrix-in təklif etdiyi kimi yaratmışsa, məni başa düşəcəklər. Bu sadəcə cəhənnəmdir. Bilməyənlər üçün Bitrix hər səhifə üçün əriştə faylından istifadə etməyi təklif edir. Məsələn, Bitrix tərtibatçıları tərəfindən hazırlanmış idarəetmə panelindəki sifarişin ətraflı görünüşü üçün səhifə 4k sətirdən çox çəkir. Bu faylın məzmununa baxarkən IDE-im yavaşlamağa başlayır. Orada php, js və html var. SQL-dən qurtulmaları yaxşıdır, baxmayaraq ki, bunun digər inzibati səhifələrdə olduğuna əminəm.
Eyni komponentlərdən istifadə edərək inzibati səhifələrin işləməsinə nə mane olduğu aydın deyil. Əksər inzibati səhifələri fərdiləşdirmək üçün sadəcə bir yol yoxdur. Komponentlərə gəldikdə, bu, qısa müddətdə edilə bilər.
Yeri gəlmişkən, yaxşı insanlar sizə inzibati səhifələr yaratmağa kömək edəcək bir modul hazırlayıblar

js çərçivəsi

Bitrix bir növ müştəri çərçivəsi kimi çıxış edən bir js komponentinə malikdir. Tərtibatçıların heç biri bunu bir neçə səbəbə görə bəyənmir:

demək olar ki, sənədləşdirilməyib
o dəhşətlidir
o, çoxlarına tanış olan jQuery-ni böyük ölçüdə təkrarlayır

Bitrix çox vaxt onu öz komponentlərində istifadə edir və bununla da tərtibatçılar arasında daha da qəzəb doğurur. Kiçikləşdirilmiş formada bu kitabxananın nüvəsi 85kb-dir, bu da kiçik deyil. Bitrix-in bütün imkanlarından (kompozit, aktivlərin idarə edilməsi) istifadə etmək istəyirsinizsə, onu qoşmaqdan qaça bilməzsiniz.

Kopyala-yapışdır ruhu

Son vaxtlar, getdikcə daha az, lakin yenə də tez-tez Bitrix sizi nəyisə kopyalayıb yapışdırmağa məcbur edir. Komponentin işini dəyişdirmək istəyirsinizsə, onu kopyalayın və yapışdırın. Öz yükləmə şablonunuzu yaratmaq istəyirsinizsə, sistemi kopyalayıb yapışdırıb bitirin. Demək olar ki, sizdə olan eyni şablonu etmək istəyirsinizsə, onu kopyalayıb yapışdırın və bir az dəyişdirin. Və hətta yeni başlayanlar üçün kurslarda bu barədə danışırlar. sözüm yoxdur.

Aktivlərin idarə edilməsi və CDN

Bitrix-in resursları idarə etmə tərzini çox bəyənirəm. Prinsipcə, konkret “kitabxanalar” dəstini qeydiyyatdan keçirmək mümkündür. Hər bir kitabxana bəzi digər kitabxanalardan asılı ola bilən css/js faylları toplusudur. Kitabxananı səhifəyə qoşarsanız, onu bağlamazdan əvvəl bütün asılılıqlar həll olunacaq və bütün asılı kitabxanalar səhifəyə daxil ediləcək. Hər şey qaydasındadır, yalnız hər bir resurs skript və ya keçid etiketinə ayrıca fayl kimi daxil ediləcək. Və bunun sayəsində 30-50 skripti birləşdirən və eyni sayda stil faylı olan saytlar var.
Bitrix-də dedilər ki, bu axmaq bir sualdır və bütün bu faylları bir yerə birləşdirən sehrli işarə qoydular. 50 skriptin əvəzinə hər biri 300-500 kb olan 2 skriptin olduğu saytlar meydana çıxdı. Bir müddət əvvəl bu birləşmə xətalarla işlədi və eyni resursları bir neçə dəfə birləşdirdi, amma indi deyəsən düzəldilib.
Və sonra Bitrixoids yoldan çıxdı - onlar bütün resursları CDN serverinə yükləmək imkanı əlavə etdilər. Hansı ki, həmişə yıxılır...
Sonra bütün resursları səhifənin altına köçürməyi tövsiyə edən Google Pagespeed Insights peyda oldu. Və Bitrix-də onlar xüsusi bir atributla qeyd edilmədikdə, bədəndəki bütün resursları axmaqcasına buraxan sehrli bir onay qutusu yaratdılar.
Onlar həmçinin idarə panelində başqa sehrli onay qutusundan istifadə etdiyiniz zaman qoşulan qutu ilə birlikdə öz skriptlərinin kiçildilmiş versiyalarını paylayırlar.
Ümumiyyətlə, sizin üçün scss yoxdur, TypeScript yoxdur. Resursları bacarıqla idarə etmək istəyirsinizsə, quraşdırılmış Bitrix sistemindən istifadə etməyin, Bitrix ilə asanlıqla qoşalana bilən veb paketindən istifadə edin.

Çoxsaylı/çoxdilli

Bu, yəqin ki, məhsulun başlanğıcından bəri davam edən bir inkişaf etdirici üçün ən pis baş ağrısıdır. Siz sadəcə irəli gedib çoxdilli veb sayt yarada bilməzsiniz. Fərqli qiymətlər və valyutalar olan çoxdilli kataloqa ehtiyacınız varsa, bu, una çevrilir, bunun üçün də səliqəli bir məbləğ ödəməli olacaqsınız (bu proqramın növbəti dil versiyası üçün əlavə lisenziya almaq üçün ayrılmalısınız. Sayt).
Əgər siz çoxdilli və çox valyutalı vebsayt yaradırsınızsa, o zaman Bitrix-in buna çox aqressiv müqavimət göstərəcəyinə hazır olun. Çoxsaylı parametrlər idarəetmə panelində mərkəzləşdirilməmişdir. İdarəetmə panelindəki hər bir obyektin saytın dil versiyasından öz asılılığı var. Bəzi qurumlar saytdan/dildən asılılıqları ümumiyyətlə dəstəkləməyə bilər, digərləri isə dillə yalnız birmənalı əlaqəyə malikdirlər, ona görə də bu qurum təkrarlanmalı və sonra dəstəklənməlidir.
Əsas versiyada məlumat blokunun bir neçə dildə işləməsi üçün bu məlumat blokunun dublikatını yaratmalı olacaqsınız. Amma praktikada heç kim bunu etmir və bir obyekti mərkəzləşdirilmiş şəkildə saxlamağın öz yollarını tapmağa çalışır, onun dildən asılı atributlarını digər saxlama obyektlərinə paylayır.
Lokallaşdırma zamanı standart dili təyin edə bilməzsiniz. Əgər rus dilində hansısa ifadəni təsvir edən dil dəyişəniniz varsa və bu dil dəyişəni ingilis dilində deyilsə, ingilis saytında boş sətir görünəcək və buna heç bir şəkildə təsir edə bilməzsiniz (bir çox hallarda siz rusca ifadəni buraxın ki, boşluq olmasın).

Hüquqların İdarə Edilməsi Mexanizmi

Onlar bu alt sistemlə çox ağıllı idilər. Bəzi qurumlara niyə baxış hüquqlarını verdiyinizi anlamaq çox vaxt çətindir, lakin istifadəçi onlardan istifadə edə bilmir. Məsələn, məlumat blokunu redaktə etmək hüququnu vermək üçün /bitrix/admin kataloquna giriş, konkret məlumat bloku üçün hüquqlar vermək və əsas modulda hüquqlar vermək lazımdır. Bir qurum üçün hüquqların verilməsi üçün çoxlu əməliyyatlar edilməlidir. Kifayət qədər hüquqlar yoxdursa, mənbə koduna baxmadan bunun səbəbini başa düşməyin bir yolu yoxdur.

Konfiqurasiya

Bitrix-də sistem parametrlərini idarə etməyə imkan verən mərkəzləşdirilmiş mərkəz yoxdur. Parametrlər yenidən sistemdə mərkəzləşdirilməmişdir. Seçimlər modul parametrlərində, komponent parametrlərində, COption-da mövcuddur (idarə panelində yerləşdirilmir). İdarəetmə panelində bir modul üçün seçimlər tamamilə fərqli yerlərdə yerləşən 3-4 müxtəlif səhifəyə paylana bilər. urlrewrite admin panel vasitəsilə redaktə edilə bilər! İndi də .settings və .settings_extra. Bəzən onlardan hansının daha yüksək prioritet olduğu heç də aydın deyil, çox vaxt variantlar üçün kifayət qədər izahatlar yoxdur və münasibətlər aydın deyil. Tərtibatçılar arasında konfiqurasiyanı paylaşmağın yerli yolu yoxdur.
Parametrlər çox məntiqsiz ola bilər. Bəzən absurdluq həddinə çatır... bigdata komponentinə baxın - təlim keçməmiş şəxs bunu qura bilərmi?

1C ilə inteqrasiya

Bu, kifayət qədər çox sayda müştərinin düşdüyü Bitrix xüsusiyyətləri siyahısındakı elementdir. Bitrix 2 kliklə saytın 1C ilə ikitərəfli inteqrasiyasını qurmağı vəd edir ki, bu da məzmunu və sənədləri bir sistemdən digərinə dərhal çatdıracaq.
Bəli, həqiqətən belədir, lakin bir neçə xəbərdarlıqla.
Birincisi, əlavə səy göstərmədən inteqrasiyanı "qutudan kənarda" etmək üçün hər şeyi Bitrix sənədlərində yazıldığı kimi etməlisiniz - Bitrix-in təklif etdiyi qaydalara uyğun olaraq saytda bir kataloq qurun və kataloqu 1C-də qurun. Bitrix tələb edir. İdeal olaraq, hər şeyi sıfırdan yaradın və sonra bəlkə hər şey qutudan kənarda sizin üçün işləyəcək.
İkincisi, Bitrix qutudan çıxan bütün 1C konfiqurasiyalarına uyğun gəlmir. Əvvəlcə yoxlamağa dəyər
Üçüncüsü, ideal dünya yoxdur. Tipik olaraq, veb saytı istəyən müştərinin artıq pərakəndə biznesi var, bu o deməkdir ki, onlarda artıq böyük zibillik olan 1C var. Və bu zibil sayta atılmalıdır. Saytın eyni zibil qutusuna çevrilməməsi üçün mübadilə mexanizmi əhəmiyyətli dərəcədə təkmilləşdirilməlidir.
Çox vaxt müştərinin tələbləri Bitrix komandasının yaratdığı məhsulun baxışından çox fərqlənir və sonra mübadilə mexanizmini təkmilləşdirmək kifayət qədər bahalı ola bilər, əmək intensivliyi ilə müəyyən bir iş üçün unikal mübadilə modulunun hazırlanması ilə müqayisə oluna bilər.
Buna görə də, saytınızı 1C ilə asanlıqla inteqrasiya edə biləcəyiniz barədə heç bir illüziyaya qapılmağa ehtiyac yoxdur. Bütün bunlar marketoloqların hiylələridir.

1C ilə mübadilənin təkmilləşdirilməsi də ayrı bir mövzudur. \CIBlockCMLImport sinfi kataloq mübadiləsinin təşkilinə cavabdehdir - 5.7k. Ən çox uzadılması tələb olunan əsas üsullardan biri 1k-dan çox sətirdən ibarət \CIBlockCMLImport::ImportElement-dir. Bir dəfə miras almaq, məhsulu uzun müddət ərzində bir neçə dəfə yeniləmək kifayətdir və 1C ilə işləməyən mübadilə əldə edə bilərsiniz. Buna görə də, tərtibatçılar tez-tez bu siniflə narahat olmurlar və hadisə işləyicilərindən istifadə edərək bir şəkildə idxal prosesinə daxil olmağa çalışırlar. Bitrix-də, xüsusən də infobloklar modulunda hadisələrin işləyiciləri ilə işləmək, eyni tipli hadisələrin vahid şəkildə təşkil edilməməsi və bəzi hadisələrin sadəcə kifayət etməməsi səbəbindən çox xoş təcrübə deyil.
Ümumiyyətlə, işlər əvvəlki kimi kədərlidir.

Uyğunsuzluq

Bəzən mənə elə gəlir ki, müxtəlif modulların tərtibatçıları həqiqətən bir-biri ilə əlaqə saxlamırlar. Nüvə mənbələrini öyrənərkən bir mühərrikdə həyata keçirilə bilən çox heterojen həllərlə qarşılaşırsınız, lakin nədənsə onlar fərqli şəkildə həyata keçirilir.
Məsələn, məlumat blokunun elementlərinin və UserFields xüsusiyyətlərini götürə bilərsiniz. Hər iki qurum əslində başqa bir qurum üçün əlavə sahədir. Onun bir növü, mənası və təsviri var. Dəyər verilənlər bazasının ayrı cədvəlində (cədvəllərində) saxlanılır, onlar təxminən oxşar məlumat əldə etmək interfeysinə malikdirlər; Bəs niyə onlar üçün eyni interfeys yaratmayaq?
Martın sonunda satış modulu ən son versiyaya yeniləndi və onlar da sifarişlər üçün özbaşına xassələr vəd etdilər. Genişlənmiş obyekt xüsusiyyətləri ilə işləmək üçün həqiqətən yeni, üçüncü interfeys varmı?

Bitrix24

Bu, ümumiyyətlə, ayrı bir müzakirə mövzusudur. Bu sistemə görə tez-tez qarışıqlıq yaranır. B24 üçün 2 seçim var - SaaS və Standlone. B24 üçün bazar var, lakin o, yalnız SaaS versiyası üçün proqramları ehtiva edir! Əgər 200 qr-a alınmış qutulu versiyanız varsa, siz sənəd dizayneri kimi məşhur proqramları quraşdıra bilməyəcəksiniz və ümumiyyətlə Bitrix24-də Bitrix24 bazarından heç bir proqram quraşdıra bilməyəcəksiniz. Bu belə bir paradoksdur.
Bunun əvəzinə adi versiyadan olan bazar Bitrix24-də mövcud olacaq. Orada daha çox həll variantları var, lakin onlar B24 deyil, əsasən Saytın İdarə edilməsi ətrafında cəmləşib.

Bitrix24, texniki dəstək şöbəsində mənə deyildiyi kimi, vahid bir sistemdir. Standart sistem komponentlərinin işinə müdaxilə etsəniz, bu funksionallığın sonrakı yeniləmələrlə pozulacağına hazır olun. Bitrix portal komponentlərini yekunlaşdırmaq üçün sizə etibar etməyəcək və bu, müştərilərini rəsmi olaraq tərəfdaşlara yönləndirmələrinə baxmayaraq

Yeri gəlmişkən, B24-ün qutulu versiyasında komponentləri dəyişdirmək olduqca çətin bir işdir. ajax istifadə edərək, cavab olaraq html+js yaradan php koduna daxil olan js kodunu yaradan komponentlər. Bu, həqiqətən dalmaq istəmədiyiniz cəhənnəm qarışığıdır.

Sənədlər

Bitrix sənədləri məhsulun hazırlanmasından 1-1,5 il geri qalır. Kod phpDocs tərəfindən çox zəif əhatə olunub və tez-tez sinifdən əvvəl şərh IDE-də avtomatik olaraq yaradılan yalnız nümayiş üçündür.
Rəsmi mənbələrdə sənədlərin təqdimat tərzi çox vaxt çox “pulsuz” olur və sənədlərdəki bəzi məqalələrin məzmununun Bitrix-in özü ilə heç bir əlaqəsi olmaya bilər.
Tərtibatçı kursu çoxlu məlumatlara malikdir, lakin tərtibatçının sistemin imkanları ilə tanış olduğu format tələb olunan qavrayış səviyyəsini təmin etmir. Symfony Cookbook-a daxil olsanız, hər şey orada yerləşdirilir, versiyadan asılı olaraq bütün lazımi aspektlər təsvir olunur. Halbuki Bitrix-də tərtibatçı təlim kursu aydın olmayan şəkildə köhnə və yeni nüvələr haqqında strukturlaşdırılmış məlumatları ehtiva edir ki, bu da əvvəlcə ayrı-ayrılıqda təqdim olunur, sonra qarışıqdır və bu, yeni başlayanlara baş ağrısı verir.

İnkişaf prosesinin təşkili

Sistemin spesifikliyinə görə rahat inkişaf prosesini təşkil etmək o qədər də asan deyil. Quraşdırıldıqdan sonra Business nəşrinin ən son versiyası (əldə olan) deyil, düşünün, demək olar ki, 530 meqabayt
$ du -s *|sort -nr|cut -f 2-|oxuyarkən a;do du -hs $a;done 523M bitrix 204K yükləmə 64K bitrixsetup.php 56K desktop_app 20K readme.html 20K lisenziya.html 4.0K veb . konfiqurasiya 4.0K urlrewrite.php 4.0K readme.php 4.0K lisenziya.php 4.0K install.config 4.0K index.php
Bu həcmin yaxşı yarısı ümumiyyətlə versiyaya nəzarət üçün lazım olmayan binar və quraşdırıcılardır. Ümumiyyətlə, Bitrix nüvəsini versiyaya salmamaq adətdir. Bitrix tərtibatçıları özləri nüvənin bütövlüyünə zəmanət verir və yeniləmələr zamanı müxtəlif modulların versiyalarının asılılıqlarını idarə edirlər. Ancaq bu dərhal ən azı bir böyük çatışmazlıq daşıyır - versiya nəzarətindən bir komanda ilə tam işləyən layihəni yerləşdirmək mümkün deyil, onu hissələrə bölmək lazımdır: kernel mənbələrini Bitrix ehtiyat nüsxəsindən və tərtibatçıların mənbələrini git-dən əldə edin; .
Baza ilə də işlər yaxşı getmir. Əgər siz özünüz inkişaf zamanı miqrasiyadan istifadə edə bilirsinizsə, onda Bitrix nəzarət edə bilməyəcəyiniz adi skriptlərdən istifadə edərək yeniləmələri verilənlər bazasına yerləşdirir. Buna görə də, yeniləyərkən hələ də verilənlər bazası ehtiyat nüsxələrini mərkəzi inkişaf hostundan digər tərtibatçılara ötürməli olacaqsınız.
Yaxşı insanlar, yenə də bütün bunları təşkil etməyə kömək edən alətləri kəsirlər, lakin təəssüf ki, Bitrix-i bu qaydalara əməl etməyə məcbur etmək hələ də mümkün deyil.
Rəsmi olaraq Bitrix sizə bir paylamanın 2 nüsxəsinə sahib olmağa imkan verir. Biri istehsal üçün, ikincisi inkişaf üçündür. Bir layihədə bir neçə tərtibatçınız varsa, deməli, siz, sanki, qanundan kənarsınız) Əslində, Bitrix ilə maşının www.bitrixsoft.com-a daxil olan və gedən bağlantılarını kəsmək kifayətdir, sonra isə siz İstədiyiniz qədər inkişafın çox nüsxəsini pərçim edə bilər, Onlar sadəcə özlərini yeniləyə bilməyəcəklər.

Həmkarlar

Və toxunmaq istədiyim sonuncu sual.
Bitrix-in giriş maneəsi aşağı olduğu üçün bu bazarda xidmət göstərən şirkətlər arasında kifayət qədər ixtisaslı kadrlar var. Mən karyeram ərzində 1C-Bitrix-də tamamlanmış bir çox müxtəlif layihələr görmüşəm (cəmi yüzdən çox). Əminliklə deyə bilərəm ki, onların 95%-i “bugger” üsulu ilə həyata keçirilib. Çox nadir hallarda inkişafa məqsədyönlü şəkildə yanaşan layihələrə rast gəlirdik, lakin bunlar yalnız bir neçəsi idi. Bütün bunlar çox kədərlidir.

nəticələr

Əlbəttə ki, bütün çatışmazlıqlar bir məqalədə nəzərdən keçirilə bilməz. Hər gün işinizə mane olan bəzi kiçik şeylərlə qarşılaşırsınız. Ancaq bütün belə xırda şeyləri nəzərdən keçirmək sadəcə mümkün deyil və yəqin ki, ehtiyac yoxdur.

Buradan hansı nəticələr çıxarmaq olar? Bitrix, səhv düşünülmüş bir arxitekturaya və məhsulda uzun müddət yaşamağa davam edən bir çox qüsura sahib olduğu üçün son dərəcə mürəkkəb bir sistemdir. Digər tərəfdən, Bitrix, çərçivələrdən fərqli olaraq, işə başlamaq üçün daha aşağı səviyyəli ixtisas tələb edən kifayət qədər sadə bir sistemdir.
Bu məhsulu dəstəkləmək Symfony, Laravel, Yii kimi məhsullarla müqayisədə çox nankor bir işdir. Məhsul, həqiqətən, həm təcrübəsiz, həm də təcrübəli tərtibatçıların təkərlərinə nitq qoymağı xoşlayır ki, bu da öz növbəsində təcrübəli Bitrix tərtibatçılarının xidmətlərinin qiymətində əks oluna bilər.

Bu sistemlə işləmək üçün bu qədər vaxt sərf etdiyim üçün peşmanam? Xeyrdən daha çox bəli. Bu vaxtı daha düzgün və daha məntiqli bir şey öyrənməyə sərf etmək daha müdrik olardı (mən bunu indi fəal şəkildə etməyə çalışıram). Ancaq elə oldu ki, səyahətimin əvvəlində məni düzgün istiqamətə yönəldən heç kim olmadı.

Əgər siz başlanğıc PHP tərtibatçısınızsa, o zaman Bitrix əvəzinə Symfony, Laravel, Yii, ZendFramework kimi çərçivələri öyrənməyə üstünlük verəcəksiniz. İnanın ki, bu, gələcəkdə öz bəhrəsini verəcək. Bu çərçivələrdən hər hansı birini mənimsədikdən sonra gələcəkdə Bitrix üçün nəsə hazırlamaq sizin üçün çətin olmayacaq. Seçiminiz yoxdursa, Bitrix-i öyrənin, amma boş vaxtlarınızda beyninizi yerinə yetirmək üçün hələ də çərçivələr dünyasına qərq olmağa çalışmaq daha yaxşıdır.

Bitrix-də təcrübəsi olan, lakin digər çərçivələrdə təcrübəsi olmayan bir tərtibatçısınızsa, başqa bir dünyaya qərq olduğunuzdan əmin olun, 1C-Bitrix üçün daha yaxşı həllər yazmağınıza kömək edəcək bir çox yeni və faydalı biliklər kəşf edəcəksiniz; Layihələrinizdə digər çərçivələrdən olan həllərdən istifadə etməyə çalışın, xoşbəxtlikdən sonuncunun və bəstəkarın komponent yanaşması sayəsində bunu etmək çətin deyil.

Əgər müştərisinizsə, Bitrix marketoloqlarına etibar etməyin. Heç bir şey Bitrix təqdimatlarında deyildiyi qədər asan olmayacaq. Bunun üçün tərtibatçılarınızı günahlandırmayın, onların bununla heç bir əlaqəsi yoxdur. Eldorado/Mvideo/Sportmaster səviyyəli böyük və mürəkkəb onlayn mağaza yaratmaq istəyirsinizsə, Bitrix ən yaxşı seçim olmaya bilər.

UPD. Məqalənin Bitrix əməkdaşları tərəfindən oxunduğu aydındır. Marketinq haqqında bölmədə Bitrix developer kursunun Architecture bölməsində marketinq müraciətlərinin yazıldığını yazmışdım. İndi onlar yoxdur. Hətta möhürlədilər, görünür, tələsirdilər.

Diqqətinizə və diqqətinizə görə təşəkkür edirəm :)

Teqlər:

1s-bitrix
sms
veb inkişafı
taxta otağı
hatebitrix
mərkəzdə sızıldayır
Özünüzü tutun

Teqlər əlavə edin