Bis jetzt haben wir viel Boden in Bezug auf die Arbeit mit WordPress und das Debuggen abgedeckt. Dies gilt insbesondere für die Arbeit mit Tools und Plugins, die in WordPress verfügbar sind. Wenn Sie gerade dieser speziellen Serie beitreten, vergewissern Sie sich bitte, dass Sie mit den folgenden Beiträgen auf dem Laufenden sind:

• Lesen und Verstehen von WordPress-Fehlerprotokollen, Teil 1
• Lesen und Verstehen von WordPress-Fehlerprotokollen, Teil 2
• Grundlegendes Debuggen in WordPress

Denken Sie daran, dass ich im vorherigen Beitrag Folgendes gesagt habe:

Wenn Sie jedoch von Ihrer IDE aus in die Welt des professionellen, praktischen Debuggens einsteigen möchten, ist es wichtig, das Was, Wie und Warum zu verstehen.

Und wir sind endlich bereit, uns anzusehen, was dies erfordert. Um loszulegen, müssen wir jedoch ein paar Dinge über Xdebug und die Terminologie verstehen und eine IDE haben, die für alle, die diese spezielle Serie lesen, konsistent ist.

Das wird also in zwei Teile zerlegt.

• Zuerst sehen wir uns die für das Debugging erforderliche Terminologie an und stellen sicher, dass wir in unserer Entwicklungsumgebung über ein ordnungsgemäßes IDE-Setup verfügen.
• Als nächstes werden wir uns ansehen, wie wir sicherstellen können, dass wir Xdebug richtig installiert haben, und es dann mit unserer Entwicklungsumgebung verbinden, damit wir es zum Laufen bringen können.

Wenn Sie in den letzten Jahren eine Vielzahl von Inhalten in diesem Blog gelesen haben, werden Ihnen einige davon bekannt vorkommen. Wenn nicht, keine große Sache. Denken Sie daran, das Ziel ist sicherzustellen, dass wir alle auf dem gleichen Niveau sind, während wir mit der oben erwähnten Arbeit und dem Rest der Serie fortfahren.

Lassen Sie uns damit beginnen.

Installation von Xdebug, Teil 1

Wie oben erwähnt, wird diese Reihe von Beiträgen einem von zwei Zwecken dienen, die beide kurz beschrieben werden können (der zweite davon wird im nächsten Beitrag beschrieben):

1. Debugging-Terminologie
2. Installation einer IDE

Obwohl viele, die dies lesen, bereits mit einigen Terminologien vertraut sein werden (insbesondere, wenn Sie zuvor clientseitige Tools oder sogar serverseitige Tools verwendet haben) und Sie bereits einen Editor Ihrer Wahl haben, ist es wichtig, sicherzustellen, dass wir es sind zumindest auf einer konsistenten Grundlage arbeiten.

Wenn Sie in Bezug auf Ihre Fähigkeiten in Bezug auf die beiden oben genannten Punkte zuversichtlich sind, wird der nächste Beitrag wahrscheinlich interessanter für Sie sein. Wenn dies auf der anderen Seite für Sie Neuland betritt, sollte es die Grundlage für alles schaffen, was Sie benötigen, um sicherzustellen, dass Sie Projekte in WordPress erfolgreich debuggen.

Darüber hinaus wird sichergestellt, dass Sie über einen konsistenten Satz von Tools verfügen, mit denen Sie arbeiten können, damit wir weiterhin mit einem Standardsatz von Tools voranschreiten können, um die produktivste Entwicklungsumgebung zu erstellen, die möglich ist.

1 Debugging-Terminologie

Abhängig von Ihrem Hintergrund könnten Sie davon ausgehen, dass es zwischen fünf und sieben Begriffe gibt, von denen sich jeder auf das Debuggen bezieht. Ich habe es dann schon in anderen Beiträgen auf dieser Seite skizziert. Allerdings habe ich dies jedes Mal mit einer etwas anderen Herangehensweise an den Inhalt getan.

In diesem Beitrag möchte ich versuchen, dies so genau und präzise wie möglich zu machen, damit es eine konsistente Referenz bietet, die wir in den kommenden Beiträgen (und in der Arbeit) verwenden können. So wie es jetzt aussieht, sind hier die Begriffe, die meiner Meinung nach jeder kennen sollte, wenn es um seinen Debugger geht.

1. Haltepunkte. Diese können als die grundlegenden Blöcke des Debugging betrachtet werden. Einfach ausgedrückt handelt es sich um Stellen im Code, an denen Sie die Ausführung anhalten möchten, damit Sie untersuchen können, was im Code passiert. Vielleicht hat das mit Variablen zu tun; vielleicht hat es mit Funktionen zu tun, vielleicht hat es mit etwas anderem zu tun. Unabhängig davon ist dies wichtig, da Sie dem Programm sagen: “Hey, ich möchte die Ausführung des Programms hier in dieser Zeile stoppen, damit ich den Status des Programms untersuchen kann.”
2. Uhren. Dies sind Funktionsaufrufe, Variablen oder andere Stellen im Code, die so gesetzt werden können, dass wir während der Ausführung buchstäblich sehen können, wie sich Werte ändern. Wenn wir über Funktionen sprechen, könnten wir uns auf die Werte von Argumenten beziehen, wenn sie innerhalb einer Funktion gesetzt und manipuliert werden. Wenn wir über Variablen sprechen, sprechen wir über Variablen; dann sprechen wir über die Werte, die sie zu einem bestimmten Zeitpunkt während der Ausführung des Programms halten. Dies kann der Fall sein, wenn wir einen bestimmten Haltepunkt setzen, oder wenn wir den Code schrittweise durchlaufen und den Status der Variablen während der gesamten Programmausführung im Auge behalten.
3. Starten. Diese Aktion weist den Debugger einfach an, mit der Überwachung des Webservers zu beginnen. Im Wesentlichen behält es alles im Auge, was innerhalb des Programms passiert, und wenn Haltepunkte gesetzt sind, ist es bereit, die Ausführung zu stoppen und uns zu erlauben, einen Blick darauf zu werfen, was mit dem Status des Programms passiert. Sie können technisch gesehen eine Debugging-Sitzung starten und überhaupt nichts tun. Es ist nicht gerade produktiv, aber es ist möglich.
4. Treten Sie ein. Nehmen Sie für einen Moment an, Sie haben einen Haltepunkt direkt über einem Funktionsaufruf oder bei einem Funktionsaufruf gesetzt. Auf diese Weise können wir in die Funktion einsteigen, um den Wert jedes Arguments zu überwachen, wie sie innerhalb der Funktion manipuliert werden, was die Funktion zurückgibt (falls überhaupt) und alles, was innerhalb der Funktion passiert.
5. Treten Sie hinüber. Nehmen Sie andererseits an, dass Sie die Funktion durchlaufen und nicht sicher sind, ob Sie in die Funktion eintauchen möchten. Vielleicht interessieren Sie sich nur für die Werte, die die Funktion zurückgibt, oder für den Zustand des Programms, nachdem die Funktion ausgeführt wurde, aber Sie interessieren sich nicht dafür, was innerhalb der Funktion passiert ist. Im Wesentlichen behandeln Sie es wie eine Blackbox. Das bedeutet es, eine Funktion zu überspringen. Das heißt, Sie lassen die Funktion laufen, ohne sie zu betreten, um zu sehen, wie sie funktioniert.
6. Treten Sie aus. Dieser spezielle Aspekt des Debuggens ist immer dann nützlich, wenn Sie sich in einer Funktion wiederfinden und bereit sind, zur Hauptausführungslinie zurückzukehren, weil Sie alles gesehen haben, was Sie sehen müssen. Vielleicht haben Sie gesehen, wie sich die Werte einer Variablen geändert haben, vielleicht haben Sie gesehen, wie ein Algorithmus genug Arbeit geleistet hat, um zu wissen, dass er getan hat, was Sie wollen. Was auch immer der Fall ist, dies ermöglicht es Ihnen, die Funktion mit dem treffenden Namen zu verlassen und dann in die zu wechseln
7. Hör auf. Genauso wie start den Debugger anweist, auf den Server zu hören, auf Breakpoints zu achten und Informationen über den Fortschritt der Anwendung anzuzeigen, macht stop genau das Gegenteil. Es teilt dem Debugger mit, dass wir mit dem Zuhören, Beobachten und Beobachten des Programmstatus fertig sind. Das bedeutet nicht, dass das Programm stoppt – nur der Debugger. Wenn Sie also damit fertig sind, alle vom Debugger bereitgestellten Informationen zu beachten, sind Sie wahrscheinlich in der Lage, den Debugger zu stoppen.

Eine letzte Anmerkung, die ich machen möchte, ist, dass PHP insofern einzigartig ist, als es eine Vielzahl von öffentlich zugänglichen Variablen wie $_GET , $_POST, $_REQUEST und so weiter anbietet. Auch das sind Variablen, die uns zur Verfügung stehen und die wir beobachten können. Es ist nicht nur auf das beschränkt, was wir in unserem Code geschrieben haben.

Dies ist besonders nützlich, da wir Daten über das Neuladen von Seiten, Ajax-Anforderungen (z. B. während GET- und POST-Aktionen) usw. hinweg betrachten.

2 Installieren von Xdebug

Obwohl es wahrscheinlich aus früheren Posts in dieser Reihe ersichtlich ist, werde ich Visual Studio Code als bevorzugte IDE verwenden. Wenn Sie keine haben, dann ist dies eine, die ich empfehle. Wenn Sie jedoch eine IDE haben, mit der Sie vertraut sind, empfehle ich diese.

• Code ist immer in Entwicklung,
• hat eine aktive Erweiterungsökonomie,
• funktioniert gut mit einer Vielzahl von Sprachen, Tools usw.
• ist leichtgewichtig und spielt gut mit den verschiedenen Dingen, die wir in der WordPress-Entwicklung verwenden können (wie PHP, HTML und JavaScript).

Darüber hinaus bietet Code auch solide Unterstützung für Xdebug. Um sicherzustellen, dass der Debugger ordnungsgemäß installiert ist, müssen wir jedoch sicherstellen, dass wir die Erweiterung mit unserer Installation von PHP installiert haben, dass sie auf unserem gesamten System verfügbar ist und in unserer IDE ausgeführt werden kann. Wir werden uns darum kümmern, aber zuerst müssen wir sicherstellen, dass Xdebug richtig installiert ist.

Xdebug installieren

Die Installation von Xdebug ist einfach. In Ihrer Terminalsitzung müssen Sie den folgenden Befehl ausführen:

Sobald Sie dies getan haben, werden Sie feststellen, dass während der Installation mehrere Dinge im Terminalfenster passieren. Wenn Sie nicht besonders interessiert sind, brauchen Sie sich keine Gedanken darüber zu machen, was es tut, bis Sie zur Eingabeaufforderung zurückkehren.

An diesem Punkt wurde das Xdebug-Modul installiert; Sie müssen PHP jedoch mitteilen, dass es installiert ist und wo es das Modul finden kann.

Um die Erweiterung mit Ihrer aktuellen PHP-Version zu installieren, ist es wichtig zu wissen, welche PHP-Version Sie installiert haben. Wenn Sie einen Paketmanager verwenden, gibt es möglicherweise mehrere Versionen, und Sie müssen der Konfigurationsdatei dieser bestimmten Version mitteilen, wo das Modul zu finden ist.

Umgekehrt, wenn Sie eine einzelne Version installiert haben, müssen Sie einer einzelnen PHP-Version mitteilen, wo sie installiert ist. Zuerst können Sie mit diesem Befehl herausfinden, wo Xdebug im Dateisystem vorhanden ist :

Dann müssen Sie die Konfigurationsdatei für Ihre PHP-Installation aktualisieren. Führen Sie dazu einfach php -v von der Befehlszeile aus und es wird Ihnen sagen, welche Version Sie verwenden. Von hier aus müssen Sie die Initialisierungsdatei für die von Ihnen verwendete PHP-Version finden. Wenn Sie beim Ausführen von php -v so etwas zurückbekommen:

Dies sagt uns, dass wir PHP 7.1.19 ausführen (obwohl Ihre Version variieren kann). Von hier aus wissen wir, dass wir nach einer bestimmten PHP-Konfigurationsdatei für diese Version von PHP suchen müssen. Suchen Sie dazu auf Ihrem System im Verzeichnis /usr/local/etc/php/7.1/ nach php.ini (obwohl die genaue Versionsnummer variieren kann).

Öffnen Sie von dort aus die Datei und fügen Sie dann die folgende Codezeile hinzu:

zend_extension="/usr/local/lib/php/pecl/20160303/xdebug.so"

Dadurch wird PHP mitgeteilt, wo sich Xdebug befindet, damit es in Ihrer Arbeit verwendet werden kann.

Testen der Installation

Um zu überprüfen, ob die Installation korrekt verlaufen ist, können Sie den folgenden Code in Ihrem Terminal ausführen:

Und dann sollten Sie etwas wie die folgende Ausgabe auf dem Bildschirm sehen:

Beachten Sie, dass Sie im obigen Screenshot Folgendes sehen:

mit Xdebug v2.6.0, Copyright (c) 2002-2018, von Derick Rethans

Das bedeutet, dass das Modul installiert wurde und PHP es kennt.

Konfigurieren Ihrer IDE

Im nächsten Beitrag werden wir uns ansehen, wie wir Xdebug in unsere IDE einbinden. Unter der Annahme, dass Sie die Schritte in diesem Beitrag befolgt haben und alles gut gelaufen ist, sollten Sie in Bezug auf die Vorbereitung auf das Debuggen von WordPress-Projekten bereit sein.

Bis wir es jedoch in einer IDE ausgeführt haben, ist es nicht so nützlich (oder es ist schwieriger als es sein muss). Nächste Woche schauen wir uns genau an, wie das geht.