Actualizări, copii de rezervă și roluri

Modulul 6: Administrare și securitate · Timp de citire: 11 minute

Obiectiv de învățare: După această lecție puteți actualiza un magazin WooCommerce și face copii de rezervă fără să pierdeți comenzi și puteți împărți drepturile astfel încât fiecare persoană să poată face doar ce este necesar.

Noțiuni cheie: actualizare majoră și minoră, actualizarea bazei de date, extensii și compatibilitate, suprascrieri de șabloane (template overrides), șabloane învechite, copie de rezervă înainte de actualizare, comenzi între copia de rezervă și restaurare, tabelele HPOS, rolurile Manager magazin (Shop manager) și Client (Customer), privilegiul minim, afișarea versiunilor, xmlrpc.php

De ce un magazin online este diferit de un site obișnuit

În cursul WordPress (lecțiile 7.2, 8.1 și 8.2) găsiți cum actualizați WordPress, cum faceți copii de rezervă și cum restaurați. Pentru un magazin online toate acestea rămân valabile, cu o mare diferență: baza de date se schimbă pe tot parcursul zilei. Fiecare comandă, fiecare client, fiecare modificare de stoc și fiecare plată ajung în ea. La un site de prezentare, cu o copie de rezervă de ieri pierdeți cel mult un articol. La un magazin online pierdeți comenzi care au fost deja plătite.

De aceea, două reguli de bază pentru această lecție:

1. La un magazin online, restaurarea este ultimul pas, nu primul.
2. Actualizați după un plan, nu „repede, printre altele, vineri după-amiază”.

Actualizările WooCommerce

WooCommerce lansează regulat versiuni noi, iar între ele mici remedieri. Numărul versiunii are trei părți, de exemplu 11.2.2. O schimbare a ultimei cifre înseamnă o mică remediere sau o actualizare de securitate; o schimbare a primei sau a celei de-a doua cifre aduce funcții noi și uneori modificări la care extensiile sau tema dumneavoastră trebuie să se adapteze.

La o actualizare WooCommerce se întâmplă trei lucruri pe care le vedeți mai rar la un modul obișnuit:

• O actualizare a bazei de date. Uneori WooCommerce trebuie să modifice tabelele. Vedeți atunci în administrare un mesaj că baza de date este actualizată; aceasta rulează în fundal prin acțiunile programate (lecția 7.3). Nu o întrerupeți și verificați la WooCommerce > Stare dacă s-a încheiat.
• Extensiile trebuie să țină pasul. Modulele de plată, integrările de livrare și cele de contabilitate indică până la ce versiune de WooCommerce au fost testate. În ecranul de module vedeți un avertisment dacă o extensie nu menționează o versiune mai nouă. Citiți modificările modulului dumneavoastră de plată înainte de actualizare: un modul de plată care nu mai funcționează înseamnă un magazin care nu vinde.
• Suprascrierile de șabloane. Multe teme au propriile copii ale șabloanelor WooCommerce (folderul woocommerce/ din temă). Dacă WooCommerce modifică originalul, copia devine învechită. La WooCommerce > Stare (Stare sistem) vedeți în partea de jos, la temă, ce șabloane suprascrie aceasta și care sunt învechite. Șabloanele învechite pot să nu conțină câmpuri noi sau pot genera erori. Actualizați tema sau cereți autorului o actualizare.

Actualizările minore (ultima cifră) le aplicați de preferință repede, ideal automat, pentru că adesea repară erori de securitate. Actualizările majore le testați mai întâi pe staging (lecția 7.3), într-un moment liniștit, cu o copie de rezervă făcută imediat înainte.

Copii de rezervă: ce dispare la restaurare

Un exemplu. Theehuis Example face în fiecare noapte, la ora 03.00, o copie de rezervă. Marți, la ora 10.00, administratorul actualizează WooCommerce, iar după aceea pagina de produs afișează o eroare. Între 03.00 și 10.00 au intrat șase comenzi, plătite prin furnizorul de plăți. Dacă restaurați acum copia de rezervă de la 03.00, atunci:

• cele șase comenzi dispar din baza de date, deși banii se află la furnizor;
• magazinul nu mai știe că stocul este mai mic;
• magazinul poate primi ulterior notificări (webhooks) de la furnizor despre comenzi pe care nu le cunoaște.

De aceea:

• Faceți o copie de rezervă imediat înainte de o actualizare, nu doar noaptea. Astfel golul este cât mai mic.
• La restaurare, notați ce comenzi au venit după copia de rezervă (din e-mailurile „Comandă nouă” și din panoul furnizorului dumneavoastră de plăți) și readăugați-le apoi manual sau exportați-le în prealabil.
• Restaurați de preferință doar fișierele (vechiul folder al modulului sau al temei) dacă problema este în cod și lăsați baza de date neatinsă. O actualizare poate fi adesea anulată instalând versiunea anterioară a modulului; cursul WordPress, lecția 8.2, arată cum restaurați în mod țintit. Dacă actualizarea a modificat deja baza de date, este posibil ca versiunea veche să nu mai funcționeze cu ea: de aceea testați mai întâi pe staging.
• Faceți copii de rezervă mai des decât la un site obișnuit: un magazin cu comenzi pe tot parcursul zilei are nevoie de o copie a bazei de date cel puțin zilnic, ideal mai des, și de o copie în afara serverului (regula 3-2-1, cursul WordPress, lecția 8.1).

Începând cu WooCommerce 8.2, comenzile magazinelor noi se află în tabele proprii (HPOS, lecția 1.2), cum ar fi wp_wc_orders. Un modul de copii de rezervă care preia doar „articolele” sau alege tabelele după nume trebuie să includă și aceste tabele. La un test de restaurare (cursul WordPress, lecția 8.2), verificați dacă acele comenzi sunt într-adevăr incluse.

La WebOké, WebOké Backups face în fiecare noapte o copie de rezervă, păstrată 30 de zile într-un alt centru de date (DA 16.1); în plus, puteți face singur o copie de rezervă înainte de o actualizare în DirectAdmin sau Installatron. La alți furnizori de găzduire funcționează în mod similar; întrebați cât de des și pentru cât timp.

Roluri: cine ce poate face

WooCommerce adaugă două roluri în WordPress (cursul WordPress, lecția 3.3):

• Client (Customer): un client cu cont. Poate vedea doar propriile comenzi și date. Nu acordați niciodată acestui rol drepturi de administrare.
• Manager magazin (Shop manager): poate gestiona produse, comenzi, clienți, cupoane și setările WooCommerce, dar nu poate instala module și nu poate schimba tema.

Pentru angajații care ambalează comenzi, răspund la întrebările clienților sau introduc produse, rolul Manager magazin este suficient. Administrator este doar pentru cine se ocupă de partea tehnică. Fiecare angajat are propriul cont, cu autentificare în doi pași (cursul WordPress, lecția 7.3); fără un cont comun „magazin”. Un manager de magazin vede toate datele clienților, așa că ștergeți conturile atunci când cineva pleacă.

Cheile API (lecția 2.4) sunt tot o formă de drepturi: acordați unei integrări doar acces de citire dacă nu trebuie să scrie nimic și ștergeți cheile care nu mai sunt folosite.

Ce afișează magazinul dumneavoastră tuturor

Atacatorii caută magazine cu o versiune veche de WooCommerce sau cu un modul de plată care are o vulnerabilitate cunoscută. WooCommerce pune implicit în codul sursă un rând <meta name="generator" content="WooCommerce 11.2.2">, iar versiunea apare și după foile de stil (?ver=). Ascunderea este un câștig mic; actualizarea, unul mare. Un magazin la zi nu trebuie să își facă prea multe griji din cauza unui număr de versiune vizibil. Un magazin rămas în urmă se trădează.

Fișierul xmlrpc.php este o interfață veche prin care aplicațiile se autentifică în WordPress. Este folosit adesea abuziv pentru ghicirea parolelor. Dacă nu folosiți nicio aplicație sau serviciu care are nevoie de el, închideți-l (la WebOké este închis implicit, KB 169). Un xmlrpc.php deschis răspunde la o cerere obișnuită din browser cu „XML-RPC server accepts POST requests only.” și starea 405. Închis, răspunde cu 403 sau 404.

Rezumat

• Baza de date a unui magazin se schimbă toată ziua: restaurarea costă comenzi deja plătite.
• Actualizările minore repede, cele majore mai întâi pe staging; urmăriți actualizarea bazei de date, extensiile și șabloanele învechite la WooCommerce > Stare.
• Faceți o copie de rezervă imediat înainte de o actualizare și mai des decât la un site obișnuit; verificați că tabelele de comenzi sunt incluse.
• Angajații primesc rolul Manager magazin, nu Administrator; fiecare cu propriul cont și autentificare în doi pași.
• Ascunderea versiunilor ajută puțin, actualizarea mult; închideți xmlrpc.php dacă nu îl folosiți.

Test (quiz)

Exercițiu

Exercițiul A6.2: Afișează magazinul dumneavoastră versiunile? Introduceți adresa magazinului dumneavoastră, versiunea WordPress (Panou de control > Actualizări) și versiunea WooCommerce (Module). Programul solicită pagina principală și fluxul, precum și fișierul /wp-content/plugins/woocommerce/readme.txt (doar primii 2 kB, rândul „Stable tag”). Caută numerele de versiune ale WordPress și WooCommerce în rândurile generator și după ?ver= la foile de stil WooCommerce și solicită de la wordpress.org cele mai noi versiuni. Verde dacă versiunile dumneavoastră sunt cele mai noi și ce este vizibil corespunde cu ele. Portocaliu dacă este disponibilă doar o actualizare minoră sau dacă versiunea este vizibilă, dar actuală. Roșu dacă ați rămas în urmă cu o versiune majoră, dacă versiunea vizibilă diferă de cea introdusă (rulează altceva decât credeți) sau la date introduse greșit.

Exercițiul A6.2b: Este xmlrpc închis? Introduceți adresa magazinului dumneavoastră și bifați dacă folosiți o aplicație sau un serviciu care are nevoie de xmlrpc.php. Programul solicită /xmlrpc.php printr-un GET obișnuit, fără să trimită nimic. Verde la 401, 403, 404, 410, o redirecționare sau o pagină HTML obișnuită. Roșu la 405 cu textul „XML-RPC server accepts POST requests only.” fără bifă; portocaliu dacă ați indicat că aveți nevoie de el. Verifică de asemenea dacă lista numelor de utilizator prin /wp-json/wp/v2/users este publică (portocaliu dacă sunt vizibile nume).

O bifă verde înseamnă că această verificare este în regulă acum, nu că magazinul dumneavoastră este sigur.

Lecturi suplimentare

Pașii dintr-un panou sunt valabili pentru WebOké; la alți furnizori funcționează în mod similar.

• Curs gratuit WordPress 7.2: Gestionarea actualizărilor
• Curs gratuit WordPress 8.1: Copii de siguranță: ce, unde și cât de des
• Curs gratuit WordPress 8.2: Restaurare și testare
• Curs gratuit WordPress 3.3: Utilizatori și roluri
• Manual DirectAdmin 16.1: Ce tipuri de backupuri există la WebOké
• WebOké Backups: vizualizarea, restaurarea sau descărcarea unei copii de rezervă
• Accesul la xmlrpc.php în WordPress nu funcționează
• High Performance Order Storage (developer.woocommerce.com, în limba engleză): https://developer.woocommerce.com/docs/features/orders/high-performance-order-storage/