DataLife Engine (DLE)-ის ჰოსტინგი: მოთხოვნები და დაყენება

DataLife Engine კომერციული PHP კონტენტის მართვის სისტემაა, შექმნილი საინფორმაციო საიტებისთვის, მედია პორტალებისა და ბლოგებისთვის, და პოპულარულია ძირითადად რუსულენოვან ქვეყნებში. მისი ჰოსტინგი ნაცნობი PHP რუტინაა - ფაილები ვებ root-ში, MySQL ოჯახის ბაზა, ინსტალერი ბრაუზერში - სამი რამით, რომელიც DLE-სთვის სპეციფიკურია: ყოველ დომენზე ლიცენზია გჭირდება (ან შეზღუდული უფასო demo), მეგობრული URL-ები Apache-ისთვის დაწერილ rewrite წესებზეა დამოკიდებული, ხოლო მხარდაჭერის საზოგადოება და დოკუმენტაციის უმეტესობა რუსულ ენაზეა.

ოფიციალური მოთხოვნების გვერდის მიხედვით, მიმდინარე ვერსიებს სჭირდება PHP 8.0 ან უფრო ახალი, MySQL 5.6+ ან MariaDB 10.0+, nginx ან Apache, და PHP გაფართოებები zlib, xml, gd, curl, mbstring, fileinfo, exif და intl. ეს ციფრები მინიმუმებია; ნამდვილ საიტებზე PHP 8-ის მიმდინარე გამოშვება და მიმდინარე ბაზა უნდა მუშაობდეს. ეს გზამკვლევი გადის ლიცენზიას, დაყენებას, კონფიგურაციის ფაილებს, nginx-ს, cache-ს (Redis პროტოკოლის cache-ის ჩათვლით Valkey-ზე), განახლებებს და პრობლემებს, რომლებზეც ხალხი რეალურად წერს.

რა არის DLE და ლიცენზია#

DLE-ს ავითარებს SoftNews Media Group და ყიდის თავისი ოფიციალური საიტიდან, dle-news.ru. ის დახურული კოდის კომერციული პროგრამაა იმ გაგებით, რაც ჰოსტინგისთვის მნიშვნელოვანია: სრულ ვერსიას თავისუფლად ვერ ჩამოტვირთავ, და ლიცენზია დომენზეა მიბმული.

როგორც ოფიციალური საიტი ამ სტრიქონების წერისას აღწერს, მისი გაშვების სამი გზა არსებობს:

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

ერთი გაფრთხილება ცალკე აბზაცს იმსახურებს. რადგან DLE კომერციული და პოპულარულია, "nulled" ასლები - მეკობრული ვერსიები მოშორებული ლიცენზიის შემოწმებით - ყველგანაა, ხშირად ჩამოტვირთვის საიტებზე შაბლონებთან და მოდულებთან ერთად შეფუთული. ისინი ყველაზე გავრცელებული გზაა, რომლითაც DLE საიტები გატეხილი აღმოჩნდება: ადამიანები, რომლებიც ლიცენზიის შემოწმებას შლიან, backdoor-ის დამატებას იშვიათად ერიდებიან. დააყენე მხოლოდ ვერსია, რომელიც ოფიციალურ საიტზე შენი ანგარიშიდან ჩამოტვირთე, და მესამე მხარის მოდულები და შაბლონები მათი დეველოპერებისგან იყიდე.

მოთხოვნები და ზომის შერჩევა#

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

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

დისკის მოხმარებაში დომინირებს uploads/ - სიახლეებზე მიმაგრებული სურათები - და სერვერზე შენახული backup-ები. ორივეს თვალი ადევნე. რამდენი RAM სჭირდება WordPress-ს იმავე არითმეტიკას სხვა PHP CMS-ისთვის გადის, და აქ ის თითქმის უცვლელად მოქმედებს.

სანამ რამეს ატვირთავ, დარწმუნდი, რა PHP ვერსიასა და გაფართოებებს გაძლევს შენი ჰოსტინგი რეალურად. ფაილი <?php phpinfo(); შიგთავსით ვებ root-ში, ერთხელ ჩატვირთული და შემდეგ წაშლილი, ორივეს ჩამოთვლის. ოფიციალური FAQ აღნიშნავს, რომ install.php, რომელიც მხოლოდ "Internal Server Error"-ს აჩვენებს, ჩვეულებრივ ნიშნავს, რომ საჭირო PHP მოდული აკლია.

DLE-ს დაყენება#

1. შექმენი ბაზა და მომხმარებელი მასზე სრული უფლებებით. ჩაიწერე host, პორტი, ბაზის სახელი, მომხმარებელი და პაროლი.
2. ატვირთე საიტის ფაილები. დისტრიბუცია სერვერზე განკუთვნილ ფაილებს დოკუმენტაციისგან აცალკევებს; ატვირთე საიტის საქაღალდის შიგთავსი შენს ვებ root-ში და არა თავად საქაღალდე, თორემ საიტი მხოლოდ ქვედირექტორიის ქვეშ უპასუხებს. ატვირთე არქივი და გახსენი file manager-ით, ნაცვლად იმისა, რომ ათასობით ფაილი SFTP-ით სათითაოდ გაგზავნო - SFTP და file manager ორივე გზას ფარავს.
3. შეამოწმე უფლებები. ინსტალერი ამოწმებს, შეუძლია თუ არა DLE-ს ჩაწერა იმ დირექტორიებში, რომლებიც სჭირდება - მათ შორის backup/, uploads/ და მისი ქვესაქაღალდეები, templates/, engine/data/ და engine/cache/. გაასწორე ყველაფერი, რასაც მონიშნავს. Container-ზე დაფუძნებულ ჰოსტინგზე, სადაც PHP და file manager ერთი და იმავე მომხმარებლით მუშაობს, ეს ჩვეულებრივ ცვლილებების გარეშე გადის.
4. გაუშვი ინსტალერი https://example.com/install.php-ზე. მიიღე ლიცენზია, მიეცი გარემოს შემოწმების საშუალება, შეიყვანე ბაზის მონაცემები და შექმენი ადმინისტრატორის ანგარიში. გამოიყენე არააშკარა მომხმარებლის სახელი და გენერირებული პაროლი.
5. წაშალე `install.php`, როცა ინსტალერი გეტყვის. დარჩენილი ინსტალერი მოწვევაა, რომ შენს საიტზე თავიდან დააყენონ.
6. გაააქტიურე ლიცენზია ოფიციალურ საიტზე შენს ანგარიშში მოცემული ინსტრუქციით, თუ იყიდე.

ადმინისტრაციული პანელი /admin.php-ზეა. DLE ამ ფაილისთვის ნაკლებად აშკარა სახელის გადარქმევას უჭერს მხარს, რაც ბევრ ავტომატურ შესვლის მცდელობას წყვეტს; მიჰყევი შენი ვერსიის ნაბიჯებს, რადგან პანელის საკუთარი ბმულებიც შესაბამისად უნდა განახლდეს.

RE:NODE-ზე DLE ერთ-ერთი სისტემაა, რომლისთვისაც Engines გეგმებია შერჩეული. მას თავად აყენებ SFTP-ით ან file manager-ით - one-click ინსტალერი არ არის - და ყოველ გეგმას ორი ბაზის სლოტი აქვს, რომლებიც პანელიდან იქმნება გენერირებული host-ით, მომხმარებლითა და პაროლით, ასე რომ ბაზა უკვე არსებობს, სანამ პირველ ნაბიჯს დაიწყებ.

კონფიგურაციის ფაილები#

DLE თავის პარამეტრებს PHP ფაილებში ინახავს engine/data/-ის ქვეშ. ორს ყველაზე მეტი მნიშვნელობა აქვს.

`engine/data/dbconfig.php` ბაზასთან კავშირს ინახავს, ინსტალერის მიერ ჩაწერილს:

define ("DBHOST", "db.example.internal:3306");define ("DBNAME", "dle");define ("DBUSER", "dle_site");define ("DBPASS", "from-the-panel");define ("PREFIX", "dle");define ("USERPREFIX", "dle");define ("COLLATE", "utf8mb4");

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

`engine/data/config.php` ინახავს პარამეტრებს, რომლებსაც ადმინისტრაციულ პანელში ცვლი, System Settings-ის ქვეშ: საიტის მისამართი, ენა, დროის სარტყელი, მეგობრული URL-ები, cache და ბევრი სხვა. შეცვალე ისინი პანელიდან, სადაც შესაძლებელია; ფაილს პანელი წერს. თუ ცუდი პარამეტრი - ყველაზე ხშირად საიტის არასწორი მისამართი - გაგაძევებს, სწორედ აქ ასწორებ ხელით.

ორივე ფაილი შეიცავს საიდუმლოებებს ან პარამეტრებს, რომლებიც ამხელს, როგორ მუშაობს საიტი. ისინი PHP-ია, ამიტომ სწორად მორგებული სერვერი მათ ასრულებს და არ აჩვენებს; არასოდეს დატოვო ასლები სხვა გაფართოებებით, მაგალითად dbconfig.php.bak, რომელიც უბრალო ტექსტად გაიცემოდა.

სიმბოლოების ნაკრებს მნიშვნელობა აქვს ისტორიის მქონე DLE საიტებისთვის. ძველი საიტები ხშირად windows-1251-ში იყო აწყობილი; მიმდინარე ვერსიები UTF-8-ს იყენებს. ძველი საიტის გადატანა ნიშნავს როგორც ბაზის, ისე შაბლონების კონვერტაციას, და შეცდომა ნაცნობ დამახინჯებულ კირილიცას იძლევა. კონვერტაცია ცალკე, ტესტირებულ ნაბიჯად გააკეთე - არასოდეს სერვერის გადატანის თანმხლებ ეფექტად.

მეგობრული URL-ები nginx-ზე#

DLE-ს საძიებო სისტემებისთვის მეგობრულ URL-ებს - /news/12-site-launch.html index.php?newsid=12-ის ნაცვლად - აწარმოებს rewrite წესები .htaccess ფაილში, რომელიც ძრავას მოყვება. Apache-ზე mod_rewrite-ით ისინი უბრალოდ მუშაობს.

nginx .htaccess-ს უგულებელყოფს. nginx-ზე მეგობრულ URL-ებს სჭირდება, რომ ეს წესები nginx-ის location და rewrite დირექტივებად ითარგმნოს, და DLE-ს წესების ნაკრები გრძელია, რადგან URL-ის ყოველ ტიპს (სიახლეები, კატეგორიები, სტატიკური გვერდები, tag-ები, მომხმარებლის პროფილები, RSS) საკუთარი შაბლონი აქვს. ორი სიფრთხილე მოქმედებს:

• თარგმნე წესები შენი საკუთარი ვერსიის `.htaccess`-იდან, და არა ფორუმის პოსტიდან დაკოპირებული ფრაგმენტიდან, რომელიც სხვა გამოშვებას ეხება. შაბლონები ვერსიებს შორის იცვლება.
• დარწმუნდი, რომ გადაწერილი მოთხოვნები ისევ PHP-მდე აღწევს. გავრცელებული შეცდომა, რომელზეც DLE-სა და nginx-ის ფორუმებზე ხშირად წერენ, ისაა, რომ თარგმნილი წესი index.php-ს ჩამოსატვირთ ფაილად აწვდის, ნაცვლად მისი შესრულებისა. Rewrite-ები უნდა მიდიოდეს იმ location-ში, რომელიც .php მოთხოვნებს PHP-FPM-ს გადასცემს.

მინიმუმ, front-controller-ის სათადარიგო წესი, რომელსაც ყველა PHP CMS იყენებს, ადგილზე უნდა იყოს:

location / {    try_files $uri $uri/ /index.php?$args;}

ეს მარტო DLE-ს მეგობრულ URL-ებს ვერ აამუშავებს, რადგან DLE გზებს კონკრეტულ query პარამეტრებზე ასახავს. თუ შენს ჰოსტინგზე nginx-ის კონფიგურაციის რედაქტირება არ შეგიძლია, მეგობრული URL-ები System Settings-ში გამორთე - საიტი მაშინ index.php?... მისამართებს იყენებს, რომლებიც ყველგან მუშაობს - და ჰოსტს ჰკითხე, შეიძლება თუ არა DLE-ს წესების დამატება. მეგობრული URL-ების ჩართვა ან გამორთვა საიტის ინდექსაციის შემდეგ ყველა მისამართს ცვლის, ამიტომ გაშვებამდე გადაწყვიტე.

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

Cache, Redis-ის ჩათვლით Valkey-ზე#

DLE გენერირებულ ბლოკებსა და გვერდებს cache-ში ინახავს, და დატვირთულ საინფორმაციო საიტზე cache არის განსხვავება ბაზას შორის, რომელიც უმკლავდება, და ბაზას შორის, რომელიც ვერა. პარამეტრები ადმინისტრაციულ პანელშია System Settings-ის ქვეშ, Optimisation ჩანართზე: ჩართე cache, შემდეგ აირჩიე cache-ის ტიპი.

Redis cache DLE 14.2-ში გამოჩნდა და საშუალებას გაძლევს იმავე პანელში შეიყვანო სერვერის მისამართი, პორტი და ავთენტიფიკაციის მონაცემები. Valkey იმავე პროტოკოლზე ლაპარაკობს, რაზეც Redis, ამიტომ Valkey სერვერი Redis cache-ის backend-ად მუშაობს. წინაპირობა PHP გაფართოებაა: თუ phpinfo() redis განყოფილებას არ აჩვენებს, Redis ვარიანტი ამ ჰოსტინგზე ვერ იმუშავებს, რაც არ უნდა მოარგო პანელში. ამ შემთხვევაში ფაილური cache სწორი არჩევანია, და ის საიტების უმეტესობისთვის სავსებით საკმარისია.

ორი ჩვევა cache-ს დაბნეულობის წყაროდ ქცევას აცილებს. შაბლონების შეცვლის შემდეგ cache ადმინისტრაციული პანელიდან გაასუფთავე, რომ ვიზიტორებმა ძველი გამოტანა არ ნახონ. და cache-ის ზომა პატიოსნად შეარჩიე: გარე cache-ით DLE ინახავს ბლოკებს, რომლებიც miss-ის დროს თავიდან იგება, ამიტომ Valkey-ის მხარეს eviction-იანი პოლიტიკა შესაფერისია - Valkey-ის მეხსიერება და eviction პოლიტიკები ვარიანტებს ხსნის.

Backup-ები და განახლებები#

DLE ადმინისტრაციულ პანელში ბაზის backup-ის ხელსაწყოს შეიცავს, რომელიც dump-ებს backup/ დირექტორიაში წერს. ის სასარგებლოა და თავისთავად საკმარისი არ არის: dump-ები იმავე დისკზეა, სადაც საიტი, და არ შეიცავს uploads/-ს, შაბლონებს ან კონფიგურაციას. ნამდვილი backup არის ბაზა პლუს ფაილების მთელი ხე, სხვაგან შენახული და დროდადრო აღდგენილი, რომ დამტკიცდეს, რომ მუშაობს - backup-ები, რომლებიც მართლა აღდგება ამ ბოლო ნაბიჯის არგუმენტია.

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

1. აიღე ფაილებისა და ბაზის სრული backup და შეამოწმე, რომ დასრულდა.
2. ჩაინიშნე ყოველი ფაილი, რომელიც ხელით შეცვალე - შაბლონები, მოდულისთვის შესწორებული core ფაილები. განახლება core ფაილებს გადაწერს, და შენი ცვლილებები მათთან ერთად მიდის.
3. შეამოწმე, უჭერს თუ არა მესამე მხარის ყოველი მოდული ახალ ვერსიას მხარს. მოდულები, რომლებიც core ფაილებს ასწორებენ, ჩვეულებრივი მიზეზია, რის გამოც განახლება საიტს ტეხავს.
4. თუ შეგიძლია, ჯერ საიტის ასლი განაახლე; ჰოსტინგზე ორი ბაზის სლოტით staging ასლი საკუთარი ბაზით დამატებით არაფერი ღირს.
5. გაუშვი განახლება, გაასუფთავე cache და შეამოწმე გამოქვეყნება, კომენტარები და შესვლა.

საბაზისო ლიცენზია განახლებებს ერთი წლით მოიცავს. ამის შემდეგ შენი ვერსია ისევ მუშაობს, მაგრამ ახალ გამოშვებებს - უსაფრთხოების შესწორებების ჩათვლით - აღარ იღებ, სანამ არ განაახლებ. ეს DLE-ს გაშვების ღირებულებაში გაითვალისწინე.

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

`install.php` აჩვენებს "Internal Server Error"-ს. აკლია PHP გაფართოება, ოფიციალური FAQ-ის მიხედვით. შეადარე phpinfo() მოთხოვნების სიას.

ბაზასთან კავშირის შეცდომა გადატანის შემდეგ. engine/data/dbconfig.php-ში ჯერ კიდევ ძველი host ან პაროლია.

მთავარი გვერდის გარდა ყველა გვერდი 404-ს აბრუნებს. მეგობრული URL-ები ჩართულია და rewrite წესები აკლია - ტიპური nginx-ზე. თარგმნე წესები ან გამორთე მეგობრული URL-ები.

დამახინჯებული კირილიცა. სიმბოლოების ნაკრების შეუსაბამობა ბაზას, კავშირსა და შაბლონებს შორის, ჩვეულებრივ ძველი windows-1251 საიტის გადატანის შემდეგ.

ადმინისტრაციული პანელი ძველ დომენზე გადამისამართებს. engine/data/config.php-ში საიტის მისამართი დომენის შეცვლის შემდეგ არ განახლებულა.

Redis cache-ის ვარიანტი არაფერს აკეთებს. php-redis გაფართოება ჩატვირთული არ არის, ან მისამართი, პორტი ან პაროლი არასწორია.

FAQ#

შემიძლია DLE უფასოდ გამოვიყენო?

მხოლოდ demo ვერსია, რომელიც 100 სიახლითა და 200 კომენტარით შემოიფარგლება, დაშიფრული კოდი აქვს და არც განახლებებს, არც მხარდაჭერას იღებს. ნამდვილ საიტს თავისი დომენისთვის ფასიანი ლიცენზია სჭირდება. მოერიდე "უფასო სრულ ვერსიებს" ჩამოტვირთვის საიტებიდან; ისინი მეკობრულია და ხშირად backdoor-ით.

მუშაობს DLE nginx-ზე?

დიახ - ოფიციალური მოთხოვნები nginx-ს Apache-სთან ერთად ჩამოთვლის. ერთადერთი განსხვავება მეგობრული URL-ებია, რომელთა წესები Apache-ის .htaccess ფორმატში მოდის და nginx-ისთვის უნდა ითარგმნოს, ან მეგობრული URL-ები უნდა გამოირთოს.

შემიძლია DLE საიტის სხვა დომენზე გადატანა?

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

რომელი PHP ვერსია გამოვიყენო DLE-სთვის?

PHP 8-ის უახლესი გამოშვება, რომელსაც შენი DLE ვერსია და ყოველი დაყენებული მოდული უჭერს მხარს. ოფიციალური მინიმუმი 8.0-ია, რომელიც upstream-ში უკვე მხარდაჭერის გარეშეა; ძველი მოდულები ჩვეულებრივი მიზეზია, რის გამოც საიტი ძველ ვერსიაზე რჩება.

მჭირდება ცალკე cache სერვერი?

საიტების უმეტესობისთვის არა; ფაილური cache ჩაშენებულია და ყველგან მუშაობს. Redis პროტოკოლის cache, როგორიცაა Valkey, დატვირთულ საიტებს ეხმარება დისკისა და ბაზისთვის დატვირთვის მოშორებით, იმ პირობით, რომ ჰოსტინგს php-redis გაფართოება აქვს.