WordPress Multisite: ჰოსტინგი, სუბდომენები და ქვედირექტორიები

WordPress Multisite საშუალებას გაძლევს ერთი WordPress-ის ინსტალაციით ბევრი საიტი აამუშაო: ბირთვის ფაილების ერთი ნაკრები, პლაგინებისა და თემების ერთი დირექტორია, ერთი მონაცემთა ბაზა, PHP პროცესების ერთი პული და ყველაფრის ზემოთ Network Admin-ის ეკრანი. ის შესაფერისია, როცა საიტები ერთ მფლობელს ეკუთვნის, ერთმანეთს ჰგავს და ერთად იმართება: უნივერსიტეტის ფაკულტეტების საიტები, ფრენჩაიზი, ენობრივი ვერსიები, რეგიონული ვიტრინების მქონე მაღაზია. ის შეუფერებელია, როცა საიტები ერთმანეთს არ უკავშირდება, სხვადასხვა კლიენტს ეკუთვნის ან სხვადასხვა პლაგინებსა და რისკის სხვადასხვა დონეს საჭიროებს. არჩევანი, რომლის გაუქმებაც ძვირი ჯდება, ასეთია: ქვედირექტორია (example.com/shop/) თუ სუბდომენი (shop.example.com). ქვემოთ განვიხილავთ, როგორ გააკეთო ეს, რას ითხოვს Multisite ჰოსტინგისგან და სად ართულებს ცხოვრებას ჩუმად რამდენიმე ცალკე ინსტალაციასთან შედარებით.

რა არის სინამდვილეში Multisite#

ჩვეულებრივ WordPress-ის ინსტალაციას ბაზაში ცხრილების ერთი ნაკრები აქვს: wp_posts, wp_options, wp_comments და ასე შემდეგ. Multisite ამ სქემას პირველი საიტისთვის ინახავს და ყოველი ახალი საიტისთვის ამატებს თითო საიტის ცხრილების დანომრილ ასლს: wp_2_posts, wp_2_options, wp_3_posts და ა. შ. ყოველ საიტს დაახლოებით დუჟინა საკუთარი ცხრილი აქვს. რამდენიმე ცხრილი მთელი ქსელისთვის საერთოა:

• wp_users და wp_usermeta - ანგარიშების ერთი სია მთელი ქსელისთვის. ადამიანს ერთი ლოგინი აქვს, როლი კი თითოეულ საიტზე ცალ-ცალკე ენიჭება.
• wp_blogs და wp_site - საიტებისა და ქსელების რეესტრი.
• wp_sitemeta - მთელი ქსელის პარამეტრები, მათ შორის სუპერ ადმინების სია და იმის აღნიშვნა, რომელი პლაგინებია ქსელის დონეზე გააქტიურებული.
• wp_signups და wp_registration_log - გამოიყენება, როცა ადამიანებს საიტების თვითონ რეგისტრაცია შეუძლიათ.

ფაილებიც ასევე იყოფა. კოდი საერთოა: ერთი wp-content/plugins, ერთი wp-content/themes, ბირთვის ერთი ასლი. ატვირთვები განცალკევებულია და პირველის გარდა ყოველი საიტი წერს wp-content/uploads/sites/<id>/-ში. პარამეტრები, შიგთავსი, მენიუები, ვიჯეტები და აქტიური თემა თითოეული საიტის საკუთარია. რომელი პლაგინებია დაინსტალირებული, ქსელის გადაწყვეტილებაა; რომელია აქტიური, საიტის გადაწყვეტილებაა, თუ სუპერ ადმინმა ისინი მთელ ქსელზე არ გააქტიურა.

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

ტერმინოლოგია ხშირად ბნელს ქმნის. ქსელი (network) მთელი ინსტალაციაა. საიტი (site) მისი ერთი წევრია. სუპერ ადმინი (super admin) ქსელის დონის როლია: ის აინსტალირებს პლაგინებსა და თემებს, ქმნის და შლის საიტებს და ნებისმიერ მომხმარებელს ცვლის. საიტის ჩვეულებრივ ადმინისტრატორს Multisite-ის ქსელში პლაგინებისა და თემების ინსტალაცია საერთოდ არ შეუძლია, მხოლოდ ისინი ჩართოს, რომლებიც სუპერ ადმინმა ხელმისაწვდომი გახადა. კლიენტები, რომლებიც საკუთარი პლაგინების დაყენებას ელოდებიან, ხშირად უკმაყოფილონი რჩებიან.

სუბდომენი თუ ქვედირექტორია#

ეს არჩევანი ერთხელ კეთდება, ქსელის გამართვისას, და მოგვიანებით WordPress ინტერფეისიდან მის შეცვლას არ გაძლევს. შემდგომი გადასვლა wp-config.php-ის, გადაწერის წესებისა და ყოველი საიტის ცხრილებში მისამართების შეცვლას და ბევრ შემოწმებას ნიშნავს, ამიტომ წინასწარ გადაწყვიტე.

პრაქტიკული განსხვავებები ასეთია.

DNS და სერტიფიკატები. ქვედირექტორიების ქსელს არაფერი სჭირდება იმ DNS ჩანაწერის გარდა, რომელიც მთავარი დომენისთვის უკვე გაქვს, და ერთი სერტიფიკატი ყველა საიტს ფარავს. სუბდომენების ქსელს სჭირდება, რომ ყოველი საიტის სახელი სერვერზე მიუთითებდეს და ყოველ სახელს სერტიფიკატი ფარავდეს. ჩვეულებრივი გამოსავალია wildcard DNS ჩანაწერი *.example.com იმავე მისამართზე, რაზეც მთავარი დომენია, და wildcard სერტიფიკატი ან სერტიფიკატი თითო სახელზე. Wildcard სერტიფიკატები, როგორც წესი, DNS-ით დადასტურებით გაიცემა, რისთვისაც საჭიროა, რომ შენს DNS პროვაიდერს ჰქონდეს API, რომელსაც შენი ინსტრუმენტი გამოიძახებს. რას ფარავს და რას არა wildcard ჩანაწერი, წაიკითხე სტატიაში DNS ჩანაწერები მარტივად, ზოგადი იდეა „ერთი სახელი ერთ სერვისზე“ კი აღწერილია სტატიაში სუბდომენები სერვერებისთვის.

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

გზების კონფლიქტი. ქვედირექტორიების ქსელში გზის პირველი სეგმენტი Multisite-ს ეკუთვნის. საიტი სახელად blog იკავებს /blog/-ს, ამიტომ მთავარ საიტზე გვერდი, კატეგორია ან პოსტის ტიპი იმავე სლაგით blog მასთან შეეჯახება. WordPress საიტის შექმნისას რეზერვირებული სახელების ნაწილს (wp-admin, files, page, feed და მსგავსი) უარყოფს, მაგრამ ვერ იცის ყველა სლაგი, რომელიც მთავარი საიტის შიგთავსში გამოგიყენებია. სუბდომენებს ეს პრობლემა საერთოდ არ აქვთ.

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

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

წესი, რომელიც მუშაობს: თუ wildcard ჩანაწერისა და მისი სერტიფიკატის გაკეთება შეგიძლია და საიტები ვიზიტორის თვალში ცალკეა, აირჩიე სუბდომენები; თუ საიტები ერთი მთლიანის რუბრიკებია ან ერთი DNS ჩანაწერით ხარ შეზღუდული, აირჩიე ქვედირექტორიები. და რომელიც არ უნდა აირჩიო, ყოველ საიტს მოგვიანებით საკუთარი დომენის სახელი შეიძლება მიეცეს, როგორც domain mapping-ის განყოფილებაშია აღწერილი.

Multisite-ის ჩართვა#

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

1. დაამატე wp-config.php-ში ერთი ხაზი, იმ კომენტარის ზემოთ, რომელიც რედაქტირების შეწყვეტას ითხოვს:

define( 'WP_ALLOW_MULTISITE', true );

1. პანელში გამორთე ყველა პლაგინი (პლაგინები, რომლებიც მისამართების გადაწერას ან გადამისამართებას ეხება, შემდეგ ნაბიჯს უშლის ხელს; მერე ისევ ჩართე).
2. გახსენი Tools, შემდეგ Network Setup. WordPress შემოგთავაზებს სუბდომენებსა და ქვედირექტორიებს შორის არჩევანს, ქსელის სათაურსა და სუპერ ადმინის ელფოსტას.
3. დააჭირე Install-ს. WordPress ცვლილებებს თვითონ არ წერს. ის გაჩვენებს კოდის ორ ბლოკს ჩასასმელად: კონსტანტებს wp-config.php-ისთვის და გადაწერის წესებს .htaccess-ის ან ვებ სერვერისთვის.

სუბდომენების ქსელისთვის wp-config.php-ის ბლოკი ასე გამოიყურება და WP_ALLOW_MULTISITE-ის ხაზის მომდევნოდ იდება:

define( 'MULTISITE', true );define( 'SUBDOMAIN_INSTALL', true );define( 'DOMAIN_CURRENT_SITE', 'example.com' );define( 'PATH_CURRENT_SITE', '/' );define( 'SITE_ID_CURRENT_SITE', 1 );define( 'BLOG_ID_CURRENT_SITE', 1 );

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

შემდეგ ჩაანაცვლე WordPress-ის ნაგულისხმევი გადაწერის წესები. Apache-ზე, .htaccess-ში, ქვედირექტორიების ქსელი იყენებს:

RewriteEngine OnRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]RewriteBase /RewriteRule ^index\.php$ - [L]# add a trailing slash to /wp-adminRewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]RewriteCond %{REQUEST_FILENAME} -f [OR]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^ - [L]RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]RewriteRule . index.php [L]

სუბდომენების ქსელში ამ წესებიდან საიტის სახელის არასავალდებულო პრეფიქსი ამოღებულია:

RewriteEngine OnRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]RewriteBase /RewriteRule ^index\.php$ - [L]RewriteCond %{REQUEST_FILENAME} -f [OR]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^ - [L]RewriteRule ^(wp-(content|admin|includes).*) $1 [L]RewriteRule ^(.*\.php)$ $1 [L]RewriteRule . index.php [L]

nginx-ზე .htaccess არ არსებობს. სუბდომენების ქსელს განსაკუთრებული არაფერი სჭირდება try_files $uri $uri/ /index.php?$args;-ისა და wildcard-ის შესაბამისი server_name-ის გარდა, ქვედირექტორიების ქსელი კი ამატებს ბლოკს, რომელიც ადმინისა და PHP-ის გზებიდან საიტის პრეფიქსს აშორებს:

if (!-e $request_filename) {    rewrite /wp-admin$ $scheme://$host$uri/ permanent;    rewrite ^(/[^/]+)?(/wp-.*) $2 last;    rewrite ^(/[^/]+)?(/.*\.php) $2 last;}

რომელ ვებ სერვერს იყენებს შენი ჰოსტინგი და კითხულობს თუ არა ის საერთოდ .htaccess-ს, ეს პირველია, რაც დაწყებამდე უნდა გაარკვიო. გადაწერის ეს ნაბიჯია, სადაც Multisite-ის წარუმატებელი გამართვების უმეტესობა ჩერდება: ყველა ქვესაიტი მთავარი საიტის 404-ს აბრუნებს ან ადმინი გადამისამართების ციკლში ვარდება.

1. ორივე ფაილის შენახვის შემდეგ ხელახლა შედი (cookie-ები იცვლება), შემდეგ ჩართე პლაგინები Network Admin-იდან.

თუ ინტერფეისი არ გინდა, WP-CLI მთელ გარდაქმნას ერთი ბრძანებით აკეთებს, საიტის დირექტორიიდან გაშვებით:

$ wp core multisite-convert --title="Example Network" --subdomains$ wp site list

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

Wildcard DNS სუბდომენების ქსელისთვის#

რომ shop.example.com ჩაიტვირთოს, სახელი სერვერზე უნდა მიუთითებდეს. ორი ვარიანტი გაქვს: ყოველი ახალი საიტისთვის A ჩანაწერი ხელით შექმნა ან wildcard ჩანაწერის ერთხელ შექმნა:

example.com.      3600  IN  A  203.0.113.10*.example.com.    3600  IN  A  203.0.113.10

Wildcard შეესაბამება ერთი დონის სიღრმის ნებისმიერ სახელს, რომელსაც საკუთარი ჩანაწერი არ აქვს, ამიტომ shop.example.com და anything.example.com ორივე გადაიყვანება, a.b.example.com კი არა. გარკვეული ჩანაწერი mail.example.com-ისთვის ან www.example.com-ისთვის wildcard-ზე ყოველთვის წინ დგას, ასე რომ ფოსტა და სხვა სერვისები საკუთარ მისამართებზე შეგიძლია დატოვო.

სერვერმაც უნდა უპასუხოს ამ სახელებზე. WordPress მარშრუტს Host სათაურით ირჩევს: როცა shop.example.com-ზე მოთხოვნა მოდის, ის ჰოსტის სახელს wp_blogs-ში ეძებს და იმ საიტს ტვირთავს. ამიტომ ვებ სერვერმა ყველა ეს სახელი ერთსა და იმავე WordPress-ის დირექტორიაში უნდა გააგზავნოს: ნაგულისხმევი ვირტუალური ჰოსტით ან server_name *.example.com ჩანაწერით. შეამოწმე ეს, სანამ რეალურ საიტებს შექმნი:

$ dig +short shop.example.com203.0.113.10$ curl -sI https://shop.example.com/ | head -n 1

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

RE:NODE-ზე აპლიკაციებისა და ვებ ჰოსტინგის გეგმებში შედის reverse proxy-ის სლოტი: A ჩანაწერს გამოჩენილ მისამართზე მიუთითებ და სერტიფიკატი ავტომატურად გაიცემა და განახლდება. ეს ეხება სერტიფიკატს იმ სახელებისთვის, რომლებსაც იქ მიამაგრებ. ჩვენ არ ვამტკიცებთ, რომ wildcard სახელები ან wildcard სერტიფიკატები მხარდაჭერილია, და არ ვაქვეყნებთ, რამდენი proxy სლოტი აქვს თითოეულ გეგმას, ამიტომ თუ სუბდომენების ქსელს ბევრი სახელით გეგმავ, აგებამდე მხარდაჭერას ჰკითხე. ქვედირექტორიების ქსელი ამ კითხვას გვერდს უვლის, რადგან ერთი სახელია. როგორ მუშაობს სერტიფიკატის ნაწილი, განმარტავს სტატია შენი დომენი და მისი სერტიფიკატი.

საიტების შექმნა, მომხმარებლები და domain mapping#

როცა ქსელი მუშაობს, ახალი საიტები იქმნება Network Admin-იდან, Sites, შემდეგ Add New, ან WP-CLI-ით:

$ wp site create --slug=shop --title="Shop" --email=admin@example.com$ wp site list --fields=blog_id,url,registered$ wp super-admin add alice$ wp plugin activate wordpress-seo --network$ wp theme enable twentytwentyfive --network

--slug ხდება სუბდომენი ან ქვედირექტორია ქსელის ტიპის მიხედვით. wp theme enable --network თემას ყველა საიტისთვის ხელმისაწვდომს ხდის, ჩვეულებრივი wp theme enable <theme> --url=shop.example.com კი მხოლოდ ერთისთვის.

Network Admin-ში, Settings-ის ქვეშ, ყველაზე მნიშვნელოვანი პარამეტრებია:

• Registration: გამორთული, მხოლოდ მომხმარებლის ანგარიშები, შესულ მომხმარებლებს საიტების რეგისტრაცია შეუძლიათ, ან ორივე. დატოვე გამორთული, თუ საჯარო სერვისს არ ამუშავებ, რადგან საიტების ღია რეგისტრაცია სპამ საიტებს სწრაფად იზიდავს.
• Upload file types and size: ქსელის დონის Max upload file size აქ ისმება (ველი fileupload_maxk, ნაგულისხმევი მნიშვნელობა მცირეა, 1500 KB), PHP-ის upload_max_filesize-გან დამოუკიდებლად. ორივე ლიმიტი მოქმედებს და ნაკლები იმარჯვებს. იხილე php.ini-ის პარამეტრები, რომლებიც მნიშვნელოვანია.
• Menu settings: ხედავენ თუ არა საიტების ადმინისტრატორები Plugins მენიუს საერთოდ.

ერთი კონსტანტა, რომლის ადრე დაყენებაც ღირს, განსაზღვრავს, სად მოხვდება ვიზიტორი, რომელიც არარსებულ საიტს ითხოვს:

define( 'NOBLOGREDIRECT', 'https://example.com' );

მის გარეშე სუბდომენში შეცდომა ზოგად გვერდს „ეს საიტი არ არსებობს“ აჩვენებს.

Domain mapping ნიშნავს საიტისთვის საკუთარი დომენის მიცემას, www.shop-example.net, ქსელის დომენის ქვეშ მყოფი სახელის ნაცვლად. WordPress 4.5-დან ეს ჩაშენებულია და პლაგინი არ სჭირდება: Network Admin-ში საიტი დაარედაქტირე და მისი Site Address (URL) ახალ დომენზე შეცვალე. დანარჩენი WordPress-ის გარეთ ხდება:

1. ახალი დომენის A ჩანაწერი იმავე სერვერზე მიუთითე.
2. დარწმუნდი, რომ ვებ სერვერი ამ სახელზე პასუხობს და სერტიფიკატი მას ფარავს.
3. შეცვალე Site Address Network Admin-ში, Sites, Edit-ის ქვეშ.
4. გაუშვი ძიება-ჩანაცვლება თვითონ საიტის ცხრილებზე, რადგან შიგთავსში ჯერ კიდევ ძველი მისამართებია:

$ wp search-replace 'shop.example.com' 'www.shop-example.net' \    --url=shop.example.com --network --dry-run

ჯერ --dry-run-ით გაუშვი, წაიკითხე რაოდენობები, შემდეგ ისევ გაუშვი მის გარეშე. სუბდომენების ქსელში გადატანილი დომენი ცალკე შესვლის cookie-საც ნიშნავს, ამიტომ ქსელის დომენზე შესული მომხმარებლები იქ შესულები არ არიან. ზოგიერთი კონფიგურაცია ასევე ამატებს define( 'COOKIE_DOMAIN', '' );-ს, რომ WordPress-მა cookie მშობელ დომენზე არ ააძულოს.

რა ჯდება Multisite რესურსებში#

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

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

მონაცემთა ბაზა. ყოველი საიტი დაახლოებით დუჟინა ცხრილს ამატებს, ამიტომ 200 საიტის ქსელი ორი ათასზე მეტ ცხრილს შეიცავს. MySQL-ისთვის ეს პრობლემა არ არის, მაგრამ ინსტრუმენტები და პლაგინები, რომლებიც ყველა ცხრილს გადაუვლიან - backup პლაგინები, ძიება-ჩანაცვლება მთელ ქსელზე, ზოგი მიგრაციის სკრიპტი - ნელდება. თვით WordPress-ს დიდი ქსელებისთვის დამცავი მექანიზმი აქვს: როგორც კი ქსელი 10 000 საიტს ან მომხმარებელს გადააჭარბებს (ზღვარი wp_is_large_network, ფილტრით იცვლება), ის ზოგიერთ ქსელურ დათვლის მოთხოვნას გამოტოვებს, რომლებიც სხვაგვარად ძალიან ნელი იქნებოდა. პატარა გეგმაზე ამ ზღვარს ძნელად მიაღწევ, მაგრამ wp_options-ში ათი ათასი autoload ჩანაწერის ეფექტს ბევრად ადრე იგრძნობ. ყოველი საიტი ყოველ მოთხოვნაზე თავის autoload პარამეტრებს ტვირთავს, ამიტომ პლაგინი, რომელიც ერთ საიტზე wp_options-ს ბერავს, მხოლოდ იმ საიტს ანელებს, საერთო ცხრილები wp_users და wp_usermeta კი მთელ ქსელთან ერთად იზრდება და ყოველ შესვლაზე ექცევა.

ობიექტის cache. მუდმივი ობიექტის cache Multisite-ს ერთ საიტზე მეტად ეხმარება, რადგან ყოველი მოთხოვნა ქსელის საერთო ცხრილებს რამდენჯერმე მიმართავს. cache-ის გასაღებები საიტის ID-ს შეიცავს, ამიტომ კარგი ობიექტის cache პლაგინი საიტებს განცალკევებულად ინახავს. გამართვას აღწერს სტატია Valkey ობიექტის cache WordPress-ისთვის, ხოლო WordPress-ის სიჩქარე და cache გვერდების cache-ს განიხილავს, რომელიც ქსელში ქსელს უნდა ითვალისწინებდეს, თორემ ჰოსტის სახელის მიხედვით ერთი საიტის გვერდებს მეორის მაგივრად დააბრუნებს.

WP-Cron. ყოველ საიტს საკუთარი ამოცანების გრაფიკი აქვს, რომელიც მის ცხრილში wp_<id>_options ინახება, და WP-Cron ყოველი საიტის გვერდების ნახვებიდან ცალ-ცალკე ირთვება. გაჩუმებულმა საიტმა ორმოცდაათსაიტიან ქსელში დღეების განმავლობაში დაგეგმილი ჩანაწერები შეიძლება არ გამოაქვეყნოს. რეალური cron-ით გამოსწორება სტატიიდან WP-Cron თუ რეალური cron ისევ მოქმედებს, ერთი ცვლილებით: ვადაგასული ამოცანები ყოველი საიტისთვის უნდა გაუშვა და არა ერთისთვის. დაყენებული DISABLE_WP_CRON-ის პირობებში ამას ერთი cron ხაზი აკეთებს:

$ wp site list --field=url | xargs -I % wp --url=% cron event run --due-now

გაუშვი ყოველ ხუთ წუთში. ყოველი საიტი WordPress-ის ახალი ჩატვირთვაა, ამიტომ ორმოცდაათსაიტიან ქსელში ის გარკვეულ დროს გრძელდება და ამ დროის მანძილზე CPU-ს ტვირთავს. თუ შენს გეგმაში CPU-ს წილი მცირეა, გაშვებები დროში გაანაწილე ან სია გაყავი. Schedules ჩანართი RE:NODE-ის პანელში ის ადგილია, სადაც cron-ის სტილის ამოცანა იგება იმ გეგმებზე, რომლებზეც ის არსებობს.

დისკი და ატვირთვები. ატვირთვების საქაღალდეები საიტების მიხედვით იზრდება და საერთო არ არის, ამიტომ ერთმა დიდი მედიათეკის მქონე საიტმა დისკი ყველას შეიძლება გაუვსოს. Network Admin-ში საიტზე ატვირთვების ადგილის კვოტის დაყენება შეიძლება (blog_upload_space, ნაგულისხმევი 100 MB), რაც ღირს ჩართვად, თუ საიტებს სხვა ადამიანებს გადასცემ.

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

როდის არ გამოიყენო Multisite#

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

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

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

გჭირდება ერთი საიტის აღდგენა. Multisite ქსელის backup ერთი ბაზისა და ფაილების ერთი ხის backup-ია. ერთი საიტის გუშინდელ მდგომარეობაში დაბრუნება ნიშნავს მისი ცხრილებისა და საქაღალდის uploads/sites/<id>/ ხელით ექსპორტს. WP-CLI ექსპორტს მისაღებად აადვილებს:

$ wp db export shop-site.sql --tables=$(wp db tables --scope=blog --url=shop.example.com --format=csv)

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

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

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

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

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

RE:NODE-ზე ცალკე ინსტალაციების გზა იაფად საცდელია. WordPress-ის ხაზი აინსტალირებს WordPress-ს wp-config.php-ით, რომელიც უკვე საკუთარ MySQL ბაზაზეა გამართული, და იწყება თვეში $5-დან, თითოეულ გეგმას კი საკუთარი backup-ის სლოტები და საკუთარი პანელი აქვს. რამდენიმე პატარა გეგმა გაძლევს საიტების მიხედვით აღდგენას, თითოეულზე საკუთარ CPU-სა და მეხსიერების ლიმიტებს და საერთო დარტყმის ზონის არარსებობას, იმის ფასად, რომ ყოველს ცალ-ცალკე განაახლებ. საიტის ინსტალაციებს შორის გადატანას აღწერს სტატია WordPress-ის გადატანა ახალ ჰოსტინგზე, რომელიც მოგვიანებით ქსელის გაყოფისასაც გამოგადგება.

საიტის გადატანა ქსელში და ქსელიდან#

საიტების გადატანა მომენტია, როცა Multisite მოწესრიგებულობას კარგავს. არსებული ცალკე საიტი შეიძლება შემოვიდეს ჩაშენებული Tools, Export და Import-ით, რომლებიც ჩანაწერებს, გვერდებსა და მედიის ბმულებს გადააქვთ, ან პლაგინით, რომელიც ცხრილებს გადააქვს. რადგან ცხრილების პრეფიქსი wp_<id>_-ად იცვლება, ბაზის უბრალო კოპირება არ მუშაობს: ცხრილები უნდა გადაარქვა სახელი, განაახლო ჩანაწერი wp_<id>_options, რომელიც მომხმარებლის როლებს ინახავს (wp_<id>_user_roles), და მისამართები გაასწორო.

საპირისპირო მიმართულებით საიტი ქსელს ასე ტოვებს: მისი ცხრილები გადაიტანება, სახელი ნაგულისხმევ პრეფიქსზე უბრუნდება, საქაღალდე uploads/sites/<id>/ გადაიკოპირება wp-content/uploads/-ში და შემდეგ გზებსა და მისამართებზე ძიება-ჩანაცვლება სრულდება. მომხმარებლები თავიდან უნდა შეიქმნას, რადგან ისინი საერთო ცხრილში wp_users ცხოვრობენ. ეს წინასწარ დაგეგმე: ეს არის Multisite-ის არჩევის რეალური ფასი საიტებისთვის, რომლებიც მოგვიანებით დამოუკიდებელი შეიძლება გახდეს.

პრობლემების გადაჭრა#

ყველა ქვესაიტი მთავარ საიტს ან 404-ს აჩვენებს. გადაწერის წესები ცალკე საიტის ძველი წესებია ან ვებ სერვერი ჰოსტის სახელს ამ WordPress-ის დირექტორიაში არ აგზავნის. ხელახლა გამოიყენე შენი ქსელის ტიპის ბლოკი Network Setup-იდან და დარწმუნდი, რომ ვირტუალური ჰოსტი wildcard-ზე პასუხობს.

გადამისამართების ციკლი `/wp-admin/`-ზე. ჩვეულებრივ cookie-ებია. შეამოწმე, რომ DOMAIN_CURRENT_SITE ზუსტად ემთხვევა მისამართის ზოლში მითითებულ ჰოსტს (www-ით ან მის გარეშე), გაწმინდე დომენის cookie-ები და დარწმუნდი, რომ define( 'COOKIE_DOMAIN', '' ); არ არის დაყენებული შეუსაბამო მნიშვნელობაზე.

„Error establishing a database connection“ მხოლოდ ერთ ქვესაიტზე. საიტის ცხრილები აკლია ან პრეფიქსი არასწორია - ჩვეულებრივ ხელით აღდგენის შემდეგ. შეამოწმე, რომ wp db tables --url=shop.example.com ცხრილებს wp_<id>_ ჩამოთვლის. თუ მთელი ქსელი არ მუშაობს, დაიწყე სტატიით WordPress-ის თეთრი ეკრანი და 500 შეცდომები.

ქსელის გამართვის შემდეგ პლაგინები გაქრა. პლაგინები გამართვის ნაბიჯისთვის იყო გამორთული, ასე უნდა ყოფილიყო. ჩართე ისინი Network Admin-ში, Plugins-ის ქვეშ, და თითოეულისთვის გადაწყვიტე, ქსელის დონეზე უნდა გააქტიურდეს თუ არა.

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

FAQ#

შეიძლება თუ არა ცალკე WordPress საიტის მოგვიანებით Multisite-ად გარდაქმნა?

დიახ. დაამატე WP_ALLOW_MULTISITE, გაუშვი Tools, Network Setup (ან wp core multisite-convert) და ჩასვი გენერირებული კონსტანტები და გადაწერის წესები. ჯერ backup გააკეთე. ქვედირექტორიების ქსელები მხოლოდ ერთ თვეზე ახალგაზრდა ინსტალაციებზე ინიშნება, ამიტომ უფრო ძველი საიტი სუბდომენების ქსელად გარდაიქმნება, თუ ამას ხელით არ გამოასწორებ.

შეიძლება თუ არა მოგვიანებით სუბდომენსა და ქვედირექტორიას შორის გადართვა?

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

აჩქარებს თუ არა Multisite WordPress-ს?

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

შეიძლება თუ არა თითოეულ საიტს საკუთარი დომენის სახელი ჰქონდეს?

დიახ, ჩაშენებული domain mapping-ით WordPress 4.5-დან. ახალი დომენი სერვერზე მიუთითე, დარწმუნდი, რომ ვებ სერვერიც და სერტიფიკატიც მას ფარავს, შემდეგ შეცვალე Site Address Network Admin-ში, Sites-ის ქვეშ, და გაუშვი ძიება-ჩანაცვლება.

რამდენი საიტი ეტევა ქსელში?

თვით პროგრამას მკაცრი ზღვარი არ აქვს. პრაქტიკაში ზღვრებს განსაზღვრავს მონაცემთა ბაზა (საიტზე დაახლოებით დუჟინა ცხრილი), PHP-ის საერთო worker-ები და მეხსიერება და დრო, რომელსაც ქსელური ამოცანები, მაგალითად backup და cron, მოითხოვენ. რამდენიმე ასეულ აქტიურ საიტზე მეტისას დაფიქრდი, ხომ არ გჭირდება ბაზის ცალკე სერვერი და გამართული cache.

მუშაობს თუ არა პლაგინები Multisite-ში?

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