Erori fatale WordPress 6.0 în class-wp-widget.php pentru PHP 8.1.6

31 mai 2022, 02:05:12
Vizualizări: 21.9K
Voturi: 5

/wp-includes/class-wp-widget.php îmi dă o eroare pentru un blog, dar nu și pentru celălalt, și ambele au aceeași versiune de class-wp-widget.php ceea ce nu are sens pentru mine.

PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function WP_Widget::__construct(), 0 passed in /home/www/stackexchange.com/wp-includes/class-wp-widget-factory.php on line 61 and at least 2 expected in /home/www/stackexchange.com/wp-includes/class-wp-widget.php:162

Citind codul, se pare că class-wp-widget.php este sursa problemei, dar s-ar putea să mă înșel.

Celălalt blog (care funcționează) de pe același server are același fișier și nu primesc eroarea.

Puteți vedea funcția WordPress defectă aici https://developer.wordpress.org/reference/classes/wp_widget/__construct/

Există vreo modalitate de a "dezactiva" widget-urile pentru a dezactiva acest cod WordPress defect?

Actualizare: mulțumesc @bosco pentru idee, analizarea Stack trace-ului a ajutat...

Stack trace:
#0 /home/www/example.com/wp-includes/class-wp-widget-factory.php(61): WP_Widget->__construct()
#1 /home/www/example.com/wp-includes/widgets.php(115): WP_Widget_Factory->register()
#2 /home/www/example.com/wp-content/themes/theme1516/includes/register-widgets.php(22): register_widget()
#3 /home/www/example.com/wp-includes/class-wp-hook.php(307): load_my_widgets()
#4 /home/www/example.com/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()
#5 /home/www/example.com/wp-includes/plugin.php(476): WP_Hook->do_action()
#6 /home/www/example.com/wp-includes/widgets.php(1854)

Deoarece "register-widgets.php" este singurul cod non-core de aici, și pentru că presupun că comentariul lui @bosco este corect, am comentat widget-urile vechi și cel puțin asta a eliminat "ecranul alb al morții" între timp pagina de start arată ciudat, probabil voi face doar copy/paste la HTML-ul de pe site-ul cu PHP 7.x.

8
Comentarii

Dacă ar fi o problemă de compatibilitate cu PHP 8.1, aș pune pariu că ai vedea o notificare de depreciere - conform Make: "Toate problemele cunoscute rămase în PHP 8.1 sunt notificări de depreciere.". Cel mai probabil, această eroare este produsul unui plugin sau temă care folosește o metodă învechită de înregistrare a Widget-urilor - faptul că stiva de apeluri din eroare nu menționează o extensie nu înseamnă că eroarea nu a fost cauzată de una. Metoda tradițională de depanare prin dezactivare/activare unul câte unul ar putea ajuta la identificarea culpabilului

bosco bosco
31 mai 2022 02:47:03

Analizând codul personal, se pare că o extensie probabil trimite ceva către register_widget() care nu suprascrie corespunzător constructorul WP_Widget.

bosco bosco
31 mai 2022 02:59:08

Aș aștepta înainte de a face upgrade la PHP 8.1. Deși WordPress funcționează pe PHP 8.0, încă nu suportă oficial 8.0, iar multe plugin-uri și teme nu au fost testate sau nu funcționează pe 8.0. Versiunea 8.1 este și mai nouă, iar multe dintre uneltele nu au fost actualizate să ruleze pe ea. Cel puțin pentru încă câteva luni, ar trebui să consideri PHP 8.1 ca fiind la stadiul experimental. Atâta timp cât folosești o versiune de PHP care se află încă în perioada de suport, vei fi în regulă pentru moment

Tom J Nowell Tom J Nowell
31 mai 2022 03:00:19

Altfel, Bosco are probabil dreptate, dezactivează toate pluginurile și activează-le pe rând, apoi verifică în acel plugin apelurile de înregistrare a widget-urilor, un stack trace ar fi indicat direct pluginul relevant. Eroarea pe care ai partajat-o indică doar că este legată de Widget, cel mai probabil un widget personalizat încearcă să apeleze constructorul părintelui dar nu transmite niciun argument, așa: parent::__construct() când ar trebui să fie așa parent::__construct( 'my_widget', 'My Widget' );

Tom J Nowell Tom J Nowell
31 mai 2022 03:02:27

OK @bosco o să încerc din nou, am găsit niște apeluri vechi de register_widget într-o temă veche, poate le pot comenta pe acelea.

Jay Brunet Jay Brunet
31 mai 2022 03:10:10

@PJBrunet ar trebui să postezi soluția ta ca o soluție, nu ca o editare, site-ul nu va vedea niciodată că ai rezolvat problema și va continua să o afișeze pentru a încerca să obțină un răspuns.

Tom J Nowell Tom J Nowell
31 mai 2022 03:54:09

@TomJNowell Da, am luat asta în considerare. Nu sunt nou pe aici LOL. Nu sunt convins că problema este rezolvată. O temă veche care a funcționat timp de 10+ ani până la PHP 7.x nu ar trebui să facă WordPress să se blocheze cu un ecran alb al morții. Chiar mai bine, un asistent de migrare a temelor/pluginurilor pentru PHP 8.x ar fi minunat. Lucrez în PHP de 20 de ani și nu am nicio dorință să învăț widget-urile WordPress. În opinia mea de expert, au fost o idee proastă de la bun început, și uite, nu au prins cu adevărat. La fel, OOP a fost subiect de glume de ani de zile, nimeni nu vrea să repare nici erorile din constructorii PHP.

Jay Brunet Jay Brunet
31 mai 2022 04:20:53

Nu am încredere în temele care nu primesc actualizări regulate - nu aș avea niciodată încredere într-o temă scrisă pentru compatibilitate cu un nucleu WordPress care are 10+ ani și care nu a fost atinsă de atunci. Nu există niciun motiv pentru care WordPress ar trebui să suporte codarea widget-urilor din tema ta, deoarece acestea nu au fost niciodată implementate corect de la bun început. Cel mai bine ar fi să găsești o temă complet nouă, deoarece această problemă ar putea fi un indiciu al altor abuzuri de API/funcționalități prost codate și, având în vedere că nu a fost actualizată niciodată, probabil și al unui număr de vulnerabilități de securitate.

bosco bosco
31 mai 2022 22:44:03
Arată celelalte 3 comentarii
Toate răspunsurile la întrebare 3
4
16

În cazul în care nu poți reveni la o versiune de PHP mai veche de 8.1 sau să repari înregistrarea widget-urilor (și ai încredere în tema ta veche de peste 10 ani), poți actualiza linia 61 din wp-includes/class-wp-widget-factory.php în felul următor:

$this->widgets[ $widget ] = new $widget( $widget, $widget );

Această modificare poate rezolva problema înregistrării widget-urilor.

31 aug. 2022 11:25:52
Comentarii

Aceasta a fost exact și problema mea, iar această modificare de cod a rezolvat-o pentru mine. Mulțumesc mult pentru asta!

SqlRyan SqlRyan
6 feb. 2023 18:09:25

Mulțumesc. Mi-ai salvat situația.

recantha recantha
16 mai 2023 22:28:50

A fost incredibil! După această mică modificare, am putut porni WordPress și apoi am dezactivat cu ușurință plugin-ul problematic. Apoi am putut să schimb codul înapoi la cel implicit din WordPress ($this->widgets[ $widget ] = new $widget()), iar site-ul încă funcționează. Mulțumesc mult!

Jesper Jesper
29 iul. 2023 19:35:31

Amintire prietenoasă că modificarea nucleului nu este niciodată o idee bună. Faci o actualizare și, hop, trebuie să o faci din nou.

Fredy31 Fredy31
17 aug. 2023 22:38:56
5

Bănuiesc că cauza este un widget personalizat construit incorect. Uită-te la acest exemplu din Codex:

class My_Widget extends WP_Widget {

    /**
     * Configurează numele widgetului etc.
     */
    public function __construct() {
        $widget_ops = array( 
            'classname' => 'my_widget',
            'description' => 'My Widget este fantastic',
        );
        parent::__construct( 'my_widget', 'My Widget', $widget_ops );
    }

Ceea ce fac multe pluginuri prost construite este următorul lucru:

class My_Widget extends WP_Widget {

    /**
     * Configurează numele widgetului etc.
     */
    public function __construct() {
        parent::__construct();
    }

Sau nu includ deloc o metodă __construct! Transmiterea fără parametri sau absența unui constructor este incorectă. Versiunile anterioare de PHP ar fi putut înlocui aceste valori cu null sau undefined, rezolvându-le ca '', dar mă așteptam ca aceasta să devină o problemă înainte de actualizarea la 8.1 și cu siguranță ar fi apărut în jurnalul de erori ca o notificare.

Deci identifică care plugin sau temă este responsabil pentru aceasta, fie prin urmărire a stivei, fie printr-un proces de eliminare, poate chiar prin căutarea în codul sursă cu un instrument.

Dacă aceasta este în cod pe care îl întreții, cum ar fi o temă sau un plugin personalizat, poți rezolva problema prin implementarea corectă a API-ului Widget, așa cum instruiesc Codex și ghidurile devhub. Mai exact, prin furnizarea primilor doi parametri.

Dacă nu ești interesat să repari widgeturile, le poți elimina complet de pe site.


Între timp, revino la versiunea 8.0 pentru un timp. Atât 8.0 cât și 8.1 sunt versiuni acceptate de PHP și primesc actualizări. WordPress încă nu a construit suport oficial pentru 8.0, iar 8.1 este o versiune foarte recentă (începutul anului 2022), așa că nu este surprinzător că ai întâmpinat probleme de compatibilitate și conflicte cu codul terților la actualizare.

31 mai 2022 03:10:03
Comentarii

Deși apreciez efortul, acest răspuns seamănă cu alte răspunsuri pe care le-am găsit pe Google. În cazul meu particular, nu folosesc widget-urile, acestea au fost doar incluse ca extra în temă și nu am nicio dorință să repar o duzină de widget-uri vechi de peste 10 ani. În ceea ce privește PHP 8.x, am două bloguri de test care rulează fără probleme pe Arch, apropo ;-)

Jay Brunet Jay Brunet
31 mai 2022 03:42:31

indiferent dacă ai folosit widget-urile sau nu, acest aspect este irelevant pentru problemă (eu rulez propriul site pe 8.0). Dacă nu intenționezi să folosești widget-urile și nu vrei să le repari, atunci ar trebui să le elimini. Problema nu este WordPress, ci codul terță parte care folosește greșit API-ul și generează erori.

Tom J Nowell Tom J Nowell
31 mai 2022 03:52:04

Pentru a spune altfel, atunci când codul tău scris pentru o bibliotecă concepută pentru standardul C++ 98 nu compilează când actualizezi codul la standardul C++ 20, nu este deloc vina Comitetului/Grupului de Lucru C++ - încerci să folosești o bibliotecă scrisă acum peste 20 de ani de cineva care nu a actualizat-o niciodată, pe o platformă care nu a fost construită să o susțină. WordPress are o convingere enervant de puternică în ceea ce privește compatibilitatea retroactivă - dar schimbările care rup compatibilitatea sunt bune pentru sănătatea și dezvoltarea oricărei tehnologii.

bosco bosco
31 mai 2022 22:31:46

Pe când în acest caz, Widget-ul a fost construit incorect din prima zi

Tom J Nowell Tom J Nowell
31 mai 2022 22:34:19

@TomJNowell Se întâmplă astfel de lucruri, dar PHP 8.x pare mai pretențios decât versiunile anterioare. Am găsit alte erori fatale, dar din fericire au fost rezolvate în WP 6.

Jay Brunet Jay Brunet
2 iun. 2022 01:33:23
3

Pentru cei care încă întâmpină această problemă, puteți încerca să mergeți în wordpress/wp-includes/class-wp-widget-factory.php la linia 61 și să faceți următoarea modificare pentru a remedia problema fără a schimba alt cod:

Schimbați această linie: $this->widgets[ $widget ] = new $widget();

În: $this->widgets[ $widget ] = new $widget( $widget, $widget );

Acum totul ar trebui să funcționeze conform așteptărilor.

19 ian. 2023 21:54:43
Comentarii

Nu, nu modifica niciodată fișierele de bază.

vancoder vancoder
20 ian. 2023 00:40:26

Cu siguranță este o idee proastă și nu ar trebui să faci această modificare și apoi să pleci pur și simplu, dar când site-ul tău nu se încarcă și nici măcar nu poți exporta sau recupera datele pentru că interfața de administrare este indisponibilă, această soluție este de mare ajutor.

SqlRyan SqlRyan
6 feb. 2023 18:16:57

în actualizarea WordPress din martie 2023 (6.2) există încă o incompatibilitate cu versiunea PHP 8.1 care încă trebuie rezolvată în acest fel... :/ (da, acest fișier este suprascris după fiecare actualizare)

hello_earth hello_earth
10 apr. 2023 16:55:50