Ultimate Multisite 101

Ultimate Multisite არის WordPress-ის Multisite плагин, რომელიც საშუალებას გაძლევთ შეთავაზოთ WaaS (Web as a Service) ან ვებგვერდები როგორც სერვისი მომხმარებლებისთვის. სანამ ამაში ჩავუღრმავდებით და არ მივხვდებით, როგორ შეუძლია Ultimate Multisite თქვენს ბიზნესსა და მომხმარებლებს დაგეხმაროთ, საჭიროა საფუძვრული ცოდნის შეძენა.

WordPress-ის Multisite

ბევრ ჩვენგანს ნაცნობია სტანდარტული WordPress-ის ინსტალაცია. თქვენ შეგიძლიათ ის შექმნათ თქვენი ჰოსტინგის პროვაიდერის კონტროლ პანელიდან ან, უფრო და தைரியமானებისთვის, დაამონტაჟოთ ახალი ვებ-서ვერი და მონაცემთა ბაზა, ჩამოტვირთოთ ძირითადი ფაილები და დაიწყოთ ინსტალაციის პროცესი.

ეს მუშაობს მილიონი WordPress-ის საიტისთვის მთელ მსოფლიოში, მაგრამ აგენტების ან ჰოსტინგის პროვაიდერის პერსპექტივიდან, ერთი წუთით განვიხილოთ მოცულობა.

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

თავისი ბირთვში WordPress-ი გთავაზობთ ფუნქციას, რომელსაც უბრალოდ „Multisite“ ეწოდება და რომელიც თავის წარმომავლობას 2010 წლამდე აკავშირებს WordPress 3.0-ის გაშვებასთან. მას შემდეგ ის რამდენიმე ცვლილება განიცდის ახალი ფუნქციების შესატანად და უსაფრთხოების გასაძლიერებლად.

არსებითად, WordPress Multisite შეიძლება წარმოვიდგინოთ ასე: უნივერსიტეტი ინარჩუნებს WordPress-ის ერთ ინსტალაციას, მაგრამ თითოეული ფაკულტეტი ინარჩუნებს საკუთარ WordPress-საიტს.

ვინაიდან ამ განცხადებას დავშალოთ, მოდით შევხედოთ რამდენიმე ძირითად ტერმინს, რომლებიც გვხვდება არა მხოლოდ Ultimate Multisite-ის დოკუმენტაციაში, არამედ მთელ WordPress საზოგადოებაშიც.

ქსელი (The Network)

WordPress-ის თვალსაზრისით, მულტი-საიტის ქსელი არის ის ადგილი, სადაც ერთი და იმავე პანელიდან (dashboard) რამდენიმე ქვესაიტი შეიძლება მართული იყოს. მიუხედავად იმისა, რომ მულტი-საიტის ქსელის შექმნა განსხვავებულია ჰოსტინგ პროვაიდერებს შორის, საბოლოო შედეგი ჩვეულებრივ არის რამდენიმე დამატებითი ინსტრუქცია wp-config.php ფაილში, რათა WordPress-ს აცნობოს, რომ ის ამ კონკრეტულ რეჟიმში მუშაობს.

მულტი-საიტის ქსელს და ცალკე WordPress-ის ინსტალაციას შორის არსებობს რამდენიმე მკაფიო განსხვავება, რაც მოკლედ განვიხილავთ.

ქვედა დომენი (Subdomain) vs. ქვედა დირექტორია (Subdirectory)

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

ქვედა დირექტორიების კონფიგურაციაში ქსელმა ირჩევს გზას მთავარი დომენის მიხედვით. მაგალითად, ქსელის საიტზე „site1“ იქნება მისი სრული URL-ი https://domain.com/site1. ქვედა დომენის კონფიგურაციაში კი ქსელმა თავისი საკუთარი ქვედა დომენი მიიღებს მთავარი დომენიდან. ამრიგად, „site1“ ნიშნული საიტზე სრული URL-ი იქნება https://site1.domain.com/.

მიუხედავად იმისა, რომ ორივე ვარიანტი სრულად ვალიდური არჩევანია, ქვედა დომენების გამოყენებას აქვს რამდენიმე უპირატესობა, მაგრამ ის ასევე მოითხოვს მეტ დაგეგმვას და არქიტექტურულ დაგეგმვას.

DNS-ის მხრივ, _subdirectories_-ის გამოყენება საკმაოდ მარტივი გამოწვევაა. რადგან ქსელური საიტები უბრალოდ მშობლიური გზების შვილებია, მთავარი დომეინისთვის მხოლოდ ერთი დომეინის სახელი საჭირო უნდა არსებობდეს. _subdomains_-ისთვის კი გამოწვევა ცოტა უფრო რთულია და მოითხოვს ან თითოეული ქსელური საიტისთვის ცალკე CNAME ჩანაწერის არსებობას, ან DNS ჩანაწერებში ვულკაირდის (*) ჩანაწერის გამოყენებას.

შემდეგი განსახილველი სფერო არის SSL-ის და მისი სერტიფიკატების გამოცემის და გამოყენების საკითხი. subdirectory-ის კონფიგურაციაში ერთი დომეინის სერტიფიკატი შეიძლება გამოყენებულ იქნას, რადგან ქსელური საიტები უბრალოდ მთავარი დომეინის გზებია. ამრიგად, domain.com-ისთვის არსებული სერტიფიკატი საკმარისად მოგაწვდის SSL-ს https://domain.com/site1-, https://domain.com/site2- და ა.შ.-ისთვისაც.

subdomain-ის კონფიგურაციაში ვულკაირდული SSL სერტიფიკატის გამოყენება ყველაზე გავრცელებული ვარიანტია. ამ ტიპის SSL სერტიფიკატი უზრუნველყოფს დაშიფრვას დომეინისა და მისი subdomains-ისთვისაც. ამრიგად, ვულკაირდული SSL სერტიფიკატი მოგაწვდის https://site1.domain.com-, https://site2.domain.com- და თავად https://domain.com-სთვისაც.

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

პლაგინები და თემები

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

ამიტომ, როდესაც WordPress-ს მულტისೈტად არის კონფიგურირებული, ის აშორებს სೈტის ადმინისტრატორების შესაძლებლობას დააინსტალირონ პლაგინები და თემები, ამის ნაცვლად ეს შესაძლებლობა გადადის ახლად შექმნილი ქსელური ადმინისტრატორის ან „スーパー ადმინისტრატორის“ როლზე. ამ პრივილეგირებულ როლს შეუძლია გადაწყვიტოს, թ하시და სურს თუ არა ქსელის სೈტების ადმინისტრატორებს დაინახონ ან მიაღწიონ პლაგინების მენიუს მათ დ_{a}შბორდში, და თუ ასე, ეს უფლებები ვრცელდება პლაგინების აქტივაციაზე თუ დეაქტივაციაზე.

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

მომხმარებლები და ადმინისტრატორები

WordPress Multisite-ში ყველა ქსელური სைட் იზიარებს ერთსა და იმავე მონაცემთა ბაზას და ამიტომ იზიარებს ერთსა და იმავე მომხმარებლებს, როლებსა და შესაძლებლობებს. ყველაზე შესაფერისი გზა ამის გაგებისთვის ის არის, რომ ყველა მომხმარებელი ქსელის წევრია და არა კონკრეტული სೈტის.

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

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

მიუხედავად იმისა, რომ ეს არ არის უცხო ცნება საწარმო სისტემებში, ერთი ადგილი მომხმარებლების რეგისტრაციისა და ავтенტიზაციისთვის ხშირად რთული კონცეფციაა მათთვის, ვინც მარტო WordPress ინსტალაციებზე შე familiarize-ით არის, სადაც მომხმარებლის ადმინისტრირება ცოტა უფრო მარტივია.

Media (Mídia)

WordPress Multisite-ში ქსელური საიტები ერთ საერთო მონაცემთა ბაზას იზიარებენ და ფაილის სისტემაზე მედია ფაილებისთვის ცალკე გზებს ინახავენ.

სტანდარტული WordPress-ის მდებარეობა (wp-content/uploads) შენარჩუნებულია; თუმცა, მისი გზა იცვლება ქსელური საიტის უნიკალური ID-ის ასახვისთვის. შედეგად, ქსელური საიტის მედია ფაილები ჩნდება როგორც wp-contents/uploads/site/[id].

Permalinks (პერმალિંკები)

როგორც ადრე აღვნიშნეთ, არსებობს ქვესუბドომეინის (subdomain) და ქვეგ文件夹ის (subdirectory) კონფიგურაციის შორის მკაფიო უპირატესობები და აი, გზები.

ქვეგ文件夹ის კონფიგურაციაში, მთავარ საიტს (პირველი საიტი, რომელიც ქსელის შექმნისას იქმნება) და ქსელური ქვესაიტებს უნდა ჰქონდეთ ერთი და იგივე გზა დომეინიდან. ამან დიდი კონფლიქტების პოტენციალი შეიძლება.

პოსტებისთვის მთავარ საიტზე დამატებულია სავალდებულო /blog/ გზა, რათა თავიდან იქნას აცილებული ქსელური საიტებთან კოლისები. ეს ნიშნავს, რომ ლამაზი პერმალિંკები, როგორიცაა ‘Post name’, წარდგენილი იქნება როგორც domain.name/blog/post-name/.

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

Static Pages (სტატიკური გვერდები)

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

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

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

რეგისტრაცია

WordPress Multisite-ის ქსელური პარამეტრებში ხელმისაწვდომია რამდენიმე ახალი მომხმარებლის რეგისტრაციის ვარიანტი, რაც საშუალებას აძლევს როგორც ახალებს, ასევე არსებულ მომხმარებლებს შექმნან საიტები.

განსხვავებით ცალკე WordPress ინსტალაციებისგან, ქსელის საიტებს არ აქვთ ის მ परिचित ვარიანტები, რომლებიც საშუალებას იძლევა მომხმარებლების რეგისტრაცია ან ამ რეგისტრაციების როლებს მიენიჭონ.

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

მაგალითად, წარმოიდგინეთ, რომ თქვენი WordPress Multisite ახალი ამბებისა და ინფორმაციის ბიზნესშია. თქვენ შექმნით multisite-ს და შემდეგ ქსელური საიტები ქმნით ფინანსებისთვის, ტექნოლოგიებისთვის, გასართობებისთვის და სხვა ინტერესების სფეროებისთვის, ხოლო პლაგინებისა და თემების საერთო კონტროლის შენარჩუნებით. თითოეულ ქსელურ საიტს თავისი ქსელური საიტის ვიზუალური და მომხმარებლის გამოცდილების მიმართ ბევრად უფრო მეტი კონტროლი ექნება, ვიდრე კस्टम პოსტ-ტიპები ან ჩვეულებრივი პოსტის კატეგორიები.

ამ დონეზე, როდესაც მომხმარებელი შეს entra (log in) ხდება, ის ქსელში შედის და საბოლოოდ ყველა ქსელურ საიტზეც არის შესული, რათა უწყვეტი გამოცდილება მიეცეს. თუ თქვენი ახალი საიტი გამოწერაზე იქნება დაფუძნებული, ეს იდეალური გადაწყვეტა და შედეგია.

თუმცა, თუ multisite-ის განხორციელების განზრახული ბუნება და მიზანი არის სხვადასხვა ქსელური საიტების შეთავაზება, რომლებიც ერთმანეთთან არანაირ ურთიერთობას არ ემართება, თითქმის ყოველთვის საჭიროა გარე ან დამატებითი პლაგინების გამოყენება მომხმარებლის როლების მანიპულირებისთვის.

დომენი და SSL

დავესწავლოთ WordPress Multisite ინსტალაცია, რომელიც თითქმის ჩვენს ყურადღებას არ იპყრობს - Wordpress.com. ეს არის ყველაზე ვრცელი მაგალითი WordPress multisite-ისთვის და ავლენს მის ფართო შესაძლებლობას, რომ იყოს მორგებული და შექმნილი მიზნის შესასრულებლად.

დღეს ინტერნეტის თანამედროვე სამყაროში SSL-ის გამოყენება თითქმის აუცილებელია და WordPress multisite-ების ადმინისტრატორებს მალე ამ გამოწვევები გაუგებენ.

subdomain კონფიგურაციაში საიტები იქმნება ძირითადი დომენის სახელის საფუძველზე. ასე, 'site1' ღილაკით დადგენილი საიტი შეიქმნება როგორც 'site1.domain.com'. ვულკაირული SSL სერტიფიკატის გამოყენებით, ქსელური ადმინისტრატორი შეძლებს ამ გამოწვევის წარმატებით გადალახვას და უზრუნველყოფს SSL-ში დაშიფრვის შესაძლებლობას ქსელისათვის.

WordPress Multisite-ს აქვს დომეინის മാპინგის ფუნქცია, რომელიც საშუალებას აძლევს ქსელურ საიტებს ასოცირდნენ საკუთარ დომეინებთან ან დომეინებთან, რომლებიც განსხვავებულია ქსელის ძირითადი დომეინისგან.

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

ამ დონეზე, მიუხედავ იმისა, რომ WordPress Multisite საშუალებას გაძლევთ დაუკავშიროთ www.anotherdomain.com „site1“-ს, ქსელის ადმინისტრატორს რჩება გამოწვევა დომეინის записей გარე მართვისა და SSL სერტიფიკატების განხორციელების მხრივ.

Ultimate Multisite

როდესაც გაგებულია განსხვავებები ცალკე WordPress-ის ინსტალაციასა და Multisite ინსტალაციებს შორის, მოდით დავხედოთ, თუ როგორ არის Ultimate Multisite Website as a Service (WaaS) -ის უმაღლესი იარაღი.

შესავალი

Ultimate Multisite თქვენი შვეიცარიული ნივთია WaaS-ის შესაქმნელად. წარმოიდგინეთ Wix.com, Squarespace, WordPress.com და შემდეგ საკუთარი სერვისების მფლობობა.

내 შუაში Ultimate Multisite იყენებს WordPress Multisite-ს, მაგრამ ის ამას ისე აკეთებს, რომ არა მხოლოდ წყვეტს ქსელის ადმინისტრატორების წინაშე არსებულ მრავალფეროვან გამოწვევებს multisite ინსტალაციებთან დაკავშირებით, არამედ აუმჯობესებს შესაძლებლობებს და უზრუნველყოფს სხვადასხვა გამოყენების შემთხვევის მხარდაჭერას.

შემდგომ ნაწილებში განვიხილავთ ზოგიერთ საერთო გამოყენების შემთხვევასა და ამ შემთხვევების მხარდაჭერისთვის საჭირო გათვალისწინებებს.

გამოყენების შემთხვევები

შემთხვევა 1: სააგენტო

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

სააგენტოებისთვის Ultimate Multisite წარმოადგენს უდიდეს ღირებულებას იმის შესაძლებლობით, რომ ერთ პლატფორმაზე მრავალი ვებსაიტის მასპინძლობა და მართვა შეძლოთ. კიდევ უფრო მნიშვნელოვანია სააგენტოებისთვის, რომლებიც სტანდარტიზებულ დიზაინს კონკრეტულ თემებზე, როგორიცაა GeneratePress, Astra, OceanWP ან სხვა, იყენებენ Ultimate Multisite-ის შესაძლებლობებს ახალი ვებსაიტებისთვის ამ თემების ავტომატურად ჩართვისთვის.

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

ყველაზე სავარაუდოა, კონფიგურაციის გამოყენება სასურველი იქნება და საბედნიეროდ Ultimate Multisite-მა დომეინის 맵핑ის და SSL სერტიფიკატების მხარდაჭერა ძალიან მარტივი გახადა მისი ინტეგრაციებით პოპულარული ჰოსტინგ პროვაიდერებთან, ასევე ისეთი სერვისებთან, როგორიცაა Cloudflare და cPanel.

ასე რომ, ამ პროვაიდერის გამოყენებით ან Ultimate Multisite-ის Cloudflare-ის უკან განთავსებით, დომეინებისა და SSL სერტიფიკატების მართვა საკმაოდ მარტივი ხდება.

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

პლაგინებისა და თემების მკაცრი კონტროლი ინარჩუნக்கப்படுகிறது პროდუქტის მიხედვით Ultimate Multisite-ის ინტუიციური ინტერფეისების მეშვეობით, რაც საშუალებას იძლევა პლაგინები და თემები ხელმისაწვდომად იქნას ან დამალული იყოს, ასევე მათი ჩართვის სტატუსის მართვისთვის ახალი ვებსაიტისთვის ინსტანციირებისას.

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

Agencies-ს სიმშვიდე შეუძლია დაუკავშირდეს Ultimate Multisite-ს, რომელიც მათ საშუალებას აძლევს, იმუშაონ ყველაზე კარგად – შესანიშნავი ვებგვერდების დიზაინში.

შემთხვევა 2: ნიშური პროვაიდერი (Niche Provider)

არსებობს ძველი ფრაზა, რომელიც ამბობს: „ერთი რამ გააკეთე და ის კარგად გააკეთე“. ბევრისთვის ეს ნიშნავს პროდუქტის ან სერვისის შექმნას ერთი ძირითადი იდეის გარშემო.

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

ბევრ მიზეზს გინდათ სერვისების შეთავაზება საერთო ჩარჩოსა და პლატფორმის საფუძველზე. შესაძლოა თქვენ შექმენით ან ინვესტიციას გააკეთეთ სპეციალური plugin-ების დიზაინში საჭირო ფუნქციონალის მისაწოდებლად, ან შეიძლება தொழில்துறையின் საუკეთესო პრაქტიკამ მოითხოვოს დიზაინის სტანდარტიზებული მიდგომის რაიმე ფორმა.

Ultimate Multisite-ის ინოვაციური მახასიათებლებიდან ერთ-ერთი არის ტემპლატის (template sites) გამოყენება. ტემპლატის ვესტზე თემა უკვე დაყენებულია და ჩართულია, საჭირო plugin-ებიც დაყენებულია და ჩართულია, ასევე შექმნილია ნიმუშური პოსტები ან გვერდები. როდესაც მომხმარებელი ახალ ვესტს ქმნის ტემპლატის საფუძველზე, ტემპლატის შინაარსი და პარამეტრები იკopieება ახლად შექმნილ ვესტზე.

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

დამოკიდებულია მოთხოვნებზე, რომელთა დაცვაც საჭიროა, როგორც ქვე-დირიტორიის (subdirectory) კონფიგურაცია, ასევე ქვე-დომენის (subdomain) კონფიგურაცია შეიძლება შესაფერისი იყოს. ამ შემთხვევაში, არქიტექტურული არჩევანი იქნება მარტივი SSL სერტიფიკატი ქვე-დირიქტორიებისთვის ან ველიუმი (wildcard) SSL სერტიფიკატი ქვე-დომენებისთვის.

შემთხვევა 3: WordPress ვებ-მასპინგი

WordPress საიტების ჰოსტინგის მრავალი გზა არსებობს, მაგრამ იშვიათია ის ასეთი მარტივი იყოს, როგორც მომხმარებელს მიაწოდოთ ვებ სივრცე წინასწარ დანერგილ WordPress-ით. ეს იმის გამო ხდება, რომ მნიშვნელოვანი სერვისის შესთავაზებისთვის საჭიროა ბევრი გადაწყვეტილებისა და გათვალისწინების ერთმანეთთან შეერთება.

Ultimate Multisite ამ ველში გამოირჩევა, რადგან ის WordPress საიტების ჰოსტინგისთვის ყოვლისმომცველ „კლავიშის“ (turnkey) გადაწყვეტას გთავაზობთ. გადაწყვეტილებას მოიცავს ძირითად მექანიზმებს, რომლებიც უზრუნველყოფენ გამოწერის სერვისების, გადახდის შეგროვებისა და მიღების ფორმებს, ფასდაკლების ვაუჩერებსა და მომხმარებელთან კომუნიკაციას.

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

განვითარებისთვის განკუთვნილი დეველოპერებისთვის, Ultimate Multisite ასევე გთავაზობთ ყოვლისმომცველ RESTful API-ს და Webhooks-ს მოვლენების შესახებ შეტყობინებისთვის (event notification).

გარე პლაგუნებისა და ლიცენზიების მრავალზე დამოკიდებულების გარეშე, Ultimate Multisite გვთავაზობს ფუნქციური და Comparable გადაწყვეტას Wix-, Squarespace-სა და WordPress.com-ის მსგავსად.

არქიტექტურული გათვლები (Architecture Considerations)

მიუხედავად იმისა, რომ ეს ყოვლისმომცველი გზამკვლევი არ არის, ქვემოთ მოცემული პუნქტები დაგეხმარება ტექნოლოგიების სწორად შერჩევაში, რათა მხარი დაუჭირეთ Ultimate Multisite-ის ინს stallაციას.

საერთო (Shared) vs. სპეციალიზებული (Dedicated) ჰოსტინგი

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

პროვაიდერისგან შესაბამისი დაცვის გარეშე, საერთო სერვერზე არსებულ საიტებს „ხმაურიანი მეზობლის“ პრობლემა აქვთ. ეს ნიშნავს, რომ ერთ სერვერზე არსებული საიტი ასეთ რესურსებს იყენებს, რომ სხვა საიტებმა უნდა დაებრძოლონ დარჩენილი რესურსებისთვის. ხშირად ეს გამოხატება იმით, რომ საიტები ნელა მუშაობენ ან დროულად არ პასუხობენ მოთხოვნებს.

როგორც თქვენ თვითონ ვებ-ჰოსტინგის პროვაიდერი, გავლენა იქნება იმაზე, რომ თქვენი მომხმარებლები აღმოჩნდნენ ცუდი სიჩქარეებით, დაბალი გვერდების რეიტინგით და მაღალი ბანბას (bounce rates) მაჩვენებლით, რაც ხშირად მომხმარებლის відხევის შედეგია, რადგან ისინი სხვა სერვისებს ეძებენ.

მოკლედ რომ ვთქვათ, იაფი არ ნიშნავს კარგი.

Ultimate Multisite-ს ცნობილია იმით, რომ ის მუშაობს რამდენიმე კარგი ჰოსტინგ პროვაიდერთან და კარგად ინტეგრირდება მათ გარემოში, რაც უზრუნველყოფს ფუნქციებს, როგორიცაა დომეინის ამოცნობა (domain mapping) და ავტომატური SSL. ეს პროვაიდერები აფასებენ შესრულებას და უფრო მაღალ დონის მომსახურებას გთავაზობენ, ვიდრე საერთო ჰოსტინგი.

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

შესრულების გათვალისწინებები

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

დაფიქრდით ამაზე: თქვენ ხართ Ultimate Multisite-ის ქსელის ადმინისტრატორი 100 საიტზე. ზოგიერთი მათგანი კარგად მუშაობს და ყოველდღე ბევრ ვებგვერდის ვიზიტორს იზიდავს.

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

თუ ერთი Ultimate Multisite საიტი უმოწოდებელია, ის პასუხისმგებელი იქნება ყველა ვიზიტორის მოთხოვნების შესრულებაზე. ეს მოთხოვნები შეიძლება იყოს დინამიური PHP გვერდებისთვის ან სტატიკური აქტივებისთვის, როგორიცაა სტილის ფაილები (stylesheets), JavaScript ან მედია ფაილები. იქნება ეს ერთი საიტი თუ ასობით, ეს ამოცანები განმეორებადი, მონოტონური და ბარგს წარმოადგენს. არ არის საჭირო CPU-ის და მეხსიერების გამოყენება PHP ფაილის დამუშავებისთვის, როდესაც შედეგი ყოველთვის სტატიკური ინფორმაციაა ყველა მოთხოვნისთვის.

ასევე, ერთი PHP ან HTML გვერდის მოთხოვნა თავის მხრივ იწვევს სკრიპტებისა და სტილის ფაილების, ასევე სურათების მეტ მოთხოვნას. ეს მოთხოვნები პირდაპირ მიმართულია თქვენს Ultimate Multisite სერვერზე.

ამ პრობლემის მარტივი გადაჭრის გზა არის სერვერის განახლება, მაგრამ ეს არ წყვეტს მეორ და პრობლემას - გეოგრაფიული ლატენტურობებს (geographic latencies). ამ პრობლემის სწორად დასაკმაყოფილებლად საჭიროა მრავალი სერვერი სხვადასხვა ადგილას.

ამ მიზეზით, უმეტესი ქსელური ადმინისტრატორები იყენებენ ფრონტ-ენდ კეშირინგის (front-end caching) გადაწყვეტილებებს და კონტენტის დისტრიბუციის ქსელებს (CDN) სტატიკური გვერდებისთვის მოთხოვნების შესასრულებლად. ამ მოთხოვნების დაკმაყოფილება და აქტივების სერვერის მიღებამდე გაგზავნა ათავისუფლებს დამუშავების რესურსებს, აღარ წარმოქმნის დაყოვნებას, თავიდან აიცილებს საჭირო განახლებებს და მაქსიმალურის ტექნოლოგიურ ინვესტიციებს.

Ultimate Multisite მოიცავს მოწინავე Cloudflare add-on-ს, რომელიც ქსელური ადმინისტრატორებს საშუალებას აძლევს თავიანთ ინსტალაციები განათავსონ Cloudflare-ის უკან და გამოიყენონ არა მხოლოდ მისი კეშირინგის შესაძლებლობები, არამედ DNS ჰოსტინგი, SSL სერტიifikატები და უსაფრთხოების მექანიზმებიც.

ბექაპები (Backups)

თქვენ შეიძლება 50 ადამიანს მიმართოთ ბექაპებზე რჩევებისთვის და 50 განსხვავებული აზრი მიიღოთ ბექაპ სტრატეგიებზე. პასუხი არის: ეს დამოკიდებულია.

რა დავადასტუროთ, რომ არ არის სადავო საკითხი, არის საჭირო სარეზ dest backup-ები და თითქმის წარმოუდგენელია, რომ ეს პროცესი მართავს მხოლოდ პროვაიდერი, განსაკუთრებით ის, ვინც მართვის სერვისს (managed service) გთავაზობთ. ამიტომ, მომხმარებლები ქსელის ადმინისტრატორს მიმართავენ ამ სერვისის მიწოდებისა და მართვისთვის. ვის მივმართოთ ქსელის ადმინისტრაციის საკითხზე კი, ეს მთლიანად განსხვავებული პრობლემაა.

ამ განყოფილების მიზნებისთვის შევთანხმდეთ, რომ backup არის სისტემის მდგომარეობის მომენტარული ასლი იმ დროის მონაცემთა, როდესაც სარეზ dest backup დაიწყო. მარტივად რომ ვთქვათ, რაც სისტემის მდგომარეობაა backup-ის დროს, ეს მდგომარეობა იჭერება და ინახება backup-ში.

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

სნაპშოტები (Snapshots)

სნაპშოტები backup-ებისთვის „ყვითელი ბურთები“ა, რადგან ისინი მარტივია, არ არის დამაბნეველი (რ until you want to restore), და „უბრალოდ მუშაობს“. თუმცა, მათ თქვენი პროვაიდერის დახმარება სჭირდებათ და ძირითადად適用დება მხოლოდ VPS-ის (Virtual Private Server) ან მსგავსის შემთხვევაში. ჩვენს „თანამედროვე პროვაიდერების“ დოკუმენტაციაში ჩამოთვლილი რამდენიმე პროვაიდერი გთავაზობთ backup-ებს, რომლებსაც ქსელის ადმინისტრატორის დამატებით ჩარევა ან გაითვალისწინება არ სჭირდება.

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

სნაპშოტები შეიძლება დამატებით ღირებულებას მოიტანოს ჰოსტინგ პროვაიდერისგან, მაგრამ ეს არის დაზღვევა ავარიებთან მიმართებაში.

გარე სკრიპტები (External Scripts)

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

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

უნდა შენიშნოს, რომ ამ სკრიპტების მუშაობის დროს სისტემის დატვირთვა გაიზრდება, რაც უნდა გაითვალისწინოთ.

პლაგინები (Plugins)

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

პლაგინების ოფციები და ფუნქციონალი განსხვავებულია, მაგრამ ძირითადად ისინი ერთი და იგივე ფუნქციას ასრულებენ: ვორდ პრეესის ფაილებისა და მონაცემთა ბაზის ასლი შექმნა. ამის შემდეგ ფუნქციონალი განსხვავდება – ზოგიერთი პლაგინი შეუძლია ბექაპები გადმოგვტვირთოს ექსტერიმენტულ სერვისებზე, როგორიცაა Google Drive ან Dropbox, ან სხვა შესაბამისი ობიექტური შენახვის სერვისებზე, როგორიცაა S3, Wasabi და სხვა. უფრო ყოვლისმომცველი პლაგინები გთავაზობენ დიფერენციალურ ბექაპებს ან რაიმე სტრატეგიას, რომელიც მხოლოდ შეცვლილი მონაცემების ბექაპს უზრუნველყოფს ექსტერიმენტული შენახვის ხარჯების შესამცირებლად.

პლაგინის არჩევისას ყურადღება მიაქციეთ, რომ ის მულტი-საიტებისთვის (multisite aware) შექმნილია. მისი მუშაობის ბუნების გამო, ბექაპის განხორციელების დროს სერვერზე დროებით დატვირთვა შეიძლება გქონდეთ, სანამ პროცესი დასრულდება.

დომენი და SSL

მულტი-საიტების ქვედომეინების რეჟიმში (subdomain mode) დომენებთან დაკავშირებით უკვე ბევრი განხილული საკითხია. ქსელური ადმინისტრატორებისთვის თითქმის უნივერსალური გადაწყვეტა არის ვულკარდ DNS-ის ჩანაწერების გამოყენება.

ამ ტიპის DNS ჩანაწერი წარმატებით დააკავშირებს ქვედომეინებს, როგორიცაა ‘site1.domain.com’ და ‘site2.domain.com’, IP მისამართთან 1.2.3.4, რაც მხარს უჭერს Ultimate Multisite-ს და უფრო ფართოდ კი WordPress Multisite-ს ქვედომეინების რეჟიმში.

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

সৌভাগ্যবশত SSL সার্টিফিকেট পাওয়ার জন্য সহজ বিকল্প রয়েছে। subdirectory মোডে আপনি একটি সাধারণ ডোমেইন সার্টিফিকেট ব্যবহার করতে পারেন। এগুলো হোস্টিং প্রোভাইডারদের কাছ থেকে সহজেই এবং বিনামূল্যে পাওয়া যায় যারা হয়তো ফ্রি LetsEncrypt সার্ভিস বা অন্য কোনো উৎস ব্যবহার করে। অন্যথায়, যদি আপনি সার্টিফিকেট সিগনেচার রিকোয়েস্ট তৈরি করতে সক্ষম হন তবে কর্তৃপক্ষ থেকে বাণিজ্যিক ভাবে এগুলো কিনতে পারেন।

subdomain মোডের জন্য, ওয়াইল্ডকার্ড SSL সার্টিফিকেট একটি ওয়াইল্ডকার্ড ডোমেইনের সাথে পুরোপুরি মিলে যায় এবং অতিরিক্ত কনফিগারেশন ছাড়াই সার্টিফিকেটটিকে মূল ডোমেইন এবং সমস্ত subdomain-এর জন্য কর্তৃত্বপূর্ণ করে তুলতে পারে।

তবে এটা মনে রাখা উচিত যে ওয়াইল্ডকার্ড SSL সার্টিফিকেটগুলো Cloudflare-এর মতো পরিষেবাগুলির সাথে কাজ নাও করতে পারে, যদি না আপনি এন্টারপ্রাইজ প্ল্যানে থাকেন বা প্রবেশ বিন্দুকে শুধুমাত্র DNS-তে সেট করেন, যেখানে সমস্ত ক্যাশিং এবং অপ্টিমাইজেশন এড়িয়ে যাওয়া হয়।

Out-of-the-box Ultimate Multisite এই সমস্যার একটি সমাধান প্রদান করে যা ওয়ার্ডপ্রেস মাল্টিসাইটের চাহিদা সম্পর্কে আমাদের বিস্তৃত অভিজ্ঞতা প্রদর্শন করে। এই সাধারণ অ্যাড-অনটি সক্রিয় করলে Ultimate Multisite আপনার Cloudflare ক্রেডেনশিয়াল ব্যবহার করে নেটওয়ার্ক সাইটগুলির জন্য স্বয়ংক্রিয়ভাবে Cloudflare-এ DNS এন্ট্রি যোগ করবে এবং তাদের মোড 'proxied' সেট করবে। এইভাবে, যখন প্রতিটি নেটওয়ার্ক সাবসাইট তৈরি করা হবে, তখন SSL সহ Cloudflare-এর সম্পূর্ণ সুরক্ষা এবং সুবিধা থাকবে।

আপনার Ultimate Multisite ইনস্টলেশনের প্রকৃতি এবং উদ্দেশ্যের উপর নির্ভর করে গ্রাহকদের নিজস্ব ডোমেইন ব্যবহার করার প্রয়োজন হতে পারে। এই ক্ষেত্রে নেটওয়ার্ক অ্যাডমিনিস্ট্রেটরকে দুটি সমস্যার সমাধান করতে হয়। একটি হলো ডোমেইন নাম হোস্টিং এবং অন্যটি হলো ডোমেইনের জন্য SSL সার্টিফিকেট।

ბევრი ადამიანისთვის Cloudflare-ის გამოყენება მარტივი ვარიანტია. მომხმარებელმა საკუთარი დომენი Cloudflare-ზე უნდა დააყენოს, CNAME-ს Ultimate Multisite-ის ძირითად დომენზე მიმართოს და Ultimate Multisite-ში თავისი დომეინის მართვა დაიწყოს საკუთარი დომეინის სახელწოდების გამოყენებისთვის.

ამას გარდა, საჭიროა ალტერნატიული გადაწყვეტილებების ძებნა, ამიტომ Ultimate Multisite გირჩევთ შესაბამის პროვაიდერების სია. ეს იმიტომ, რომ DNS-ის და SSL-ის დაყენების პროცესი შეიძლება საკმაოდ რთული იყოს. თუმცა, Ultimate Multisite-ის ინტეგრაციით ამ პრობლემები ბევრად მარტივი ხდება და პროცედურა ავტომატიზებულია.

პლაგინები (Plugins)

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

მიუხედავად იმისა, რომ ბევრ პლაგინს შეიძლება დააყენოთ WordPress Multisite-ზე, მათი აქტივაცია და ლიცენზირება ავტორების მიხედვით განსხვავდება.

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

ამიტომ, შესაძლოა უკეთესია შეამოწმოთ პლაგინის ავტორთან, თუ როგორ იმუშავებს მათი პლაგინი WordPress Multisite-თან და რა სპეციალური მოთხოვნები ან პროცედურებია საჭირო მისი ლიცენზირებისთვის.