WordPress მომსახურების რეჟიმში გაიჭედა: განახლების შეცდომები

თუ საიტი წერს "Briefly unavailable for scheduled maintenance. Check back in a minute." და ამას ათ წუთზე მეტია წერს, განახლება შეწყდა და WordPress-ის ძირეულ საქაღალდეში დატოვა ფაილი .maintenance. წაშალე ფაილ მენეჯერით ან SFTP-ით და საიტი დაბრუნდება. ეს სიმპტომს მკურნალობს. მიზეზი ჩვეულებრივ ოთხიდან ერთ-ერთია: განახლების შუაში PHP-ის დროის ან მეხსიერების ლიმიტი ამოიწურა, WordPress-ს რომელიმე საქაღალდეში ჩაწერის უფლება არ ჰქონდა, დისკი გაივსო, ან ბრაუზერის ჩანართი უხერხულ მომენტში დაიხურა. სანამ არ იცი, რომელია, შემდეგი განახლებაც ასევე დასრულდება.

ეს პოსტი მთელ ოჯახს მოიცავს: გაჭედილ მომსახურების გვერდს, "Another update is currently in progress"-ს, "Could not copy file"-ს, FTP მონაცემების მოთხოვნას, plugin-ის განახლებას, რომლის შემდეგაც საიტი დაეცა, და ხელით განახლებას, როცა ადმინ-პანელი არ გეხმარება. ყველაფერი ფაილ მენეჯერით ან SFTP-ით კეთდება, და ყოველ ნაწილში წერია, რა შეამოწმო, სანამ რამეს შეცვლი.

რას აკეთებს WordPress განახლებისას#

განახლება ერთი ოპერაცია არ არის და ეტაპების თანმიმდევრობა გიჩვენებს, სად მოხდა წარუმატებლობა. როცა ადმინ-პანელიდან ბირთვს, plugin-ს ან თემას ანახლებ, WordPress დაახლოებით ამას აკეთებს:

1. ჩამოტვირთავს zip-ს დროებით ადგილას და ამოწმებს მას.
2. საიტის ძირეულ საქაღალდეში ჩაწერს ფაილს .maintenance. ამ მომენტიდან ვიზიტორები მომსახურების გვერდს ხედავენ.
3. არქივს გახსნის wp-content/upgrade/-ში.
4. ახალ ფაილებს ძველებზე გადააკოპირებს, საქაღალდე-საქაღალდე.
5. წაშლის გახსნილ ფაილებს და ფაილს .maintenance.
6. ბირთვის განახლებისას ბაზის განახლებას გაუშვებს მომდევნო ჯერზე, როცა ადმინისტრატორი პანელს გახსნის.

ეტაპები 2-დან 5-მდე სახიფათო ფანჯარაა და ჯანსაღ ჰოსტინგზე რამდენიმე წამი გრძელდება. ყველაფერი, რაც ამ ფანჯარაში PHP-ს გააჩერებს, საიტს ნახევარ მდგომარეობაში ტოვებს: მომსახურების ფაილი რჩება, ზოგი ფაილი ახალია და ზოგი ძველი, ან wp-content/upgrade/-ში ნარჩენი რჩება. WordPress ისეა აგებული, რომ უმეტესი ასეთი შემთხვევიდან გამოვიდეს, ამიტომ მომსახურების გვერდი თავისით ამოიწურება, მაგრამ იმ მოთხოვნას ვერ გადაარჩენს, რომელსაც დასრულების საშუალება არ მისცეს.

ფაილი .maintenance პატარაა. მასში დროის ნიშნულია:

<?php $upgrading = 1761000000; ?>

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

როგორ გამოვიყვანოთ საიტი მომსახურების რეჟიმიდან#

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

1. გახსენი ფაილ მენეჯერი ან SFTP კლიენტი და გადადი საქაღალდეში, სადაც wp-config.php დევს. ეს არის WordPress-ის ძირეული საქაღალდე.
2. ჩართე დამალული ფაილების ჩვენება. FileZilla-ში ეს არის Server, Force showing hidden files. WinSCP-ში - Options, Preferences, Panels, Show hidden files.
3. წაშალე .maintenance.
4. გადატვირთე საიტი პირად ფანჯარაში, რომ მომსახურების გვერდის შენახულმა ასლმა არ გაგაბრუოს.

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

თუ ფაილი აღარ არის, მაგრამ მომსახურების შეტყობინება მაინც ჩანს, გვერდი cache-იდან მოდის. ჩვეულებრივი წყაროებია: caching plugin, რომელმაც გვერდი შეინახა, სანამ .maintenance არსებობდა, სერვერის მხარეს გვერდების cache და CDN. გაასუფთავე plugin-ის cache მის პარამეტრების გვერდზე, ხოლო თუ პანელი არ იხსნება, წაშალე wp-content/cache/-ის შიგთავსი. თუ საიტის წინ CDN ან proxy დგას, ისიც გაასუფთავე - Cloudflare საიტებისა და თამაშის სერვერებისთვის განმარტავს, მისი რომელი ფენები ინახავს HTML-ს და რომელი არა.

მეორე, უფრო იშვიათი მიზეზია საკუთარი მომსახურების გვერდი. WordPress ჩვეულებრივი შეტყობინების ნაცვლად აჩვენებს wp-content/maintenance.php-ს, თუ ეს ფაილი არსებობს. plugin-ები, რომლებსაც "მომსახურების რეჟიმი" ან "მალე გაიხსნება" გვერდი აქვთ, ხშირად სწორედ მას ქმნიან. თუ ეკრანზე სტანდარტული წინადადება არ არის, მოძებნე ეს ფაილი ან ჯერ ჩართული მომსახურების plugin.

"Another update is currently in progress"#

ბირთვის განმაახლებელი იკავებს დაბლოკვას, რომ ბრაუზერის ორმა ჩანართმა ან ორმა ადმინისტრატორმა ერთდროულად ვერ გაუშვას. დაბლოკვა ბაზის ჩანაწერია, wp_options ცხრილში, სახელით core_updater.lock. განახლების დასრულებისას ის თავისუფლდება. თუ განახლების შუაში PHP მოკვდა, ჩანაწერი რჩება და მომდევნო 15 წუთის განმავლობაში WordPress ბირთვის ახალ განახლებას არ იწყებს და წერს "Another update is currently in progress".

პატიოსანი გამოსწორება ისაა, რომ თხუთმეტი წუთი დაელოდო და ისევ სცადო. დაბლოკვას ვადა აქვს და მისი გასვლის შემდეგ WordPress ძველ ჩანაწერს უგულებელყოფს. თუ ლოდინი არ შეგიძლია ან გინდა დარწმუნდე, რომ პრობლემა ეს ჩანაწერია, წაშალე. RE:NODE-ზე პანელის ღილაკი "Open in phpMyAdmin" ერთჯერადი ტოკენით შეგიყვანს, რომელიც 60 წამში იწურება, ამიტომ პაროლის აკრეფა არ გჭირდება. გაუშვი ეს SQL ჩანართში და ცხრილების პრეფიქსი შეცვალე, თუ ის wp_ არ არის:

SELECT option_id, option_name, option_valueFROM wp_optionsWHERE option_name = 'core_updater.lock';DELETE FROM wp_optionsWHERE option_name = 'core_updater.lock';

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

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

რატომ ვერ სრულდება განახლებები: მიზეზები ალბათობის მიხედვით#

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

დისკის ადგილი. განახლებას ერთდროულად ესაჭიროება ადგილი zip-ისთვის, გახსნილი ასლისთვის და ახალი ფაილებისთვის, ამიტომ ბირთვის განახლებამ შეიძლება მცირე ხნით ჩანაცვლებადის სამჯერ მეტი ადგილი მოითხოვოს. პატარა გეგმაზე, დიდი ატვირთვების საქაღალდით, ეს წარუმატებლობისთვის საკმარისია. შეხედე დისკის გრაფიკს პანელის კონსოლში, რომელიც დისკს ლიმიტის მიმართ აჩვენებს, და გაათავისუფლე ზედმეტი: plugin-ების ძველი zip-ები, wp-content/upgrade/-ის შიგთავსი, cache-ის საქაღალდეები და backup plugin-ების არქივები, რომლებიც wp-content-ის შიგნით დარჩა. backup plugin, რომელიც არქივებს საიტის გვერდით წერს, WordPress-ის პატარა დისკის შევსების ყველაზე გავრცელებული გზაა.

ლიმიტები. ბირთვის განახლება ათასობით პატარა ფაილს ხსნის და აკოპირებს, რაც სწრაფ საცავზე რამდენიმე წამს გრძელდება, დატვირთულ მანქანაზე კი გაცილებით მეტს. თუ max_execution_time ძალიან დაბალია, ან memory_limit იმდენად მცირეა, რომ გახსნისას მას აწყდები, PHP პროცესს კოპირების შუაში აჩერებს. რომელი მნიშვნელობები შეამოწმო და როგორ გაზარდო, წერია პოსტში PHP-ის პარამეტრები, რომლებიც WordPress-ისთვის მნიშვნელოვანია. ხელის წესი: memory_limit-ისთვის 256M და max_execution_time-ისთვის მინიმუმ 60 წამი განახლებისთვის გონივრული ქვედა ზღვარია. რამდენი RAM სჭირდება WordPress-ს მეორე მხარეს ფარავს: ლიმიტი, რომელსაც PHP უშვებს, მაგრამ გეგმას ვერ უზრუნველყოფს.

გამავალი კავშირები. სერვერი განახლებას wordpress.org-დან ჩამოტვირთავს, ამიტომ გამავალი HTTPS სჭირდება. თუ DNS ვერ მუშაობს ან firewall მოთხოვნას ბლოკავს, ჩამოტვირთვის შეცდომას ნახავ, სანამ რომელიმე ფაილს შეეხებიან. ეს ყველაზე უსაფრთხო წარუმატებლობაა, რადგან არაფერი შეცვლილა. სცადე მოგვიანებით, და თუ გრძელდება, გახსენი Tools, Site Health და წაიკითხე "WordPress.org REST API" და loopback შემოწმებები.

ფაილების უფლებები და FTP მონაცემების მოთხოვნა#

ეს წარუმატებლობა ხალხს ყველაზე მეტად ერევა. აჭერ Update-ს და WordPress აჩვენებს ფორმას FTP ან SFTP მონაცემებისთვის, ან სრულდება შეცდომით "Could not create directory". არცერთი ნიშნავს, რომ პაროლი არასწორია. ეს ნიშნავს, რომ WordPress-მა შეამოწმა, შეუძლია თუ არა საკუთარ საქაღალდეებში ჩაწერა, და დაასკვნა, რომ არ შეუძლია.

WordPress ფაილების ჩაწერის მეთოდს ირჩევს. ნაგულისხმევად ის wp-content-ში ქმნის პატარა დროებით ფაილს და მის მფლობელს ადარებს იქ უკვე არსებული ფაილების მფლობელს. თუ ემთხვევა, პირდაპირ წერს. თუ განსხვავდება, ფიქრობს, რომ PHP საიტის მფლობელი არ არის, და FTP მონაცემებს ითხოვს. ასე რომ, მოთხოვნა სინამდვილეში შერეული მფლობელების სიმპტომია: ზოგი ფაილი ერთმა მომხმარებელმა შექმნა, ჩვეულებრივ იმან, ვინც SFTP-ით ატვირთა ან არქივიდან აღადგინა, PHP კი სხვის სახელით მუშაობს.

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

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

სადაც ბრძანებების გაშვება შეგიძლია, გამოსწორება ორი ხაზია, WordPress-ის ძირეული საქაღალდიდან:

$ find . -type d -exec chmod 755 {} +$ find . -type f -exec chmod 644 {} +

პანელიან ჰოსტინგზე მფლობელის შეცვლა ხშირად საერთოდ არ შეიძლება და იშვიათად გჭირდება. ფაილ მენეჯერი და SFTP იმავე ფაილებზე მუშაობენ, რომლებსაც PHP გასცემს, ამიტომ მათით შექმნილი ფაილები ჩვეულებრივ საიტისთვის ჩასაწერია. პრობლემა ჩვეულებრივ აღდგენის, სხვა ხელსაწყოთი გახსნილი არქივის ან მიგრაციის შემდეგ ჩნდება, რომელმაც ძველი მფლობელი გადმოიტანა. მაშინ სწორი გზა ticket-ია, რადგან გამოსწორება ჰოსტინგის მხარესაა. SFTP: permission denied ფაილების რედაქტირებისას გიჩვენებს, როგორ გაარჩიო რეჟიმის პრობლემა მფლობელის პრობლემისგან.

თუ იცი, რომ საიტის ფაილები ჩასაწერია და WordPress მაინც კითხულობს, შეგიძლია ვარაუდი აუკრძალო wp-config.php-ში ხაზის დამატებით, კომენტარის "That's all, stop editing" ზემოთ:

define( 'FS_METHOD', 'direct' );

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

ნახევრად დასრულებული განახლების შეკეთება#

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

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

2. გაასუფთავე დროებითი საქაღალდეები. WordPress განახლებებს wp-content/upgrade/-ში ხსნის. ჯანსაღ საიტზე ეს საქაღალდე ცარიელია. რაც შიგნითაა, წარუმატებელი გაშვების ნამსხვრევებია, ხოლო დარჩენილი საქაღალდე "Destination folder already exists"-ის მიზეზია. წაშალე შიგთავსი და არა თვითონ საქაღალდე. WordPress 6.3-იდან plugin-ებისა და თემების განახლებისას ძველი ვერსია ასევე ინახება wp-content/upgrade-temp-backup/-ში, რომ წარუმატებელი განახლება უკან დაბრუნდეს. თუ იქ არის იმ plugin-ის საქაღალდე, რომელსაც ანახლებდი, და მისი სამუშაო საქაღალდე გატეხილია ან აკლია, ეს ასლი სამუშაო ვერსიამდე დაბრუნების ყველაზე სწრაფი გზაა: გადაიტანე wp-content/plugins/-ში.

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

თუ საიტი ახლა კრიტიკულ შეცდომას აჩვენებს, განახლება დასრულდა, მაგრამ ახალი კოდი რაღაცასთან არ მუშაობს შენს საიტზე. ეს სხვა პრობლემაა სხვა ლოგით. გადადი პოსტზე WordPress-ის თეთრი ეკრანი და 500 შეცდომა, ჩართე WP_DEBUG_LOG და წაიკითხე debug.log-ის ბოლო ხაზი. plugin, რომელიც განახლების შემდეგ ვარდება, გამოირთვება wp-content/plugins/-ში მისი საქაღალდის გადარქმევით და საიტი მაშინვე ბრუნდება; მისი პარამეტრები ბაზაში რჩება.

WordPress-ის განახლება ხელით#

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

1. გააკეთე ფაილებისა და ბაზის backup.
2. ჩამოტვირთე უახლესი zip wordpress.org-იდან და გახსენი შენს კომპიუტერში, ან ატვირთე zip და გახსენი ადგილზე ფაილ მენეჯერით, რომელიც არქივებს იქვე ხსნის, სადაც დევს.
3. თუ პანელი მიუწვდომელია, წინასწარ არაფერი გამორთო. თუ ხელმისაწვდომია, შეგიძლია ჯერ caching plugin-ები გამორთო.
4. სერვერზე წაშალე საქაღალდეები wp-admin და wp-includes. მათში მხოლოდ ბირთვის ფაილებია, შენი შიგთავსი იქ არ არის.
5. ატვირთე ახალი wp-admin და wp-includes.
6. ახალი პაკეტის ძირიდან ცალკეული ფაილები ძველებზე ატვირთე: index.php, wp-login.php, wp-settings.php და დანარჩენი. არ გადააწერო wp-config.php და არ ჩაანაცვლო wp-content.
7. wp-content-ის შიგნით შეგიძლია განაახლო ნაგულისხმევი თემები და თან მოყოლილი plugin-ები. არასდროს წაშალო შენი საკუთარი საქაღალდეები plugins, themes ან uploads.
8. ბრაუზერში გახსენი /wp-admin/upgrade.php. თუ ბაზის განახლება სჭირდება, WordPress გააკეთებს და გეტყვის.
9. წაშალე .maintenance, თუ ის ჯერ კიდევ არის, გაასუფთავე cache-ები და გამოსცადე მთავარი გვერდი, შესვლა და ერთი პოსტი.

wp-admin და wp-includes გადაწერის ნაცვლად იმიტომ იშლება, რომ ახალი ვერსია ფაილებს არა მარტო ამატებს, არამედ აცილებს. გადაწერა წაშლილ ფაილებს ტოვებს და ძველი ფაილები შეცდომით შეიძლება ჩაიტვირთოს. ამ ორი საქაღალდის წაშლა უსაფრთხოა, რადგან შენი არაფერი არ არის მათში.

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

$ wp core version$ wp core download --force --skip-content$ wp core update-db$ wp core verify-checksums

--skip-content wp-content-ს ხელს არ ახლებს. verify-checksums ბირთვის ფაილებს ოფიციალურებს ადარებს და ჩამოთვლის შეცვლილს ან დაკარგულს, რაც სწრაფი გზაა დასარწმუნებლად, რომ ნახევრად დასრულებული განახლება ახლა მთლიანია. plugin-ების ფაილებს ცალკე ამოწმებს wp plugin verify-checksums --all. WP-CLI ყველა გეგმაზე არ არის, ამიტომ ბაზისურ გზად ფაილ მენეჯერი ჩათვალე, ხოლო რას გაძლევს RE:NODE-ის პანელი ამისთვის, ამ პოსტის ბოლო ნაწილშია.

plugin-ებისა და თემების განახლებები, რომლებიც საიტს არღვევს#

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

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

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

წინასწარ იცოდე გამოსავალი. plugin, რომელიც საიტს არღვევს, გამოირთვება მისი საქაღალდის გადარქმევით. საიტის გასაშვებად გადაარქვი wp-content/plugins/name სახელს name.off და გვერდი გადატვირთე. თუ არ იცი, რომელი plugin-ია, გადაარქვი მთელი plugins საქაღალდე plugins.off-ად, რაც ყველას ერთდროულად გამორთავს. WordPress შეამჩნევს, ბაზაში გამორთავს მათ და პანელს ისევ აჩვენებს. საქაღალდეს სახელი დაუბრუნე და plugin-ები სათითაოდ ჩართე, რომ დამნაშავე იპოვო. plugin-ის წინა ვერსიაზე დასაბრუნებლად ჩამოტვირთე ის plugin-ის გვერდიდან wordpress.org-ზე, Advanced View, Previous Versions-ში.

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

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

მნიშვნელობებია true (ყველა გამოშვება), false (არცერთი) და 'minor'. მცირე განახლებები ჩართული დატოვე. plugin-ების ავტომატური განახლება ცალკეული plugin-ის გადამრთველია Plugins ეკრანზე და უკეთესია მათთვის დარჩეს, რომლებსაც ერთი დღით დაკარგავდი და ვერავინ შეამჩნევდა. ყველაფერი, რაც გადახდებს, ფორმებს ან თემის განლაგებას ეხება, უნდა განაახლოს ადამიანმა, რომელიც შემდეგ საიტს შეხედავს.

როგორ ავიცილოთ შემდეგი წარუმატებელი განახლება#

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

• შეინახე რეზერვი. დისკზე თავისუფალი მინიმუმ ბირთვისა და შენი უდიდესი plugin-ის ზომის ორმაგი და memory_limit 256M ან მეტი.
• გქონდეს backup, რომელიც აღგიდგენია. არა უბრალოდ გაკეთებული. backup, რომელიც არასდროს აღგიდგენია, ჰიპოთეზაა. Backup-ები, რომლებიც ნამდვილად აღდგება განმარტავს, როგორ შეამოწმო ის ცოცხალი საიტის რისკის გარეშე.
• განაახლე, როცა მშვიდია, და პირველი რამდენიმე წუთი უყურე. ნახევრად დასრულებული განახლებების უმეტესობას მაშინვე ამჩნევს ის, ვინც გაუშვა.
• backup განახლებამდე დაგეგმე. განახლების ჩვეულებრივ ფანჯრამდე ერთი საათით ადრე დაგეგმილი backup ნიშნავს, რომ აღდგენის წერტილი არსებობს, თუნდაც დაგავიწყდეს. ნიმუშს გიჩვენებს დაგეგმილი ამოცანები, რომლებიც ღირს რომ გქონდეს.
• ჩანართს ნუ დახურავ. განახლება შენი მოთხოვნის შიგნით მიმდინარეობს. ბრაუზერის დახურვა გახსნისას PHP-ს ყოველთვის არ აჩერებს, მაგრამ გაჭედილი .maintenance ფაილის მიღების კლასიკური გზაა.
• ფაილების სტრუქტურა სუფთად შეინახე. backup-ები, ექსპორტები და ძველი zip-ები wp-content-ში არ ეკუთვნის. ისინი დისკს ავსებს და მთელ მსოფლიოს ეძლევა, თუ გზა მარტივად გამოსაცნობია.

რას გაძლევს RE:NODE-ის პანელი ამისთვის#

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

RE:NODE-ზე WordPress-ის ხაზი WordPress-ს პირველ გაშვებისას აყენებს, wp-config.php კი უკვე ჩაწერილია საკუთარი MySQL ბაზისთვის, ამიტომ ბაზის მონაცემები თავიდანვე სწორია. ფაილ მენეჯერს აქვს რედაქტორი ბრაუზერში, იღებს გადმოთრეულ ფაილებს და საქაღალდეების ატვირთვას და არქივებს ადგილზე ხსნის, ამიტომ ხელით განახლება ერთი zip-ის ატვირთვასა და გახსნაზე დადის. SFTP ყველა სერვერზეა, მონაცემებით თითო სერვერზე ცალკე. კონსოლის გრაფიკები მეხსიერებას, CPU-ს და დისკს გეგმის ლიმიტების მიმართ აჩვენებს, ამიტომ განახლებისთვის ადგილის უკმარისობა დაწყებამდე ჩანს. ბაზის სლოტი პანელიდან phpMyAdmin-ში იხსნება, და სწორედ ასე წაშლი ჩანაწერს core_updater.lock.

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

FAQ#

რამდენ ხანს უნდა დარჩეს WordPress მომსახურების რეჟიმში?

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

უსაფრთხოა თუ არა .maintenance ფაილის წაშლა?

დიახ. მასში მხოლოდ დროის ნიშნულია და WordPress ყოველ განახლებაზე თავიდან ქმნის. რისკი წაშლაში კი არა, იმ ვარაუდშია, რომ განახლება დასრულდა. წაშლის შემდეგ შეამოწმე Dashboard, Updates, და თუ იგივე განახლება ისევ შემოგთავაზეს, გაასწორე, სანამ გაიმეორებ.

დავკარგავ თუ არა შიგთავსს, თუ განახლება ვერ შესრულდა?

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

რატომ მთხოვს WordPress FTP მონაცემებს, როცა განახლებას ვაჭერ?

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

შემიძლია plugin-ები სატესტო ასლზე განვაახლო და შედეგი მერე გადავიტანო?

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

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

ახალი კოდი კონფლიქტშია შენს თემასთან, სხვა plugin-თან ან PHP-ის ვერსიასთან. გადაარქვი plugin-ის საქაღალდეს სახელი, რომ გამოირთოს, საიტი აღადგინე და წაიკითხე wp-content/debug.log, რომ ნახო, რომელი ფაილი და რატომ ჩავარდა. შემდეგ plugin-ის ცვლილებების სიაში შეამოწმე, ხომ არ გაჩნდა PHP-ის ახალი მოთხოვნა.