Puncte:0

După actualizarea Debian Buster la Bullseye, site-urile Wordpress nu se mai actualizează

drapel cn

Astăzi mi-am actualizat serverul web de la Debian Buster la Bullseye și a fost de fapt o actualizare destul de simplă. Totul părea să funcționeze până când am încercat să ajung la câteva site-uri WordPress de pe server. La început am primit o eroare despre un modul MySQL lipsă. Mesajul de eroare primit de la PHPMyAdmin mi-a dat un indiciu mai bun: spunea că lipsește modulul mysqli.

Asa ca l-am instalat cu apt install php7.4-mysqli și asta a făcut ca site-urile mele WordPress să funcționeze din nou.

Singura problemă acum este însă că nu pot actualiza Wordpress. De fiecare dată când încerc să actualizez WordPress, primesc o eroare:

Eroare de actualizare WordPress

Bănuiesc că trebuie să instalez suphp. Dar înainte să o fac, poate cineva să confirme că este într-adevăr cazul? Sau trebuie să fac altceva după upgrade-ul de la Buster la Bullseye?

EDITAȚI | ×: Mi-a luat destul de mult timp să-mi dau seama ce se întâmplă de fapt. Acum știu, nu am idee cum să rezolv problema.

Mesajul de eroare pe care îl dă WP este de fapt incorect. După cum se dovedește, asta este capabil să despacheteze actualizarea foarte bine în folderul corespunzător. Dar atunci când verifică dacă fișierele s-au dezambalat, nu merge bine. Problema constă în această bucată de cod în update-core.php:

foreach ( $roots ca $root ) {
  if ( $wp_filesystem->exists( $from . $root . 'readme.html' )
    && $wp_filesystem->există( $de la . $root . 'wp-includes/version.php' )
  ) {
    $distro = $root;
    pauză;
  }
}
    
if ( ! $distro ) {
  $wp_filesystem->delete( $from, true );
  return new WP_Error( 'insane_distro', __( 'Actualizarea nu a putut fi dezambalată.' ) );
}

Ceea ce face aici, este pur și simplu să verifice dacă există două fișiere în folderul în care tocmai a despachetat fișierul zip. Acest lucru eșuează. Și motivul este următorul:

Folosesc metoda FTP pentru a instala actualizări. Deci, când îi spun să actualizeze, mai întâi își dă seama în care ar trebui să descarce fișierul zip. Acest folder este stocat în $working_dir și este folosit din acel moment pentru restul procesului de actualizare.Adevărata cale pe server este /domains/domainname.com/htdocs/wp-content/upgrade/ dar din moment ce utilizatorii FTP sunt crootati, WP găsește și stochează /htdocs/wp-content/upgrade/ in schimb. Fișierul de actualizare este descărcat în acest folder și apoi dezambalat.

Apoi face verificarea de mai sus. Și asta eșuează pentru că încearcă să găsească un fișier în /htdocs/wp-content/upgrade/ în timp ce adevărata locație este /domains/domainname.com/htdocs/wp-content/upgrade/.

Înțeleg de ce descarcă pachetul foarte bine (din moment ce utilizatorii FTP sunt crootate). Dar nu înțeleg de ce nu reușește despachetarea ulterioară, dar eșuează atunci când verifică existența fișierelor...

Am verificat toate setările php și nu pot găsi nimic diferit cu setările de dinainte de upgrade-ul Debian...

Zippy1970 avatar
drapel cn
Am vrut doar să adaug că suphp a fost **nu** instalat în Buster. De asemenea, tocmai am observat că actualizarea pluginurilor funcționează, dar după ce actualizez un plugin, site-ul meu WordPress rămâne în modul de întreținere (adică a creat fișierul .maintenance, dar nu l-a eliminat)...
Puncte:0
drapel cn

Mi-a luat ceva timp să-mi dau seama exact ce se întâmplă, dar este de fapt o problemă cu WordPress. Bullseye instalează versiunea 1.0.49 a PureFTPd unde a fost instalat Buster v1.0.47. Conform jurnalului de modificări PureFTPd Aici, globbing a fost eliminat din comanda NLST în v1.0.48 (ceea ce are sens, deoarece de fapt nu este permis conform RFC).

Dezvoltatorii WordPress sunt conștienți de problemă și au corectat funcția exists().Patch-ul este disponibil Aici; aplicarea acestuia este una dintre cele două moduri de a actualiza WordPress dacă utilizați PureFTPd versiunea 1.0.48 sau o versiune ulterioară și sunteți blocat cu actualizarea prin FTP.

De asemenea, puteți înlocui singur funcția /wp-admin/includes/class-wp-filesystem-ftpext.php (sau /wp-admin/includes/class-wp-filesystem-ftpsockets.php dacă utilizați FTPSockets) cu următoarele (care este de fapt propria mea implementare a funcției):


        funcția publică există ( $fișier ) {
          $retval = fals;

          $listă = ftp_nlist( $acest->link, $fișier );
          dacă(! gol($listă)) {
            // dacă ftp_nlist returnează *ceva*, fișierul sau directorul există, pe orice server FTP
            $retval = adevărat;
          } altfel {
            // dacă ftp_nlist nu returnează nimic, fie fișierul/dir nu există, fie este un fișier și
            // comanda NLST a serverului FTP nu acceptă globalizarea (adică Pure-FTPD > v1.0.47)
            // Verificați dacă este un fișier
            if( ftp_size( $acest->link, $fișier ) >= 0 ) {
              $retval = adevărat;
            }
          }
          return $retval;

        }

WordPress 6.0 va avea noua funcție în mod implicit.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.