WordPress პლაგინების დამოკიდებულებების მიგრაციის გეგმა

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

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

შექმენით ფუნქციური ინვენტარი

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

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

ინვენტარი ფუნქციის მიხედვით შეავსეთ. „SEO პლაგინი“ ძალიან ფართო აღწერაა. მიუთითეთ კონკრეტული გამოყენება: canonical, sitemap, schema, redirect, მეტა ველი ან სხვა მოქმედება.

დახაზეთ დამოკიდებულებების გრაფი

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

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

WordPress-ის პლაგინების დამოკიდებულებები

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

პლაგინის header-ში Requires Plugins ველი დამოკიდებულებებს slug-ებით აღწერს. ეს ჩანაწერი არ ცვლის ყველა პროექტულ შემოწმებას: ვერსიის შესაბამისობა, კონფიგურაცია, თემა, მონაცემები და გარე სერვისი ცალკე უნდა გაიტესტოს. circular dependency-ის ან დაუდასტურებელი აქტივაციის შემთხვევაში release-ს სტატუსი უნდა შეჩერდეს.

აქტივაციისა და დაბრუნების რიგი

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

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

ლიცენზია და ანგარიშები

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

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

სცენარი: ფორმის პლაგინის ცვლილება

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

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

ფუნქციის შენარჩუნების არჩევანი

დამოკიდებულებების სიის საზღვრები

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

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

ტექნიკური მიგრაციის გაგრძელება

• ძველი საიტის სამაშველო ინვენტარი
• კონტენტის აუდიტი
• staging და cutover
• ფორმებისა და მოთხოვნების მიგრაცია
• ადმინისტრატორის უფლებები
• მრავალენოვანი საიტის მიგრაცია
• aiWEB პროექტის განხილვა

<li><a href="https://make.wordpress.org/core/2024/03/05/introducing-plugin-dependencies-in-wordpress-6-5/">ოფიციალური ჩანაწერი: პლაგინების დამოკიდებულებები</a></li>
<li><a href="https://developer.wordpress.org/plugins/plugin-basics/header-requirements/">ოფიციალური დოკუმენტაცია: პლაგინის მოთხოვნები</a></li>
<li><a href="https://developer.wordpress.org/plugins/users/roles-and-capabilities/">ოფიციალური დოკუმენტაცია: მომხმარებლის როლები</a></li></ul>

პასუხები პლაგინების გეგმაზე

რას ნიშნავს Requires Plugins?

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

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

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

ყველა პლაგინი უნდა გადავიტანოთ?

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

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

შემდეგი ნაბიჯი: ჩამოწერეთ რომელი პლაგინი ამუშავებს თითოეულ ბიზნეს-ფუნქციას, მიუთითეთ ლიცენზიის მფლობელი და დაგეგმეთ მიგრაციის ფარგლები aiWEB-ის გუნდთან.