4 sfaturi pentru a repara un site WordPress

Acum câteva zile, un prieten a sunat și mi-a spus că i s-a dat sarcina de a menține un vechi proiect WordPress. Aparent, site-ul web nu a fost actualizat de mai bine de trei ani și au existat probleme peste tot. Bietul a rămas blocat, pentru că nu a putut actualiza nimic acolo: pluginuri, temă, conținut... nimic nu a funcționat. Toate acțiunile (altele decât navigarea pe site-ul în sine) au dus la blocarea WordPress și returnarea unei erori.

Când avem un WordPress inutilizabil care generează erori continuu și nu poate fi actualizat, primul lucru pe care trebuie să-l facem este să identificăm de ce se comportă așa. Adică trebuie să găsim vinovatul. De obicei, orice probleme pe care le-ați putea întâlni pe un site WordPress apar din cauza temei dvs. sau a unuia (sau mai multor) dintre pluginurile dvs.

Având în vedere acest lucru, procedura obișnuită de a remedia un site WordPress este să identificăm pluginul ofensator, să-l eliminăm din ecuație, să actualizăm totul și, în sfârșit, să vedem dacă putem reinstala și actualiza pluginul ofensator pe site-ul nostru sau ar trebui să căutăm un înlocuire. Astăzi am să vă spun patru trucuri simple pentru a descoperi de ce un site eșuează și, astfel, pentru a-l putea remedia.

Utilizarea jurnalului de erori al serverului nostru

Presupunând ipoteza că este un plugin cel care cauzează erorile pe care le avem pe site-ul nostru, primul lucru pe care trebuie să-l facem este să validăm respectiva ipoteză. Există diferite formule pentru a face acest lucru. Personal, îmi place să încep prin a vedea jurnalul de erori al serverului meu, care are propria sa opțiune în cPanel:

Sperăm că jurnalul de erori nu conține doar o urmă a erorilor care au apărut pe site-ul nostru web, ci și informații despre „unde” acestea au apărut și, prin urmare, cine a fost vinovat. De exemplu, săptămâna trecută am întâlnit următoarea problemă în jurnalul de erori al mediului meu de dezvoltare:

 appserver_1 | [Mon Aug 24 09:18:20.977541 2020] [php7:notice] [pid 1107] [client 172.20.0.2:34396] PHP Notice: register_rest_route was called <strong>incorrectly</strong>. The REST API route definition for <code>yoast/v1/get_head</code> is missing the required <code>permission_callback</code> argument. For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugg ing in WordPress</a> for more information. (This message was added in version 5.5.0.) in /app/.lando/wordpress/wp-includes/functions.php on line 5225, referer: http://nab5.lndo.site/wp-admin/edit.php

Jurnalul raportează o notificare PHP care a apărut într-unul dintre fișierele proprii ale WordPress ( wp-includes/functions.php ), care nu ne spune nimic despre „un plugin este vinovatul”. Din fericire, dacă citiți întreg mesajul, veți vedea că acesta descrie ce a eșuat (adică un apel la funcția register_rest_route ) și ne oferă un indiciu despre ce ar putea fi greșit: Yoast (vedeți cum menționează „ yoast/v1/get_head ” ?).

Jurnalele de erori sunt cel mai simplu mod de a afla rapid când/dacă ceva nu este în regulă și, dacă este, care este motivul din spatele unei erori. În acest exemplu, am aflat că am avut o problemă cu Yoast și, ei bine, tot ce trebuia să fac a fost să actualizez pluginul la cea mai recentă versiune.

Dezactivarea pluginurilor din tabloul de bord WordPress

Din păcate, nu este întotdeauna posibil să accesați jurnalul de erori al unui site web pentru a afla când lucrurile au mers în sud. Sau, dacă aveți acces la jurnal, acesta poate fi incomplet. În aceste cazuri avem nevoie de formule alternative pentru a valida (sau infirma) ipoteza noastră inițială.

Presupunând că site-ul nostru web eșuează din cauza unui plugin defect, cel mai ușor lucru de făcut este să dezactivați toate pluginurile și să verificați dacă eroarea persistă. Dacă nu, vinovatul a fost un plugin; daca persista, problema este in alta parte.

Pentru a face acest lucru, accesați Tabloul de bord WordPress » Plugins , selectați toate pluginurile dvs. active și dezactivați -le în bloc:

și verificați dacă eroarea mai apare. Dacă nu, știți că problema a fost cauzată de unul dintre pluginurile pe care tocmai le-ați dezactivat. Acum este timpul să descoperim care dintre ele mai exact.

Pentru a identifica pluginul defect, le puteți activa unul câte unul și verifica când eroarea apare din nou. Sau, dacă vrei să mergi mai repede, poți aplica următorii pași:

1. Activați jumătate din pluginurile dvs.
   1. Dacă eroarea reapare, vinovatul se află în jumătatea pe care tocmai ați activat-o, astfel încât să puteți activa în siguranță cealaltă jumătate.
   2. Dacă eroarea nu apare, vinovatul este în cealaltă jumătate.
2. Odată ce știți în ce „grup” se află pluginul defect, trebuie doar să vă concentrați pe acesta și să repetați procesul. Activați jumătate din acel grup și dezactivați cealaltă jumătate (adică veți verifica acum o pătrime din total) și vedeți dacă site-ul dvs. funcționează corect.
3. Repetați procesul până când găsiți vinovatul.

Odată ce știți care plugin eșuează, cum să remediați problema depinde de dvs. Este posibil să trebuiască să contactați dezvoltatorul, să încercați să reparați singur pluginul sau chiar să luați în considerare înlocuirea acestuia cu o alternativă. Dar, cel puțin, acum știi ce trebuie să faci pentru a scăpa de problemă.

Faceți o copie de rezervă a listei dvs. de pluginuri active

Îți amintești de prietenul meu de la început? Când investigam site-ul lui, am urmat toți pașii anteriori și am dezactivat toate pluginurile de pe site-ul său...

… ceea ce a dus la un ecran alb al morții!

Aparent, web-ul era plin de plugin-uri personalizate și de modificări ale temei, cu o mulțime de dependențe încrucișate. Prin dezactivarea pluginurilor, unele dintre funcțiile pe care se baza tema nu mai erau disponibile, ceea ce a declanșat o eroare fatală. Aceasta este în mod clar o practică proastă: o temă nu se poate baza pe un plugin activ. Dacă are nevoie de unele dintre caracteristicile oferite de un anumit plugin, trebuie să implementeze verificări de securitate pentru a valida dacă sunt disponibile sau nu.

Oricum, chestia este că site-ul a fost complet închis și nu am reușit să reactivăm pluginurile folosind Dashboard. Deci, care este soluția aici? Ei bine, pentru început, ar trebui să aveți întotdeauna o copie de rezervă a site-ului dvs. web... dar în acest caz particular există o soluție mai ușoară și mai rapidă la îndemână.

În baza de date WordPress, există un tabel numit wp_options . Acolo, veți găsi o opțiune numită active_plugins . Valoarea sa este o matrice cu toate pluginurile active. Deci, înainte de a dezactiva pluginurile folosind acțiunea în bloc pe care am menționat-o mai înainte, salvați această valoare într-un fișier text:

În acest fel, dacă „dezactivarea tuturor pluginurilor” se termină într-un WSOD improbabil (dar nu imposibil), puteți reactiva toate pluginurile restabilind opțiunea active_plugins din baza de date.

Cum să dezactivezi pluginurile prin FTP

Dacă știți că problema dvs. este generată de un anumit plugin, dar nu aveți cum să o dezactivați din tabloul de bord WordPress, o puteți face în siguranță prin FTP.

După cum știți deja, pluginurile nu sunt altceva decât un set de fișiere. Când instalați un plugin nou pe site-ul dvs., codul acestuia ajunge în folderul wp-content/plugins al WordPress. Profitând de aceste cunoștințe, putem dezactiva pluginul „eliminându-l” din folderul respectiv.

Accesați cPanelul serverului dvs. și căutați opțiunea FTP:

Apoi, folosind exploratorul de fișiere FTP, găsiți folderul wp-content/plugins și localizați pluginul:

Acum, tot ce trebuie să faceți este fie să ștergeți pluginul, fie să redenumiți folderul, astfel încât WordPress să nu-l găsească. În acest fel, dacă vă conectați la site-ul dvs. WordPress, WordPress nu va mai vedea pluginul și nu va putea încărca codul defect al acestuia, rezolvând astfel problema pe care ați avut-o.

Utilizați o temă implicită

În cele din urmă, dacă ipoteza că problema a fost cauzată de unul dintre pluginurile dvs. nu era adevărată, următorul pas este să presupuneți că vinovatul este tema dvs. În acest caz, tot ce trebuie să faci este să instalezi o temă WordPress implicită (cum ar fi Twenty Twenty) și să vezi dacă problema dispare sau nu. Dacă dispare, știi deja că este ceva în neregulă cu tema ta originală; dacă nu, asta va trebui să discutăm într-o postare diferită.

Dacă, indiferent de motiv, nu aveți acces la tabloul de bord WordPress, puteți instala o nouă temă pe site-ul dvs., încărcând-o prin FTP ( wp-content/themes ) și modificați tema activă folosind baza de date: modificați doar template de opțiuni și foaia de stylesheet în wp_options . De exemplu, este posibil să doriți să setați ambele opțiuni la twentytwenty , presupunând că aceasta este tema pe care ați încărcat-o.

În concluzie

Un WordPress vanilla (fără pluginuri și fără o temă personalizată) este puțin probabil să eșueze. Deci, dacă aveți probleme pe site-ul dvs., cel mai probabil vinovat este unul dintre pluginurile sau tema dvs. În postarea de astăzi am văzut diferite formule pentru a găsi vinovatul, a-l scoate din cale și a recupera site-ul web. Sper din tot sufletul că nu trebuie să folosiți niciunul dintre aceste trucuri... dar dacă o faceți, sper că vă vor fi de ajutor.

Dar site-ul prietenului meu? Ei bine, nu știu – unii oameni spun că și-a schimbat cariera...

Imagine prezentată de Olia Nayda pe Unsplash.