Site WordPress stricat după o actualizare: reveniți la versiunea anterioară

Ce a fost actualizat?

Pe un site WordPress se actualizează patru elemente, iar fiecare se readuce altfel la versiunea anterioară: nucleul WordPress, modulele, tema și versiunea PHP a serverului, pe care furnizorul de găzduire o actualizează separat. Pentru a afla care s-a schimbat:

• E-mailurile WordPress: după o actualizare automată, WordPress scrie la adresa de administrare a site-ului, cu un subiect ca „[Numele site-ului] Unele module au fost actualizate automat”, și dă lista a ceea ce s-a schimbat.
• Ecranul de module: coloana „Actualizări automate” arată modulele care se actualizează singure, iar fiecare rând afișează versiunea instalată.
• Unelte > Sănătate site > Informații: secțiunea Server dă versiunea PHP, iar secțiunile despre module și teme, versiunea fiecărei componente.
• Datele dosarelor: un dosar de modul rescris de o actualizare poartă data acelei actualizări.

wp plugin list
ls -lt wp-content/plugins | head

Prima comandă listează modulele cu versiunea și starea lor; a doua, dosarele de module, de la cel modificat cel mai recent la cel mai vechi. Comparați cu ora la care s-a schimbat site-ul.

Goliți memoria cache înainte de a trage o concluzie

După o actualizare, fișierele CSS și JavaScript își schimbă conținutul, iar o memorie cache poate continua să le servească pe cele vechi. Rezultatul seamănă cu o defecțiune: aspect dezorganizat, meniuri care nu se mai deschid. Goliți, în această ordine, memoria cache a modulului de cache sau de optimizare, pe cea a furnizorului de găzduire, dacă oferă una, apoi pe cea a browserului, și reîncărcați pagina. Dacă site-ul revine, actualizarea nu era cauza.

Site-ul rămâne blocat în mentenanță

În timpul unei actualizări, WordPress creează un fișier .maintenance la rădăcina site-ului și afișează mesajul „Indisponibil datorită unui program de mentenanță programat. Revino în câteva minute.” Când actualizarea este întreruptă, fișierul rămâne pe loc. WordPress îl ignoră la zece minute după ora pe care o conține; ca să nu așteptați sau dacă mesajul persistă, ștergeți-l prin SFTP sau prin managerul de fișiere al furnizorului de găzduire. Pentru că numele lui începe cu un punct, activați afișarea fișierelor ascunse ca să îl vedeți.

Mergeți apoi în Panou control > Actualizări: elementul a cărui actualizare a fost întreruptă trebuie relansat sau reinstalat în versiunea anterioară.

Puneți la loc versiunea anterioară a unui modul

Reinstalarea versiunii anterioare înlocuiește fișierele modulului și îi păstrează setările, care se află în baza de date.

wp plugin install nume-modul --version=2.4.1 --force

• Modul din directorul WordPress.org: pe pagina lui publică, linkul „Vizualizare avansată” duce la lista „Versiuni anterioare”. Descărcați arhiva dorită, apoi, din ecranul „Adaugă module”, dați clic pe „Încarcă modulul”: WordPress recunoaște modulul deja instalat și propune „Înlocuiește modulul actual cu cel încărcat”.
• Modul cumpărat de la un editor: versiunile anterioare se descarcă de obicei din contul dumneavoastră de client la acesta.
• Apoi: dați clic pe „Dezactivează actualizările automate” în dreptul acestui modul, până când editorul publică o corecție.

WordPress știe deja să revină singur la versiunea anterioară în două cazuri. Începând cu versiunea 6.3, când actualizarea unui modul sau a unei teme eșuează pe parcurs, versiunea veche este pusă la loc. Începând cu versiunea 6.6, când actualizarea automată a unui modul activ provoacă o eroare fatală, WordPress reinstalează versiunea anterioară. O actualizare care reușește și strică o funcție fără eroare fatală se reia manual.

Tema: versiunea anterioară și modificările pierdute

wp theme install nume-tema --version=3.1.0 --force

O actualizare de temă înlocuiește toate fișierele acesteia. Modificările făcute direct în fișierele temei, de exemplu în functions.php sau într-o foaie de stil, dispar deci la fiecare actualizare. Copia de rezervă făcută înainte de actualizare permite regăsirea lor; ca să rămână în timp, ele se pun într-o temă copil, pe care actualizările temei părinte o lasă neatinsă.

Nucleul WordPress

WP-CLI reinstalează o versiune precisă a nucleului:

wp core update --version=7.0 --force

O actualizare majoră a nucleului poate modifica și structura bazei de date, pe care această comandă o lasă neschimbată. Cel mai sigur este adesea să păstrați nucleul la zi și să readuceți la versiunea anterioară modulul sau tema incompatibilă. Dacă revenirea nucleului este indispensabilă, ea se face dintr-o copie de rezervă completă, făcută înainte de actualizare.

Versiunea PHP, schimbată de furnizorul de găzduire

Furnizorii de găzduire trec la versiuni PHP noi pe măsură ce versiunile vechi nu mai primesc corecții de securitate. Un modul sau o temă mai veche se poate opri atunci într-o eroare fatală. Panoul furnizorului de găzduire permite de obicei alegerea versiunii PHP a site-ului:

1. Notați versiunea instalată, apoi reveniți la cea anterioară.
2. Verificați că site-ul funcționează din nou.
3. Actualizați sau înlocuiți componenta în cauză, identificată cu ajutorul jurnalului de depanare.
4. Treceți din nou la versiunea recentă.

Această revenire este o etapă de depanare: o versiune PHP fără corecții de securitate expune site-ul. Potrivit calendarului oficial publicat pe php.net, PHP 8.1 nu mai primește corecții de securitate din 31 decembrie 2025, PHP 8.2 le primește până la 31 decembrie 2026, iar PHP 8.3 până la 31 decembrie 2027. WordPress recomandă PHP 8.3 sau o versiune mai recentă.

Restaurarea unei copii de rezervă complete, ca ultimă soluție

O restaurare readuce fișierele și baza de date în starea din copia de rezervă. Tot ce a primit site-ul de atunci dispare: comenzi, mesaje din formulare, comentarii, înscrieri, articole publicate.

1. Exportați mai întâi ce a sosit după copia de rezervă: comenzi, intrări din formulare, conturi noi.
2. Restaurați fișierele și baza de date din același moment, cu instrumentul furnizorului de găzduire sau cu modulul de copii de rezervă. Fișiere dintr-o zi și o bază de date din altă zi produc erori greu de citit.
3. Reimportați datele exportate.
4. Reaplicați actualizările una câte una, verificând site-ul după fiecare: ultima aplicată înainte de defecțiune este cea care o cauzează.

Pentru următoarea actualizare

• O copie de test: mulți furnizori de găzduire oferă un mediu de staging care copiază site-ul dintr-un clic. Actualizările se aplică mai întâi acolo.
• O copie de rezervă chiar înainte, fișiere și bază de date împreună.
• O singură actualizare odată, cu o verificare a paginilor-cheie după fiecare: pagina de pornire, formularul de contact, coșul.
• Jurnalul de modificări al modulului sau al temei, citit înaintea unei actualizări majore.