Ten błąd napotkałem po aktualizacji mojej instalacji PHP do wersji 5.5.14 na RedHat EL v6. Zainstalowałem PHP za pomocą menedżera pakietów Yum, a następnie musiałem ponownie zainstalować niektóre rozszerzenia PHP, których używałem. Szukając wskazówek, jak rozwiązać ten problem, natknąłem się na to pytanie, a teraz, gdy znalazłem działające rozwiązanie, chciałem się tutaj podzielić swoimi odkryciami. Inne sugestie, które znalazłem w Internecie, w tym usuwanie i ponowna instalacja PECL / PEAR, a nawet moja instalacja PHP nie rozwiązała tego problemu. Wreszcie po dalszych badaniach i przeglądzie kodu źródłowego PECL / PEAR znalazłem prawdziwą przyczynę. Mam nadzieję, że poniższe informacje przydadzą się innym:
Ten błąd może pojawić się podczas próby uruchomienia PECL, jeśli instalacja PHP nie ma domyślnie włączonej obsługi XML, ale zamiast tego obsługa XML jest zwykle ładowana do instalacji PHP za pośrednictwem modułu rozszerzającego PHP (może to wystąpić, jeśli ./configure --disable-xmlflaga została podana podczas budowania PHP ze źródła lub jeśli zainstalowałeś PHP za pomocą różnych menedżerów pakietów, w których ta wersja PHP jest skonfigurowana do ładowania XML poprzez moduł rozszerzeń).
Zwróć uwagę, jak wygląda ostatni wiersz wyniku błędu z PECL XML Extension not found- przyczyną tego błędu jest to, że gdy PECL próbuje użyć swojej klasy XMLParser.php, nie udaje mu się, ponieważ nie może uzyskać dostępu do rozszerzenia XML (sprawdza moduł XML za pomocą extension_loaded('xml')linii wokół 259 źródła XMLParser.php), a ponieważ moduł XML jest niedostępny, nie może przeanalizować plików konfiguracji / ustawień i wyświetla wszystkie pozostałe błędy widoczne powyżej.
Przyczyną tego problemu jest sposób działania PECL. Sama komenda PECL jest po prostu skryptem powłoki, który najpierw sprawdza, gdzie PHP jest instalowany w instalacji systemu, a następnie wywołuje PHP w wierszu poleceń z wieloma flagami, zanim poda ścieżkę do głównego pliku skryptu PECL PHP. Flaga problemu, której używa skrypt powłoki PECL, jest -nopcją, która nakazuje PHP zignorować dowolne php.inipliki (a zatem PHP nie załaduje żadnego z dodatkowych rozszerzeń php.iniokreślonych przez plik, w tym w tym przypadku XML).
Wpływ -nflagi można zobaczyć, uruchamiając następujące dwa polecenia:
- najpierw spróbuj uruchomić
php -mw wierszu polecenia
- następnie porównaj dane wyjściowe z
php -n -m
Nie powinieneś widzieć rozszerzenia XML na liście po uruchomieniu drugiego polecenia, ponieważ -nflaga nakazała PHP nie analizować naszych php.iniplików.
Jeśli uruchomisz vi `which pecl`w wierszu poleceń, powinieneś zobaczyć zawartość polecenia PECL (jak wspomniano powyżej, to tylko skrypt powłoki), a jeśli przejrzysz ostatni wiersz, zobaczysz coś takiego:
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 "$@"
Powinieneś zobaczyć -nflagę wymienioną pomiędzy flagami -Ci -q. Jeśli edytujesz skrypt powłoki PECL, pomijając -nflagę, powinieneś być w stanie ponownie uruchomić PECL bez problemów.
Alternatywnie można ponownie skompilować PHP ze źródła, upewniając się, że moduł XML jest skompilowany do pliku binarnego PHP, zamiast być ładowanym z modułu rozszerzającego PHP w czasie wykonywania. Oczywiście edytowanie skryptu powłoki PECL w celu usunięcia -nflagi naprawi problem tylko do momentu ponownej instalacji PECL / PEAR, ale mam nadzieję, że opiekunowie PECL / PEAR mogą zaktualizować swoje repozytorium za pomocą tej poprawki. Zapewnienie, że PHP jest wbudowane ze skompilowaną obsługą XML, jest jednak długoterminowym rozwiązaniem tego rozwiązania, ale może nie być idealne w każdych okolicznościach.
Dla kompletności, jeśli uruchomisz vi `which pear`, zobaczysz bardzo podobny skrypt powłoki do tego, którego używa PECL, jednak -nbrakuje flagi w poleceniu wywołującym PHP i jako takie polecenie PEAR nie podlega tym samym problemom.