შეეხო სექცია php. ბიტრიქსის მოძულველის აღიარება

10.08.2022

სტატია, რომელიც იკვლევს სექციის HTML ელემენტს განყოფილების კატეგორიიდან.

განყოფილების ელემენტის დანიშნულება

სექციის ელემენტი გამოიყენება დოკუმენტში განყოფილების შესაქმნელად, რომელიც აერთიანებს ზოგიერთ აქტუალურ შინაარსს. დოკუმენტის თითოეული განყოფილებისთვის უნდა იყოს მითითებული მისი სახელი (თემა). ეს ჩვეულებრივ კეთდება სათაურების გამოყენებით (ელემენტები h1 - h6).

განყოფილების სათაური

განყოფილების შინაარსი...

განყოფილების ელემენტები ჩვეულებრივ გამოიყენება შემდეგ შემთხვევებში:

მონაკვეთების მონიშვნა განყოფილებაში. მაგალითად, სტატიაში თავების, დიალოგური ფანჯრის ჩანართების, დისერტაციის სექციების აღსანიშნავად და ა.შ.
რამდენიმე სექციის დაჯგუფება ერთ თემატურ ჯგუფად. მაგალითად, დაჯგუფებისთვის ახალი ამბებისაიტზე, კომენტარები სტატიაზე და ა.შ.

ამრიგად, სექციის ელემენტი უნდა იყოს გამოყენებული მხოლოდ გარკვეული შინაარსისთვის, თუ მას აქვს სათაური და არის რაღაცის ნაწილი.

განყოფილების ელემენტის გამოყენებით

მაგალითად, განიხილეთ გვერდის კოდის ფრაგმენტი, რომელიც შეიცავს სტატიას კომენტარებით. მომხმარებლის მიერ გვერდზე დატოვებული თითოეული კომენტარი შეიცავს გარკვეულ სრულ შინაარსს და, შესაბამისად, შეიძლება ჩაითვალოს სტატიის ელემენტად. მაგრამ, ამავდროულად, ყველა კომენტარი წარმოადგენს გარკვეულ თემატურ ჯგუფს და, შესაბამისად, ისინი შეიძლება განთავსდეს განყოფილების ელემენტში, ე.ი. ამ ელემენტსდააჯგუფებს ყველა ამ კომენტარს გვერდზე ერთად.

სტატიის სათაური

კომენტარები

კომენტარის სათაური

კომენტარის ტექსტი...

კომენტარის სათაური

კომენტარის ტექსტი...

სტატიის სათაური კომენტარები კომენტარის სათაური კომენტარის სათაური

მაგალითად, განიხილეთ სექციის ელემენტების გამოყენება სტატიის ელემენტში სექციების შესაქმნელად:

Წიგნის სათაური

პირველი თავი

თავი მეორე

თავი მესამე

დანართი A

დანართი B

ზემოთ მოყვანილ მაგალითს ექნება შემდეგი მონახაზი:

წიგნის სათაური პირველი თავი მეორე თავი მესამე თავი დანართი A დანართი B

შეზღუდვები სექციის ელემენტის გამოყენებისას

სექციის ელემენტი HTML 5-ში არ არის უნივერსალური ელემენტი შინაარსის დაჯგუფებისთვის, ე.ი. ის არ უნდა იქნას გამოყენებული თქვენთვის სასურველი შინაარსის შესაფუთად. მისი მთავარი მიზანია დოკუმენტში სემანტიკის დამატება და მისი სტრუქტურის (მოხაზულობის) შექმნა.

როდესაც ავტორს სჭირდება კონტენტის დაჯგუფება მხოლოდ მის სტილისთვის ან JavaScript-ში მანიპულირებისთვის, div ელემენტი არის მათი საუკეთესო ფსონი. div ელემენტი, სექციის ელემენტისგან განსხვავებით, არ ამატებს დოკუმენტს სემანტიკას და არ მონაწილეობს მისი სტრუქტურის (მოხაზულობის) შექმნაში.

განსხვავება განყოფილებასა და სტატიის ელემენტებს შორის

განყოფილებისა და სტატიის ელემენტებს, თუმცა ისინი ერთი შეხედვით ძალიან ჰგავს ერთმანეთს, განსხვავებული სემანტიკური მნიშვნელობა აქვთ. სტატიის ელემენტი მიზნად ისახავს დააჯგუფოს კონტენტი, რომელიც არის სრული, დამოუკიდებელი და მისი ნახვა შესაძლებელია გვერდის დანარჩენი შინაარსისგან განცალკევებით. განყოფილების ელემენტს განსხვავებული სემანტიკური მნიშვნელობა აქვს.

მაგრამ როგორ იცის ავტორმა, რა არის გარკვეული შინაარსი გვერდზე? მოდით შევხედოთ ამას სტატიის ფრაგმენტის მაგალითის გამოყენებით. ფრაგმენტი არის სტატიის ნაწილი და ამიტომ მოითხოვს განყოფილების ელემენტს მისი შინაარსის დასაჯგუფებლად. მაგრამ ეს იგივე ფრაგმენტი, რომელიც უკვე დატოვეს როგორც კომენტარი, წარმოადგენს რაღაც მთლიანს, სრულყოფილს. ამიტომ, ამ კონტექსტში, შეგიძლიათ გამოიყენოთ სტატიის ელემენტი მის დასაჯგუფებლად. მაგრამ, რა თქმა უნდა, შეიძლება საპირისპირო კამათი. ამიტომ, თუ რომელი ელემენტი გამოვიყენოთ შინაარსის დასაჯგუფებლად, უმეტეს შემთხვევაში დამოკიდებულია თქვენს, როგორც ავტორის, სუბიექტურ მოსაზრებაზე. მაგრამ ამ მიდგომაში ყველაზე მნიშვნელოვანი არჩეული პოზიციის შენარჩუნებაა. მაშასადამე, რაც უფრო თანმიმდევრულია ავტორი სტრუქტურის შექმნაში, მით მეტი მნიშვნელობის შეტანას შეძლებს მასში.

Bitrix-ის შაბლონები შეიძლება დაიყოს რამდენიმე ტიპად:

რეგულარული და რთული 2.0 კომპონენტის შაბლონები
ვებსაიტების შაბლონები
შაბლონები სხვა სუბიექტებისთვის (გზავნილები, საინფორმაციო ბიულეტენი, ვებ ფორმები, ექსპორტის გენერატორები და მრავალი სხვა)

კომპონენტთა შაბლონებს აქვთ შაბლონური ძრავების გამოყენების შესაძლებლობაც კი. პრინციპში, თქვენ შეგიძლიათ დააკავშიროთ ნებისმიერი შაბლონის ძრავა, მაგრამ არ არსებობს დამხმარე ხელსაწყოები ყუთში. თუ ვინმეს სჭირდება, მე მაქვს რამოდენიმე ბმული ტოტებისა და თხრილის გაფართოებებთან, რომლებიც მუშაობს და საკმაოდ გამოიყენება წარმოებაში. მაგრამ აქაც ბიტრიქსოიდები გახდნენ გარყვნილები. შაბლონის ძრავის გამოყენება შესაძლებელია მხოლოდ კომპონენტებთან ერთად. შეუძლებელი იქნება შაბლონის ძრავის დაკავშირება ვებსაიტის შაბლონის რენდერერთან ან სხვა ობიექტებთან, რადგან იქ რენდერი არ არის.

კომპონენტის შაბლონების კიდევ ერთი შემაშფოთებელი რამ არის მათი განთავსება. კომპონენტი დაკავშირებულია მარტივი დიზაინის გამოყენებით
$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-ში

ფაილის ბუნება

როგორც ზემოთ გაირკვა, Bitrix-ში არქიტექტურა არც თუ ისე კარგია. მაგრამ Bitrix-ს აქვს თავისი არქიტექტურის კიდევ ერთი მნიშვნელოვანი ასპექტი.
Bitrix არის ნახევარფაილი CMS. ბევრი რამ კონტროლდება ზოგიერთი ფაილის გამოყენებით:

გვჭირდება გვერდი - შექმენით ფაილი
თქვენ გჭირდებათ გვერდების ნაკრები - შექმენით ფაილი და დააკავშირეთ იქ კომპონენტი, რომელიც მუშაობს ინფობლოკებთან
თქვენ უნდა დააყენოთ გვერდის სათაური - შეცვალეთ ფაილი
თქვენ უნდა დააყენოთ სათაური განყოფილების ყველა გვერდისთვის - შექმენით სპეციალური file.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 ძალიან ხშირად და ალტერნატივის გარეშე გაიძულებს ამის გაკეთებას.
და თქვენ მუდმივად უნდა შეინახოთ ინფორმაცია თქვენს თავში იმის შესახებ, თუ რა სახის ფაილებია ისინი და რა მონაცემებს შეიძლება შეიცავდეს ისინი. IN სხვადასხვა ფაილიუნდა შეიცავდეს სხვადასხვა მონაცემებს სხვადასხვა სტრუქტურით და თქვენ უნდა გახსოვდეთ ეს თითოეული ვარიანტისთვის. ამის ძებნა დოკუმენტაციაში ყოველ ჯერზე რთული სამუშაოა.

გარდა ზემოაღნიშნულისა

შეგიძლიათ უსასრულოდ იჩივლოთ იმაზე, თუ რამდენად ცუდად მუშაობს ყველაფერი Bitrix-ში. ჩემი აზრით, ყველა ეს ჩივილი შეიძლება დახასიათდეს ერთი ფრაზით - "რაღაც არა მთლიანად". და მართლაც, თუ Bitrixoids მოულოდნელად გამოაცხადებენ რაიმე სახის ფუნქციას, მაშინ ისინი რატომღაც არ ათავისუფლებენ მას მთლიანად, არ ასრულებენ მას, არ ახსენებენ მას. უამრავი მაგალითია:

განხორციელებული ORM - ჯერ არ დასრულებულა, სრულად გამოყენება შეუძლებელია
ჩვენ გავაკეთეთ ავტოჩამტვირთავი, მუშაობს მხოლოდ მოდულებში და არა სტანდარტების მიხედვით
შესაძლებელი გახდა შაბლონის ძრავის დაკავშირება, მაგრამ თქვენ არ შეგიძლიათ გამოიყენოთ იგი ყველგან და არა მთლიანად
და ა.შ. და ასე შემდეგ.

მოკლედ, შევეცდები დავახასიათო დარჩენილი პრობლემები, რომელთა წინაშეც ყოველდღე მიწევს.

ადმინ

თუ ვინმემ იმუშავა ადმინისტრაციულ პანელთან, შექმნა თავისი გვერდები ადმინისტრაციულ ნაწილში ისე, როგორც ამას Bitrix გვთავაზობს, ის გამიგებს. უბრალოდ ჯოჯოხეთია. მათთვის, ვინც არ იცის, Bitrix გთავაზობთ noodle ფაილის გამოყენებას თითოეული გვერდისთვის. მაგალითად, Bitrix-ის დეველოპერების მიერ შედგენილი ადმინისტრაციულ პანელში შეკვეთის დეტალური ხედვის გვერდი იღებს 4k ხაზს. ჩემი IDE იწყებს შენელებას ამ ფაილის შინაარსის ნახვისას. აქ თქვენ გაქვთ php, js და html. კარგია, რომ მათ მოიშორეს SQL, თუმცა დარწმუნებული ვარ, რომ ეს სხვა ადმინისტრაციულ გვერდებზეა.
და რა უშლიდა ხელს ადმინისტრაციულ გვერდებს იგივე კომპონენტების გამოყენებით მუშაობას, გაუგებარია. უბრალოდ არ არსებობს გზა ადმინისტრაციული გვერდების უმეტესობის მორგებისთვის. კომპონენტების შემთხვევაში, ეს შეიძლება გაკეთდეს უმოკლეს დროში.
სხვათა შორის, კარგმა ადამიანებმა შექმნეს მოდული, რომელიც დაგეხმარებათ ადმინისტრაციული გვერდების აშენებაში

js ჩარჩო

Bitrix-ს აქვს js კომპონენტი, რომელიც მოქმედებს როგორც ერთგვარი კლიენტის ჩარჩო. არცერთ დეველოპერს არ მოსწონს ეს რამდენიმე მიზეზის გამო:

თითქმის არ არის დოკუმენტირებული
ის არის ამაზრზენი
ის დიდწილად იმეორებს ბევრისთვის ნაცნობ jquery-ს

Bitrix ძალიან ხშირად იყენებს მას თავის კომპონენტებში, რითაც იწვევს კიდევ უფრო მეტ აღშფოთებას დეველოპერებში. ამ ბიბლიოთეკის ბირთვი მინიფიცირებული ფორმით არის 85 კბ, რაც არ არის პატარა. თქვენ ვერ მოერიდებით მის დაკავშირებას, თუ გსურთ გამოიყენოთ Bitrix-ის ყველა შესაძლებლობა (კომპოზიტი, აქტივების მართვა).

Copy-Paste სული

IN Ბოლო დროსსულ უფრო და უფრო ნაკლებად, მაგრამ მაინც საკმაოდ ხშირად, Bitrix გაიძულებს რაღაცის კოპირება-პასტის გაკეთებას. თუ გსურთ შეცვალოთ კომპონენტის მოქმედება, დააკოპირეთ და ჩასვით. თუ გსურთ შექმნათ თქვენი საკუთარი ატვირთვის შაბლონი, დააკოპირეთ და ჩასვით სისტემა და დაასრულეთ იგი. თუ გსურთ გააკეთოთ თითქმის იგივე შაბლონი, რაც გაქვთ, დააკოპირეთ და ჩასვით და ოდნავ შეცვალეთ. და ისინი ამაზე საუბრობენ დამწყები დეველოპერების კურსებზე. Სიტყვები არ მყოფნის.

აქტივების მართვა და CDN

მე ძალიან მომწონს, როგორ მართავს Bitrix რესურსებს. პრინციპში შესაძლებელია კონკრეტული „ბიბლიოთეკების“ კომპლექტის რეგისტრაცია. თითოეული ბიბლიოთეკა არის css/js ფაილების ნაკრები, რომელიც შეიძლება დამოკიდებული იყოს ზოგიერთ სხვა ბიბლიოთეკაზე. თუ თქვენ დაუკავშირებთ ბიბლიოთეკას გვერდს, მაშინ მის დაკავშირებამდე ყველა დამოკიდებულება მოგვარდება და ყველა დამოკიდებული ბიბლიოთეკა ჩასმული იქნება გვერდზე. როგორც ჩანს, ყველაფერი კარგადაა, ფორმაში მხოლოდ თითოეული რესურსი იქნება ჩასმული ცალკე ფაილისკრიპტში ან ბმულის ტეგში. და ამის წყალობით, არის საიტები, რომლებსაც აქვთ 30-50 სკრიპტი დაკავშირებული და ამდენივე სტილის ფაილი.
უაზრო კითხვაა, თქვეს მათ Bitrix-ში და გააკეთეს ჯადოსნური პუნქტი, რომელიც აერთიანებს ყველა ამ ფაილს ერთში. და გამოჩნდა საიტები, სადაც 50 სკრიპტის ნაცვლად 2 იყო, თითო 300-500 კბ. რამდენიმე ხნის წინ ეს შერწყმა შეცდომით მუშაობდა და რამდენჯერმე გააერთიანა ერთი და იგივე რესურსები, ახლა კი, როგორც ჩანს, გამოსწორდა.
შემდეგ კი Bitrixoids გზას დაადგა - მათ დაამატეს ყველა რესურსის CDN სერვერზე ატვირთვის შესაძლებლობა. რომელიც ყოველთვის იშლება...
შემდეგ გამოჩნდა Google Pagespeed Insights, რომელიც გირჩევთ ყველა რესურსის გადატანას გვერდის ბოლოში. და Bitrix-ში მათ კვლავ გააკეთეს ჯადოსნური ყუთი, რომელიც სულელურად გამოტოვებს სხეულში არსებულ ყველა რესურსს, თუ ისინი არ არის მონიშნული სპეციალური ატრიბუტით.
ისინი ასევე ავრცელებენ თავიანთი სკრიპტების მინიფიცირებულ ვერსიებს ყუთთან ერთად, რომლებიც დაკავშირებულია ადმინისტრაციულ პანელში სხვა ჯადოსნური ველის გამოყენებისას.
ზოგადად, არანაირი scss თქვენთვის, არანაირი TypeScript. თუ გსურთ რესურსების კომპეტენტურად მართვა, არ გამოიყენოთ ჩაშენებული Bitrix სისტემა, გამოიყენეთ ვებპაკეტი, რომელიც მარტივად შეიძლება დაწყვილდეს 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, რომელიც შეიცავს 1000-ზე მეტ ხაზს. საკმარისია მისი მემკვიდრეობით ერთხელ მიღება, პროდუქტის რამდენჯერმე განახლება ხანგრძლივი დროის განმავლობაში და შეგიძლიათ მიიღოთ არასამუშაო გაცვლა 1C-ით. ამიტომ, დეველოპერები ხშირად არ აწუხებენ ამ კლასს და ცდილობენ როგორმე შევიდნენ იმპორტის პროცესში ღონისძიების დამმუშავებლების გამოყენებით. Bitrix-ში მოვლენის დამმუშავებლებთან მუშაობა, განსაკუთრებით ინფობლოკის მოდულში, ასევე არ არის ძალიან სასიამოვნო გამოცდილება, თუნდაც მხოლოდ იმიტომ, რომ იგივე ტიპის მოვლენები ერთნაირად არ არის მოწყობილი და ზოგიერთი ღონისძიება უბრალოდ არ არის საკმარისი.
ზოგადად, ყველაფერი ისეთივე სამწუხაროა, როგორც ადრე.

შეუსაბამობა

ზოგჯერ მეჩვენება, რომ სხვადასხვა მოდულის დეველოპერები ერთმანეთთან ნამდვილად არ ურთიერთობენ. ბირთვის წყაროების შესწავლისას, თქვენ წააწყდებით ძალიან განსხვავებულ გადაწყვეტილებებს, რომლებიც შეიძლება განხორციელდეს ერთ ძრავზე, მაგრამ რატომღაც ისინი განსხვავებულად არის დანერგილი.
მაგალითად, შეგიძლიათ მიიღოთ საინფორმაციო ბლოკის ელემენტების და UserFields თვისებები. ორივე ერთეული ფაქტიურად დამატებითი ველია სხვა ერთეულისთვის. მას აქვს ტიპი, მნიშვნელობა და აღწერა. მნიშვნელობა ინახება მონაცემთა ბაზის ცალკეულ ცხრილ(ებ)ში, მათ აქვთ დაახლოებით მსგავსი მონაცემთა წვდომის ინტერფეისი. რატომ არ შექმნათ იგივე ინტერფეისი მათთვის?
მარტის ბოლოს გაყიდვების მოდული განახლდა უახლესი ვერსია, და ასევე დაჰპირდნენ თვითნებურ ქონებას შეკვეთებისთვის. ნამდვილად არის ახალი, მესამე ინტერფეისი გაფართოებულ ერთეულებთან მუშაობისთვის?

Bitrix24

ეს ზოგადად ცალკე განხილვის თემაა. დაბნეულობა ხშირად ჩნდება ამ სისტემის გამო. B24-ისთვის არის 2 ვარიანტი - SaaS და Standlone. არის B24-ის ბაზარი, მაგრამ ის შეიცავს აპლიკაციებს მხოლოდ SaaS ვერსიისთვის! თუ თქვენ გაქვთ ყუთიანი ვერსია, შეძენილი 200 გრანდად, თქვენ ვერ შეძლებთ ისეთი პოპულარული აპლიკაციების დაყენებას, როგორიც არის დოკუმენტის დიზაინერი, და ზოგადად, თქვენ ვერ შეძლებთ Bitrix24-ის ბაზარიდან რომელიმე აპლიკაციის ინსტალაციას Bitrix24-ისთვის. ეს ისეთი პარადოქსია.
ამის ნაცვლად, ბაზარი რეგულარული ვერსიიდან ხელმისაწვდომი იქნება თქვენს Bitrix24-ში. იქ კიდევ ბევრი გამოსავალია, მაგრამ ისინი ძირითადად კონცენტრირებულია საიტის მენეჯმენტის გარშემო და არა B24-ზე.

Bitrix24, როგორც მითხრეს განყოფილებაში ტექნიკური მხარდაჭერა, ეს არის სრული სისტემა. თუ ხელს უშლით სისტემის სტანდარტული კომპონენტების მუშაობას, მაშინ მოემზადეთ, რომ ეს ფუნქციონირება დაირღვეს შემდგომი განახლებებით. Bitrix არ იმედოვნებს თქვენზე, რომ დაასრულოთ პორტალის კომპონენტები და ეს იმისდა მიუხედავად, რომ ისინი ოფიციალურად მიმართავენ კლიენტებს პარტნიორებს

სხვათა შორის, კომპონენტების შეცვლა B24-ის ყუთის ვერსიაში საკმაოდ რთული ამოცანაა. კომპონენტები, რომლებიც ქმნიან js კოდს, რომელსაც წვდება ajax-ის გამოყენებით php კოდი, რომელიც საპასუხოდ წარმოქმნის html+js-ს. ეს არის ჯოჯოხეთური ნარევი, რომელშიც ჩაძირვა ნამდვილად არ გსურთ.

დოკუმენტაცია

Bitrix დოკუმენტაცია ჩამორჩება პროდუქტის განვითარებას 1-1,5 წლით. კოდი ძალიან ცუდად არის დაფარული phpDocs-ით და ხშირად კლასამდე კომენტარი მხოლოდ საჩვენებლად არის და ავტომატურად გენერირდება IDE-ში.
ოფიციალურ წყაროებში დოკუმენტაციის წარდგენის სტილი ხშირად ზედმეტად „თავისუფალია“ და დოკუმენტაციის ზოგიერთი სტატიის შინაარსს შესაძლოა საერთო არაფერი ჰქონდეს თავად Bitrix-თან.
დეველოპერის კურსს აქვს ბევრი ინფორმაცია, მაგრამ ფორმატი, რომლითაც დეველოპერი ეცნობა სისტემის შესაძლებლობებს, არ იძლევა აღქმის საჭირო დონეს. თუ მიდიხართ Symfony Cookbook-ზე, იქ ყველაფერია ასახული, ყველა საჭირო ასპექტი აღწერილია ვერსიის მიხედვით. მაშინ როცა Bitrix-ში დეველოპერის სასწავლო კურსი გაურკვეველი სახით შეიცავს სტრუქტურირებულ ინფორმაციას ძველი და ახალი ბირთვების შესახებ, რომელიც ჯერ ცალკეა წარმოდგენილი და შემდეგ შერეული, რაც დამწყებთათვის თავის ტკივილს აყენებს.

განვითარების პროცესის ორგანიზება

სისტემის სპეციფიკიდან გამომდინარე, არც ისე ადვილია მოსახერხებელი განვითარების პროცესის ორგანიზება. არ არის ბიზნეს გამოცემის უახლესი ვერსია (რომელიც ხელთ იყო) ინსტალაციის დასრულების შემდეგ, დაფიქრდით, თითქმის 530 მეგაბაიტი
$ du -s *|sort -nr| cut -f 2-|კითხვისას a;do du -hs $a;შესრულებულია 523M bitrix 204K ატვირთვა 64K bitrixsetup.php 56K desktop_app 20K readme.html 20K ლიცენზია.html 4.0K ვებ . კონფიგურაცია 4.0K urlrewrite.php 4.0K readme.php 4.0K ლიცენზია.php 4.0K install.config 4.0K index.php
ამ მოცულობის კარგი ნახევარი არის ბინარები და ინსტალატორები, რომლებიც ზოგადად არ არის საჭირო ვერსიის კონტროლისთვის. ზოგადად, ჩვეულებრივია, რომ არ მოხდეს Bitrix ბირთვის ვერსია. თავად Bitrix-ის დეველოპერები უზრუნველყოფენ ბირთვის მთლიანობას და მართავენ სხვადასხვა მოდულის ვერსიების დამოკიდებულებებს განახლებების დროს. მაგრამ ამას დაუყოვნებლივ აქვს მინიმუმ ერთი დიდი მინუსი - შეუძლებელია სრულად მუშა პროექტის განთავსება ვერსიის კონტროლიდან, თქვენ უნდა აკრიფოთ იგი ნაწილებად: მიიღეთ ბირთვის წყაროები Bitrix-ის სარეზერვოდან, ხოლო დეველოპერების წყაროები git-დან; .
არც ბაზაზე მიდის საქმეები. თუ თქვენ თავად შეგიძლიათ გამოიყენოთ მიგრაცია განვითარების დროს, მაშინ 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-ის დეველოპერის კურსის არქიტექტურის განყოფილებაში იწერება მარკეტინგული ზარები. ახლა ისინი იქ არ არიან. დალუქეს კიდეც, ეტყობა ეჩქარებოდათ.

გმადლობთ დაკვირვებისთვის და თვალთვალისათვის :)

ტეგები:

1ს-ბიტრიქსი
სმ
ვებ დეველოპმენტი
ხის ოთახი
hatbitrix
ღვარძლიანები კერაზე
Თავი ხელში აიყვანე

ტეგების დამატება

). თითოეული ტეგი (განყოფილება)უნდა ჰქონდეს წყვილი (/განყოფილება). აუცილებელი პარამეტრებია სახელიდა მარყუჟი. ციკლის (სექციის) სახელი შეიძლება იყოს ნებისმიერი ასო, რიცხვი და ქვედა ხაზი. ციკლები (განყოფილება)შეიძლება იყოს წყობილი და დაბუდებული სექციების სახელები უნიკალური უნდა იყოს ერთმანეთისთვის. ცვლადი მარყუჟი(ჩვეულებრივ მნიშვნელობების მასივი) განსაზღვრავს მარყუჟის გამეორებების რაოდენობას. სექციაში ცვლადების დაბეჭდვისას, სექციის სახელი უნდა იყოს მითითებული ცვლადის სახელის გვერდით კვადრატულ ფრჩხილებში. (ნაწილი სხვა)შესრულებულია თუ პარამეტრი მარყუჟიარ შეიცავს მნიშვნელობებს.

ატრიბუტის სახელი	ტიპი	საჭირო	ნაგულისხმევი	აღწერა
სახელი	სიმებიანი	დიახ	ნ/ა	განყოფილების სახელი
მარყუჟი	შერეული	დიახ	ნ/ა	მნიშვნელობა, რომელიც განსაზღვრავს ციკლის გამეორებების რაოდენობას.
დაწყება	მთელი რიცხვი	არა	0	პოზიციის ინდექსი, რომლითაც მარყუჟი დაიწყება. თუ მნიშვნელობა უარყოფითია, მაშინ საწყისი პოზიცია გამოითვლება მასივის ბოლოდან. მაგალითად, თუ მარყუჟის ცვლადს აქვს 7 ელემენტი და დაწყების ატრიბუტის მნიშვნელობა არის -2, მაშინ საწყისი ინდექსი იქნება 5. არასწორი მნიშვნელობები (მნიშვნელობები მასივის გარეთ) ავტომატურად ამოიჭრება უახლოეს მოქმედ მნიშვნელობამდე.
ნაბიჯი	მთელი რიცხვი	არა	1	ნაბიჯის მნიშვნელობა, რომელიც გამოიყენება მასივის გასავლელად. მაგალითად, step=2 მიუთითებს მასივის გავლაზე 0,2,4 ელემენტებით... თუ ნაბიჯი უარყოფითია, მაშინ მასივი საპირისპირო მიმართულებით გაივლება.
მაქს	მთელი რიცხვი	არა	1	მარყუჟის გამეორებების მაქსიმალური რაოდენობა.
შოუ	ლოგიკური	არა	მართალია	მიუთითებს, აჩვენოს თუ არა ეს სექცია

შენიშვნა

Smarty 1.5.0-დან დაწყებული, სესიის თვისების ცვლადის სინტაქსი შეიცვალა (%sectionname.varname%)-დან ($smarty.section.sectionname.varname). ძველი სინტაქსი კვლავ მხარდაჭერილია, მაგრამ თქვენ მხოლოდ ახალი სინტაქსის მაგალითებს ნახავთ.

ინდექსი გამოიყენება მასივის მიმდინარე ინდექსის საჩვენებლად, დაწყებული ნულიდან (ან დაწყების ატრიბუტი, თუ მითითებული იყო ერთი) და იზრდება ერთით (ან ნაბიჯის ატრიბუტის მნიშვნელობა, თუ მითითებული იყო).

ტექნიკური შენიშვნა

თუ ნაბიჯი და დაწყების ატრიბუტები არ არის მითითებული, მაშინ ინდექსი იგივეა, რაც გამეორების განყოფილების ატრიბუტი, გარდა იმისა, რომ ის იწყება 0-დან და არა 1-ით.

iteration გამოიყენება მარყუჟის მიმდინარე გამეორების ნომრის საჩვენებლად.

შენიშვნა

ეს მნიშვნელობა დამოუკიდებელია საწყისი, ნაბიჯი და მაქსიმალური თვისებებისგან, ინდექსის თვისებისგან განსხვავებით. ასევე, გამეორებები იწყება ერთიდან და არა ნულიდან, როგორც ინდექსები. rownum არის iteration თვისების სინონიმი, ისინი ერთნაირად მუშაობენ.

მაგალითი 7.38. ქონების (სექციების) გამეორება

assign("custid",$id); ?> (სექციის სახელი=cu loop=$custid start=5 ნაბიჯი=2) iteration=($smarty.section.cu.iteration) index=($smarty.section.cu.index) id=($custid)
(/განყოფილება)

ამ მაგალითის გაშვების შედეგი:

გამეორება=1 ინდექსი=5 id=3005
iteration=2 ინდექსი=7 id=3007
iteration=3 ინდექსი=9 id=3009
iteration=4 ინდექსი=11 id=3011
iteration=5 ინდექსი=13 id=3013
iteration=6 ინდექსი=15 id=3015

ეს მაგალითი იყენებს iteration თვისებას ცხრილის სათაურის დასაბეჭდად ყოველ ხუთ სტრიქონში (გამოყენებით (if) mod ოპერატორთან ერთად).

(სექციის სახელი=co loop=$contacts) (თუ $smarty.section.co.iteration % 5 == 1) (/თუ) (/განყოფილება)