WordPress-ის უსაფრთხოების განახლება 7.1.4 გამოვიდა 2026 წლის 28 ოქტომბერს. WordPress მის სწრაფად დაყენებას გვირჩევს, რადგან გამოშვება საიტის პროგრამულ უზრუნველყოფაში უსაფრთხოების პრობლემებს ასწორებს. თუ თქვენი ბიზნესი WordPress-ს იყენებს, სთხოვეთ მის მომსახურე პირს, დაადასტუროს დაყენებული ვერსია, მოაწყოს შესაბამისი განახლება და შემდეგ შეამოწმოს, კვლავ შეუძლიათ თუ არა მომხმარებლებს მოთხოვნის გაგზავნა ან შეძენა.
ეს არსებული საიტის ტექნიკური მომსახურების ამოცანაა. განცხადება არ გეუბნებათ, განახლდა თუ არა თქვენი ინსტალაცია ან მოხდა თუ არა მასზე თავდასხმა. ამ კითხვებს პასუხი ამ ინსტალაციიდან მიღებული მტკიცებულებით უნდა გაეცეს.
რას ცვლის WordPress-ის უსაფრთხოების განახლება
გამოშვება თავად WordPress-ში არსებულ პრობლემებს ასწორებს. დეტალურ დოკუმენტაციაში ჩამოთვლილია შენახულ სკრიპტებთან, კონტენტის ნებართვებსა და განახლების პროცესთან დაკავშირებული პრობლემები, სხვადასხვა მიგნებისთვის განსხვავებული წინაპირობებით. შენახული სკრიპტი არის არასასურველი კოდი, რომელიც კონტენტში ინახება და მოგვიანებით ბრაუზერში სრულდება; ნებართვის პირობები მნიშვნელოვანია იმის ასახსნელად, თუ ვის შეეძლო მისი დამატება.
Patchstack-ის ტექნიკური ანალიზის თანახმად, ჩამოთვლილი პრობლემების უმეტესობა მოითხოვს WordPress-ის ანგარიშს, რომელსაც კონტენტის შექმნის ან რედაქტირების უფლება აქვს. ის ასევე აღწერს სისუსტეს, რომელმაც კონკრეტულ პირობებში თავდამსხმელს განახლების დროს კოდის გაშვების საშუალება შეიძლება მისცეს. მომსახურე პირს გამოშვების შეტყობინებას გადავცემდით და ვთხოვდით, დაედასტურებინა დაყენებული ვერსია და ეცნობებინა განახლების ნებისმიერი შეცდომა. მიგნებები არ ამტკიცებს, რომ ყველა ვიზიტორს ყველა პრობლემის გამოყენება შეუძლია.
ნამდვილად განახლდა თქვენი საიტი?
დაადასტურეთ ვერსია იმ ინსტალაციაში, რომელიც თქვენი ბიზნესის დომენს ემსახურება. WordPress შესაბამისი საიტებისთვის ფონურ უსაფრთხოების განახლებებს აღწერს, თუმცა მათზე კონფიგურაციამ და ჰოსტინგის პირობებმა შეიძლება იმოქმედოს. შეამოწმეთ დაყენებული ვერსია, რათა დაადგინოთ, მიიღო თუ არა ამ ინსტალაციამ განახლება. ფონური განახლების შესაბამისობა და პარამეტრები დაგეგმილ პროცესს აღწერს, მაგრამ მის დასრულებას არ ამტკიცებს.
ჰოსტს ან მომსახურე პირს ჰკითხეთ, მათი დასტური თავად WordPress-ის დაყენებულ განახლებას ეხება თუ ჰოსტინგის დამცავ წესს. Pantheon-ის გამოშვების შენიშვნა სასარგებლო მაგალითია: მასში ნათქვამია, რომ პლატფორმამ ზოგიერთი გარე ბოროტად გამოყენების წინააღმდეგ დამცავი წესები დაამატა, თუმცა მომხმარებლებს მაინც სთხოვს საიტების განახლებას. ეს განცხადება Pantheon-ს ეხება და სხვა ჰოსტის შესახებ მტკიცებულება არ არის.
რა უნდა სთხოვოთ მომსახურე პირს
სთხოვეთ მომსახურე პირს, ჩაიწეროს დაყენებული ვერსია და შეამოწმოს მომხმარებლის მთავარი მოქმედება საიტზე. ქვემოთ მოცემულ ნაბიჯებს გამოვიყენებდით იმის შესათანხმებლად, თუ რას გააკეთებს ის და რას შეამოწმებთ შემდეგ თქვენ. ეს შემოწმებები არ ნიშნავს, რომ ცნობილია ამ განახლების მიერ ფორმების ან გადახდების დაზიანება.
- დაასახელეთ საიტი და მომსახურე პირი. გაუგზავნეთ ბიზნესის დომენი და ჰკითხეთ, ვინ დააყენებს განახლებას. თუ მომსახურებას ჰოსტი მართავს, გამოიყენეთ მისი დამკვიდრებული მხარდაჭერის ან განთავსების პროცესი. ჩაიწერეთ ვერსია ცვლილებამდე და ვერსია, რომლის დაყენებაც იგეგმება.
- განსაზღვრეთ გამოსადეგი სარეზერვო ასლი. WordPress-ის სარეზერვო ასლების სახელმძღვანელოს თანახმად, ჩვეულებრივ, სრული აღდგენისთვის მონაცემთა ბაზაც და ფაილებიც საჭიროა. ჰკითხეთ, როდის დასრულდა ასლის შექმნა, სად ინახება და ვის შეუძლია აღდგენა. მოქმედი მაღაზიის შემთხვევაში ჰკითხეთ, როგორ დამუშავდება აღდგენისას ასლის შექმნის შემდეგ მიღებული შეკვეთები. განახლებები და სარეზერვო ასლები ერთად უნდა განიხილებოდეს საიტის ტექნიკური მომსახურებისას.
- დააყენეთ დოკუმენტირებული განახლება. WordPress ჩვეულებრივ გზად მიუთითებს: მართვის პანელი > განახლებები > განახლება ახლა. უფლებამოსილმა მომსახურე პირმა ჰოსტინგის გარემოს შესაბამისი გზა უნდა გამოიყენოს. თუ ეკრანზე შეცდომა გამოჩნდა ან უცნობი ავტორიზაციის მონაცემები მოითხოვა, სერვერის პარამეტრების გამოცნობის ნაცვლად ზუსტი შეტყობინება ამ პირს გაუგზავნეთ.
- დაადასტურეთ დაყენებული ვერსია და შეამოწმეთ მოთხოვნის ან შეძენის გზა. მოითხოვეთ WordPress-ის საბოლოო ვერსია. შემდეგ გაგზავნეთ შეთანხმებული სატესტო მოთხოვნა და დაადასტურეთ, რომ ის მოსალოდნელ საფოსტო ყუთში ან მომხმარებლის ჩანაწერში მივიდა. გვერდი, რომელიც ფორმის გაგზავნას ადასტურებს, მიწოდების ეტაპს შეუმოწმებელს ტოვებს; ამ გადაცემას ხსნის ჩვენი გზამკვლევი საიტსა და გაყიდვებს შორის დაკარგული მოთხოვნების შესახებ. თუ საიტი ყიდის, უფლებამოსილ ოპერატორს სთხოვეთ, მიღებული უსაფრთხო ტესტირების პროცესით შეამოწმოს შეკვეთის გაფორმება უნებლიე ჩამოჭრის გარეშე.
- შეინახეთ დასრულების მოკლე ჩანაწერი. ჩაიწერეთ საიტი, საბოლოო ვერსია, განახლების დრო, სარეზერვო ასლის მითითება, პასუხისმგებელი პირი, ტესტის შედეგი და ნებისმიერი ღია გამონაკლისი. თუ ფორმა მონაცემებს მომხმარებელთა სისტემას გადასცემს, შემოწმებაში დანიშნულების ჩანაწერიც შეიტანეთ, როგორც ფორმებისა და CRM-ის ინტეგრაციის ნაწილი.
თუ საიტი WordPress-ის ძველ ვერსიას იყენებს
სამიზნე ვერსიის კითხვამდე მომსახურე პირს არსებული ვერსია მიაწოდეთ. WordPress-ის გამოშვების დეტალურ გვერდზე ჩამოთვლილია ძველი ვერსიების შესწორებები, მათ შორის 7.0.8 და 6.9.11. იქვე ნათქვამია, რომ აქტიურად მხოლოდ უახლესი ვერსიაა მხარდაჭერილი. ძველი ვერსიისთვის უსაფრთხოების შესწორების მიღება და მიმდინარე, აქტიურად მხარდაჭერილ ვერსიაზე გადასვლა სხვადასხვა გადაწყვეტილებაა.
სთხოვეთ მომსახურე პირს, დაადასტუროს, რომელი უსაფრთხოების განახლება შეესაბამება დაყენებულ ვერსიას და განსაზღვროს მიმდინარე ვერსიაზე გადასასვლელად საჭირო სამუშაო. ძველი ვერსიის შესწორება შემდგომ სრულ მხარდაჭერას არ ჰპირდება.
რა მოხდება, თუ განახლება ვერ სრულდება ან საიტი კომპრომეტირებული ჩანს?
თუ განახლება ვერ სრულდება, ზუსტი შეცდომა და დრო მომსახურე პირს ან ჰოსტს გაუგზავნეთ. საეჭვო ცვლილებები ცალკე გამოძიებას საჭიროებს: გატეხილი საიტის შესახებ WordPress-ის გზამკვლევი პრობლემისა და მისი დროის დოკუმენტირებით იწყება. მხოლოდ განახლების დაყენება ვერ უპასუხებს, როგორ გაჩნდა უცნობი ადმინისტრატორის ანგარიში ან შეეხო თუ არა შემთხვევა მომხმარებელთა მონაცემებს.
ამ გამონაკლისებს დასრულების ჩანაწერში ხილულად დავტოვებდით.
