Podczas uruchamiania composer diagnosepojawia się następujący błąd:

Wczytane jest rozszerzenie xdebug, co może nieco spowolnić program Composer. Zalecane jest wyłączenie go podczas korzystania z Composera.

Jak mogę wyłączyć xdebug tylko wtedy, gdy używam Composera?

Aktualizacja : problem został rozwiązany w Composer 1.3 . Zaktualizuj kompozytora do najnowszej wersji, wykonując composer self-update, zamiast wypróbować następujące obejście.

Oto moja modyfikacja kodu @ ezzatron. Zaktualizowałem skrypt, aby wykrywał pliki ini z wyjścia phpinfo.

#!/bin/sh

php_no_xdebug () {
    temporaryPath="$(mktemp -t php.XXXX).ini"

    # Using awk to ensure that files ending without newlines do not lead to configuration error
    php -i | grep "\.ini" | grep -o -e '\(/[a-z0-9._-]\+\)\+\.ini' | grep -v xdebug | xargs awk 'FNR==1{print ""}1' | grep -v xdebug > "$temporaryPath"

    php -n -c "$temporaryPath" "$@"
    rm -f "$temporaryPath"
}

php_no_xdebug /usr/local/bin/composer.phar $@
# On MacOS with composer installed using brew, comment previous line
# Install jq by executing `brew install jq` and uncomment following line.
# php_no_xdebug /usr/local/Cellar/composer/`brew info --json=v1 composer | jq -r '.[0].installed[0].version'`/libexec/composer.phar $@

To polecenie wyłączy moduł PHP5 Xdebug dla CLI (a tym samym kompozytor):

sudo php5dismod -s cli xdebug

Usuwa link symboliczny xdebug.ini z/etc/php5/cli/conf.d/

Zasugerowano na http://blog.lorenzbausch.de/2015/02/10/php-disable-xdebug-for-cli/

Zauważ, że w przypadku Ubuntu 16.04 prawdopodobnie musisz go uruchomić w ten sposób:

sudo phpdismod -s cli xdebug

Myślę, że nie ma opcji konfiguracji PHP, aby mógł ładować różne konfiguracje zgodnie z docelowym skryptem. Przynajmniej nie bez powielania plików .ini ...

Możesz jednak dodać te opcje podczas uruchamiania programu Composer z php:

php -n -d extension=needed_ext.so composer.phar

-npowie PHP, aby ignorował wszelkie pliki php.ini. Zapobiegnie to załadowaniu xdebug dla tej samej komendy.

-doptions pozwala na dodanie dowolnej opcji (na przykład uaktywnij required_ext.so). Możesz użyć wielu -dopcji. Oczywiście jest to opcjonalne, możesz tego nie potrzebować.

Następnie możesz utworzyć alias, aby znów był słodki.

Typowe rozwiązanie (ponieważ kompozytor potrzebuje json):

php -n -d extension=json.so composer.phar

greg0ire> moje rozwiązanie oparte na tym:

#!/bin/bash
options=$(ls -1 /usr/lib64/php/modules| \

    grep --invert-match xdebug| \

    # remove problematic extensions
    egrep --invert-match 'mysql|wddx|pgsql'| \

    sed --expression 's/\(.*\)/ --define extension=\1/'| \

    # join everything together back in one big line
    tr --delete '\n'
)

# build the final command line
php --no-php-ini $options ~/bin/composer $*

alias composer=/path/to/bash/script.sh

Wygląda brzydko (próbowałem i nie udało mi się tego zrobić z xargs), ale działa… Musiałem jednak wyłączyć niektóre rozszerzenia, w przeciwnym razie otrzymuję następujące ostrzeżenia:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysqlnd_connect in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_pgsql.so' - /usr/lib64/php/modules/pdo_pgsql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/wddx.so' - /usr/lib64/php/modules/wddx.so: undefined symbol: php_XML_SetUserData in Unknown on line 0

Tworząc alias, pominiesz ten composer xdebugkomunikat o błędzie.

Po prostu dodaj tę linię do ~/.bash_aliasesswojego systemu i powinna działać bezbłędnie.

alias composer="php -n /usr/local/bin/composer"

Załaduj ponownie powłokę, aby udostępnić nowy alias composer.

source ~/.bash_profile

STOSOWANIE:

$ composer --version

UWAGA:
Nie musisz koniecznie używać żadnego innego parametru.
W zależności od systemu możesz mieć .bashrczamiast .bash_profile.

AKTUALIZACJA:

Jak @AlexanderKachkaev wspomina w komentarzach, nie warto dodawać parametru memory_limit w następujący sposób, aby uniknąć awarii w niektórych sytuacjach:

alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"

Wymyśliłem odpowiedź, która działa całkiem nieźle na OSX i prawdopodobnie mogłaby zostać dostosowana do dowolnej wersji PHP, która ładuje swoje rozszerzenia przy użyciu pojedynczych plików .ini w "dodatkowym katalogu ini":

#!/bin/sh

function php-no-xdebug {
    local temporaryPath="$(mktemp -t php-no-debug)"

    find /opt/local/etc/$1/php.ini /opt/local/var/db/$1/*.ini ! -name xdebug.ini | xargs cat > "$temporaryPath"
    php -n -c "$temporaryPath" "${@:2}"
    rm -f "$temporaryPath"
}

alias composer="php-no-xdebug php56 ~/bin/composer"

Zwykle tworzę skrypt powłoki na projekt, ponieważ każdy projekt ma inną wersję PHP. Jest w /bin/katalogu obok composer.phari composer.jsoni uruchomić go jak ./bin/composerw moim katalogu projektu.

Wygląda to tak (dla php56)

#!/bin/sh
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

COMPOSER_DISABLE_XDEBUG_WARN=1 /opt/local/bin/php56 \
    -d xdebug.remote_enable=0 -d xdebug.profiler_enable=0 \
    -d xdebug.default_enable=0 $DIR/../composer.phar "$@"

Te -dopcje skutecznie wyłączyć xdebug. Ta COMPOSER_DISABLE_XDEBUG_WARN=1część wyłącza ostrzeżenie o problemach z kompozytorem.

Preferowane jest wyłączenie rozszerzenia xdebug (zobacz rozwiązywanie problemów z kompozytorem ), ale osobiście podoba mi się prostszy skrypt.

Niektóre czasy na moim komputerze: 2 Uruchom z xdebug i włączoną obsługą ini: 1m33

Uruchom z xdebug, ale ini-wyłączone: 0m19

Uruchom bez xdebug: 0m10

Jeśli używasz PHPStorm, najnowsza wersja (2016.2) zawiera funkcję włączania XDebug dla skryptów CLI na żądanie, co oznacza, że ​​możesz po prostu wyłączyć XDebug globalnie na swoim komputerze deweloperskim. IDE włączy go w locie, gdy będzie to wymagane przez kod wewnątrz twoich projektów.

https://blog.jetbrains.com/phpstorm/2016/06/xdebug-on-demand-for-cli-php-scripts-in-phpstorm-2016-2-eap/

PhpStorm 2016.2 wprowadza tryb Xdebug On Demand, w którym możesz wyłączyć Xdebug dla swojej globalnej instalacji PHP, a PhpStorm włączy go tylko wtedy, gdy będzie to konieczne - podczas debugowania skryptów lub gdy potrzebujesz raportów pokrycia kodu.

Musisz edytować preferencje interpreterów PHP, aby uwzględnić ścieżkę do XDebug, jak opisano w powiązanym artykule.

Wydaje mi się, że jest to idealne rozwiązanie, ponieważ zwykle chcę XDebug tylko wtedy, gdy jestem w IDE.

Jednak XDebug ma inne potencjalne zastosowania, gdy jesteś „offline”, np. Rozszerzone zrzuty stosu w dziennikach błędów, które można stracić, wyłączając go globalnie. Oczywiście nie powinieneś mieć włączonego XDebug w środowisku produkcyjnym, więc byłoby to ograniczone do przypadków użycia, takich jak testy beta lub automatyczne testowanie skryptów CLI w fazie rozwoju.

Zamiast mieszać się z tymczasowym włączaniem lub wyłączaniem modułu PHP, gdy możesz mieć współbieżne procesy korzystające z PHP (na przykład jako część potoku CI), możesz powiedzieć PHP, aby wskazał inny katalog ładowania modułu.

Chociaż jest to podobne do niektórych rozwiązań wymienionych powyżej, rozwiązuje to kilka przypadków skrajnych, co jest bardzo przydatne, gdy jest używane przez Jenkinsa lub innego uczestnika CI, który przeprowadza testy na tej samej maszynie jednocześnie.

Najłatwiej to zrobić, używając zmiennej środowiskowej PHP_INI_SCAN_DIR

Używanie tego w skrypcie lub zadaniu kompilacji jest łatwe:

export PHP_INI_SCAN_DIR=/etc/php.d.noxdebug php composer install

Oczywiście najpierw chciałbyś przygotować /etc/php.d.noxdebug, robiąc coś takiego:

mkdir /etc/php.d.noxdebug cp /etc/php.d/* /etc/php.d.noxdebug rm /etc/php.d.noxdebug/xdebug.ini

Oznacza to, że masz środowisko podobne do starego środowiska php, z brakującym tylko jednym modułem. Oznacza to, że nie musisz się martwić koniecznością ładowania modułów phar / json, tak jak w przypadku rozwiązania php -n.

Wymyśliłem rozwiązanie dla instalatora Composera opartego na systemie Windows - powinno działać dla każdej instalacji Composera, po prostu tworzy kopię załadowanego pliku INI i komentuje rozszerzenie zend xdebug, a następnie ładuje ten plik konfiguracyjny po uruchomieniu kompozytora .

Otworzyłem problem, aby sprawdzić, czy chcieliby zintegrować tę zmianę:

https://github.com/composer/windows-setup/issues/58

Znajdziesz tam moje instrukcje i kod.

Jak wspomniano w odpowiedzi Joyce'a , ten problem nie istnieje już w najnowszej wersji Composera.

Dokumentacja Composera została zaktualizowana, aby to uwzględnić . Zawiera szczegółowe informacje, jak włączyć xdebug z Composerem (jeśli jest to wymagane).

Możesz zaktualizować swoją wersję Composera, korzystając z automatycznej aktualizacji .

Na moim Macu musiałem zrobić: sudo php /opt/local/bin/composer self-update

Więcej szczegółów na ten temat w kontekście instalacji Homebrew PHP można znaleźć w tym numerze .

Bezpośrednia manipulacja konfiguracją PHP

Oto mój wkład oparty na instalacji PHP zainstalowanej przez Homebrew w systemie Mac OS X.

Jest to opakowanie skryptu powłoki, zaprojektowane do zapisywania jako plik wykonywalny w /usr/local/bin/composer, z binarnym Composer pod adresem /usr/local/bin/composer.phar:

#!/bin/sh
sed -i '' -e 's:zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
/usr/local/bin/php /usr/local/bin/composer.phar "$@"
sed -i '' -e 's:;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini

teoria operacji

Skrypt opakowania:

• używa seda do tymczasowej modyfikacji pliku konfiguracyjnego, wyłączając Xdebug (linia 2)
• wykonuje Composer, przechodząc przez argumenty do polecenia (wiersz 3)
• używa seda do przywrócenia pliku konfiguracyjnego, ponownie włączając Xdebug (linia 4)

Skrypt jest połączony z instalacją PHP 5.5 w systemie OS X / Homebrew. Ścieżki powinny być dostosowane do pracy z innymi wersjami PHP oraz układami katalogów innych systemów operacyjnych i menedżerów pakietów. Zauważ również, że niektóre wersje seda nie potrzebują argumentu pustego łańcucha po -iopcji.

Caveat Utilitor

Skrypt jest prosty, ponieważ działa bezpośrednio na głównych plikach konfiguracyjnych PHP, jednak jest to również wada: Xdebug zostanie również wyłączony dla wszystkich skryptów wykonywanych jednocześnie z tym skryptem.

W moim środowisku programistycznym jest to akceptowalny kompromis, biorąc pod uwagę, że Composer jest uruchamiany ręcznie i tylko sporadycznie; Jednak możesz nie chcieć używać tej techniki, jeśli uruchamiasz Composer jako część automatycznego procesu wdrażania.

W większości przypadków nie potrzebujesz xdebug w trybie CLI. Jeśli jest to dla ciebie do przyjęcia, możesz inaczej skonfigurować cli i cgi.

Więc jeśli utworzysz php-cli.ini i conf-cli.d w pobliżu wyjścia z pliku php.ini, możesz inaczej skonfigurować cli i cgi (dla cgi będą to php.ini i conf.d ). Po prostu nie umieszczaj xdebug.ini w pliku conf-cli.d.

Jeśli instalujesz narzędzie Composer za pomocą brew na OS X, możesz użyć tego aliasu:

alias composer="php -n $(cat $(which composer) | grep composer.phar | awk '{print $7}')"

Moim szybkim rozwiązaniem dla instalacji macports z wieloma wersjami PHP było napisanie tego prostego opakowania powłoki dla Composera:

/user/local/bin/composer-nodebug.sh

#!/bin/bash

sudo mv /opt/local/var/db/php53/xdebug.ini /opt/local/var/db/php53/xdebug.NOT
sudo mv /opt/local/var/db/php54/xdebug.ini /opt/local/var/db/php54/xdebug.NOT
sudo mv /opt/local/var/db/php55/xdebug.ini /opt/local/var/db/php55/xdebug.NOT
composer $1 $2 $3 $4 $5 $6 $7
sudo mv /opt/local/var/db/php53/xdebug.NOT /opt/local/var/db/php53/xdebug.ini
sudo mv /opt/local/var/db/php54/xdebug.NOT /opt/local/var/db/php54/xdebug.ini
sudo mv /opt/local/var/db/php55/xdebug.NOT /opt/local/var/db/php55/xdebug.ini

Następnie uruchom dowolne polecenia kompozytora, takie jak:

sudo composer-nodebug.sh update

Wady:

• wymaga sudo (chyba że chmodujesz pliki INI)
• jeśli zabijesz go w trakcie modyfikowania plików INI
• będzie wymagać dodania przyszłych wersji PHP.
• gdy działa, wpływa to na inne procesy PHP

Nie eleganckie, ale proste.

Tworzenie aliasu dla kompozytora, aby wyłączyć xdebug i zapobiec błędom pamięci:

Dodaj tę linię do swojego ~ / .bash_profile

alias composer='php -d xdebug.profiler_enable=0 -d memory_limit=-1 /usr/local/bin/composer'

Uruchom ponownie terminal, aby udostępnić nowy alias.

Oto moje szybkie rozwiązanie, aby pozbyć się ostrzeżenia Xdebug w wersji PHP5-cli. Usunąłem obsługę Xdebug dla PHP5-cli w systemie Ubuntu 14.04.

cd /etc/php5/cli/conf.d/

sudo rm 20-xdebug.ini

Koniec z ostrzeżeniem Xdebug w PHP5-cli.