WordPress-იდან გადასვლის შემდეგ ადმინისტრატორისა და რედაქტორის სამუშაო პროცესი

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

განსაზღვრეთ რედაქტირების სრული გზა

დაიწყეთ ერთი რეალური დავალებით და არა ზოგადი ფრაზით, მაგალითად „გვერდის მართვა“. აღწერეთ რა ხდება, როცა გუნდი აქვეყნებს ახალი სერვისის გვერდს:

1. რედაქტორი ქმნის ან ხსნის გვერდს და ამატებს ტექსტს, სურათს, ბმულს და საკონტაქტო მოქმედებას;
2. პასუხისმგებელი პირი ამოწმებს სათაურს, ფაქტებს, ენის ვერსიას, მობილურ ხედვასა და ფორმის გზას;
3. preview-ში შედარებულია რედაქტირებული გვერდი მოქმედ საიტთან და დამტკიცებულ მასალასთან;
4. გამოქვეყნების შემდეგ ხდება URL-ის, მეტა-მონაცემების, შიდა ბმულისა და შემოსული მოთხოვნის კონტროლირებული ტესტი.

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

როლები და წვდომები

WordPress-ის დოკუმენტაციაში აღწერილია 6 წინასწარ განსაზღვრული როლი: Super Admin, Administrator, Editor, Author, Contributor და Subscriber. Super Admin პრაქტიკულად Multisite ქსელის მართვას უკავშირდება, ამიტომ ერთიანი ბიზნეს-საიტის როლები ცალკე შეაფასეთ. თითოეულს განსხვავებული შესაძლებლობები აქვს. ახალ სისტემაში იგივე სახელების კოპირება აუცილებელი არ არის, მაგრამ საჭიროა იგივე პრინციპის შენარჩუნება: მომხმარებელს მიეცეს მხოლოდ ის მოქმედებები, რომლებიც მის სამუშაოს სჭირდება.

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

Preview და დამტკიცება

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

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

კონტენტის მოდელი და API

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

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

სცენარი: მარკეტინგის გუნდის ახალი გვერდი

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

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

რედაქტირების გარემოების არჩევანი

გადაცემის დოკუმენტი

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

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

რა აფერხებს რედაქტორს

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

რედაქტორის workflow-ის საზღვრები

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

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

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

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

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

<li><a href="https://developer.wordpress.org/plugins/users/roles-and-capabilities/">ოფიციალური დოკუმენტაცია: მომხმარებლის როლები</a></li>
<li><a href="https://wordpress.org/documentation/article/how-to-use-the-preview-function/">ოფიციალური დოკუმენტაცია: წინასწარი გადახედვა</a></li>
<li><a href="https://developer.wordpress.org/rest-api/">ოფიციალური დოკუმენტაცია: პროგრამული ინტერფეისი</a></li></ul>

კითხვები ადმინისტრატორსა და რედაქტორს

უნდა დარჩეს თუ არა WordPress რედაქტორისთვის?

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

რა განსხვავებაა preview-სა და staging-ს შორის?

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

რამდენი ადამიანი უნდა ამტკიცებდეს გვერდს?

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

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

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