Ho riscontrato questo errore dopo aver aggiornato la mia installazione di PHP alla 5.5.14, su RedHat EL v6. Avevo installato PHP tramite il gestore pacchetti Yum, e quindi avevo bisogno di reinstallare alcune delle estensioni PHP che stavo usando. Nel cercare suggerimenti su come risolvere questo problema, mi sono imbattuto in questa domanda e ora che ho scoperto una soluzione funzionante, ho voluto condividere qui i miei risultati. Altri suggerimenti che avevo trovato online che includevano la cancellazione e la reinstallazione di PECL / PEAR e persino la mia installazione di PHP non hanno risolto questo problema. Finalmente dopo qualche ulteriore ricerca e revisione del codice sorgente per PECL / PEAR ho trovato la vera causa. Speriamo che ciò che segue sarà di aiuto per gli altri:
È possibile che venga visualizzato questo errore quando si tenta di eseguire PECL se l'installazione PHP non ha XML abilitato per impostazione predefinita, ma invece il supporto XML viene solitamente caricato nell'installazione PHP tramite un modulo di estensione PHP (ciò potrebbe verificarsi se il ./configure --disable-xml
flag è stato specificato durante la creazione di PHP dalla fonte, o se hai installato PHP tramite vari gestori di pacchetti in cui quella build di PHP è configurata per caricare XML tramite un modulo di estensione).
Notare come è l'ultima riga dell'output dell'errore da PECL XML Extension not found
- il motivo per cui questo errore appare è perché quando PECL tenta di usare la sua classe XMLParser.php fallisce perché non può accedere all'estensione XML (controlla il modulo XML usando extension_loaded('xml')
attorno alla linea 259 del sorgente XMLParser.php) e poiché il modulo XML non è disponibile, non può analizzare i file di configurazione / impostazioni e generare tutti gli altri errori visti sopra.
Il motivo per cui si verifica questo problema è dovuto al modo in cui PECL opera. Il comando PECL stesso è solo uno script di shell, che determina innanzitutto dove è installato PHP sull'installazione del sistema, quindi chiama PHP sulla riga di comando con un numero di flag prima di fornire il percorso del file di script PHP PECL principale. Il flag di problema utilizzato dallo script della shell PECL è l' -n
opzione che indica a PHP di ignorare qualsiasi php.ini
file (e quindi PHP non caricherà nessuna delle estensioni aggiuntive php.ini
specificate dal file, incluso in questo caso XML).
Si può vedere l'impatto del -n
flag eseguendo i seguenti due comandi:
- prima prova a correre
php -m
sulla riga di comando
- quindi confrontare l'output con
php -n -m
Non dovresti vedere l'estensione XML elencata quando esegui il secondo comando perché il -n
flag ha detto a PHP di non analizzare i nostri php.ini
file.
Se esegui vi `which pecl`
dalla riga di comando dovresti vedere il contenuto del comando PECL (come notato sopra, è solo uno script di shell), e se controlli l'ultima riga, vedrai qualcosa del genere:
exec $PHP -C -n -q $INCARG -d date.timezone=UTC -d output_buffering=1 -d variables_order=EGPCS -d safe_mode=0 -d register_argc_argv="On" $INCDIR/peclcmd.php "$@"
Dovresti vedere il -n
flag elencato tra i flag -C
e -q
. Se modifichi lo script della shell PECL, omettendo il -n
flag ora dovresti essere in grado di eseguire nuovamente PECL senza problemi.
In alternativa, puoi ricompilare PHP dal sorgente assicurandoti che il modulo XML sia compilato nel binario PHP anziché essere caricato da un modulo di estensione PHP in fase di esecuzione. Ovviamente la modifica dello script della shell PECL per rimuovere il -n
flag risolverà il problema solo fino a quando PECL / PEAR non verrà reinstallato, si spera tuttavia che i manutentori di PECL / PEAR possano aggiornare il loro repository con questa correzione. Garantire che PHP sia costruito con il supporto XML compilato, è comunque una soluzione a lungo termine alla soluzione, ma potrebbe non essere l'ideale per le circostanze di tutti.
Per completezza, se esegui vi `which pear`
vedrai uno script di shell molto simile a quello utilizzato da PECL, tuttavia il -n
flag che manca al comando che chiama PHP e come tale il comando PEAR non è soggetto agli stessi problemi.