Installazione di Xdebug, Parte 1: Il modulo Xdebug

Ormai, abbiamo coperto molte cose relative al lavoro con WordPress e al debug. E questo è particolarmente vero per quanto riguarda il lavoro con strumenti e plug-in disponibili all’interno di WordPress. Se ti stai appena unendo a questa serie particolare, assicurati di essere aggiornato con i seguenti post:

• Lettura e comprensione dei log degli errori di WordPress, parte 1
• Lettura e comprensione dei log degli errori di WordPress, parte 2
• Debug di base all’interno di WordPress

Nel post precedente, ricorda che ho detto quanto segue:

Ma se stai cercando di entrare nel mondo del debug pratico e professionale dall’interno del tuo IDE, allora è importante capire cosa, come e perché.

E siamo finalmente pronti a vedere cosa richiede. Per iniziare, tuttavia, significa che dobbiamo capire alcune cose su Xdebug, la terminologia e avere un IDE coerente per tutti coloro che leggono questa particolare serie.

Quindi questo sarà suddiviso in due parti.

• Innanzitutto, esamineremo la terminologia richiesta per il debug e ci assicureremo di avere una configurazione IDE adeguata nel nostro ambiente di sviluppo,
• Successivamente, esamineremo come assicurarci di aver installato correttamente Xdebug e quindi collegarlo al nostro ambiente di sviluppo in modo da poterlo mettere in funzione.

Se hai letto una varietà di contenuti in questo blog negli ultimi anni, alcuni di questi potrebbero sembrare familiari. Se no, niente di grave. Ricorda che l’obiettivo è assicurarci che siamo tutti sullo stesso livello mentre procediamo con il lavoro sopra menzionato e per tutto il resto della serie.

Detto questo, iniziamo.

Installazione di Xdebug, parte 1

Come accennato in precedenza, questo insieme di post servirà a uno dei due scopi che possono essere entrambi descritti succintamente (il secondo dei quali sarà descritto nel prossimo post):

1. Terminologia di debug
2. Installazione di un IDE

Anche se molti che stanno leggendo questo avranno già familiarità con parte della terminologia (soprattutto se hai già utilizzato strumenti lato client o anche strumenti lato server) e hai già un editor di scelta, è importante assicurarsi di essere almeno lavorando con una base coerente.

Se sei sicuro delle tue capacità nei due punti sopra menzionati, è probabile che il prossimo post sarà più interessante per te. Se, d’altra parte, questo sta entrando in un nuovo territorio per te, dovrebbe gettare le basi per tutto ciò di cui hai bisogno per assicurarti di eseguire correttamente il debug dei progetti in WordPress.

Inoltre, si assicurerà di disporre di un insieme coerente di strumenti con cui lavorare in modo da poter continuare a portare avanti un insieme standard di strumenti per creare l’ambiente di sviluppo più produttivo possibile.

1 Terminologia di debug

A seconda del tuo background, potresti affermare che ci sono da cinque a sette termini ciascuno dei quali è correlato al debug. Ho delineato poi prima in altri post su questo sito. Ogni volta, tuttavia, l’ho fatto con un approccio un po’ diverso al contenuto.

In questo post, miro a cercare di renderlo il più accurato e preciso possibile in modo che fornisca un riferimento coerente che saremo in grado di utilizzare nei post (e nel lavoro) a venire. Allo stato attuale, ecco i termini che penso che tutti dovrebbero conoscere in relazione al proprio debugger.

1. Punti di rottura. Questi possono essere considerati i blocchi fondamentali del debug. In poche parole, sono punti nel codice di cui vuoi sospendere l’esecuzione in modo da poter esaminare cosa sta succedendo nel codice. Forse questo ha a che fare con le variabili; forse ha a che fare con le funzioni, forse ha a che fare con qualcos’altro. Indipendentemente da ciò, questo è importante perché stai dicendo al programma "ehi, voglio interrompere l’esecuzione del programma proprio qui su questa riga in modo da poter indagare sullo stato del programma".
2. Orologi. Si tratta di chiamate di funzione, variabili o altri punti del codice che possono essere impostati in modo tale da poter vedere letteralmente i valori cambiare durante l’esecuzione. Se stiamo parlando di funzioni, allora potremmo riferirci ai valori degli argomenti mentre sono impostati e manipolati all’interno di una funzione. Se parliamo di variabili, parliamo di variabili; quindi stiamo parlando dei valori che mantengono in un dato momento durante l’esecuzione del programma. Questo può essere quando impostiamo un punto di interruzione specifico, oppure può essere ogni volta che passiamo attraverso il codice e teniamo d’occhio lo stato della variabile durante l’esecuzione del programma.
3. Inizia. Questa azione dice semplicemente al debugger di iniziare a monitorare il server web. In sostanza, tiene d’occhio tutto ciò che sta accadendo all’interno del programma e, se vengono impostati punti di interruzione, è pronto a interrompere l’esecuzione e permetterci di dare un’occhiata a ciò che sta accadendo con lo stato del programma. Puoi tecnicamente avviare una sessione di debug e non fare nulla. Non è esattamente produttivo, ma è possibile.
4. Entra. Si supponga per un momento di avere un punto di interruzione impostato appena sopra una chiamata di funzione o su una chiamata di funzione. Questo ci consente di entrare nella funzione per monitorare il valore di ogni argomento, come vengono manipolati all’interno della funzione, cosa restituisce la funzione (se non altro) e tutto ciò che accade all’interno della funzione.
5. Passo oltre. D’altra parte, supponiamo che stai camminando attraverso la funzione e non sei sicuro di voler tuffarti nella funzione. Forse sei interessato solo ai valori che la funzione restituisce o allo stato del programma dopo che la funzione è stata eseguita, ma non sei interessato a cosa è successo all’interno della funzione. In sostanza, lo tratti come una scatola nera. Ecco cosa significa scavalcare una funzione. Cioè, lasci eseguire la funzione senza entrarci per vederla funzionare.
6. Esci. Questo particolare aspetto del debug è utile ogni volta che ti trovi in ​​una funzione e sei pronto per tornare alla linea di esecuzione principale perché hai visto tutto ciò che devi vedere. Forse hai visto cambiare i valori di una variabile, forse hai visto un algoritmo fare abbastanza lavoro per sapere che ha fatto quello che vuoi. In ogni caso, questo ti consentirà di uscire dalla funzione, opportunamente denominata, e quindi di passare al file
7. Fermati. Proprio come start dice al debugger di iniziare ad ascoltare il server, prestare attenzione ai punti di interruzione e visualizzare informazioni sullo stato di avanzamento dell’applicazione, stop fa esattamente l’opposto. Dice al debugger che abbiamo finito di ascoltare, guardare e prestare attenzione allo stato del programma. Questo non significa che il programma si fermi, solo il debugger. Quindi, se hai finito di prestare attenzione a tutte le informazioni fornite dal debugger, è probabile che tu sia in grado di interrompere il debugger.

Un’ultima nota che vorrei fare è che PHP è unico in quanto offre una varietà di variabili accessibili pubblicamente come $_GET , $_POST, $_REQUEST e così via. Queste sono anche variabili a nostra disposizione che possiamo guardare. Non è solo limitato a ciò che abbiamo scritto nel nostro codice.

Ciò è particolarmente utile quando esaminiamo i dati tra i ricaricamenti di pagine, le richieste Ajax (come durante le azioni GET e POST) e così via.

2 Installazione di Xdebug

Sebbene sia probabilmente evidente dai post precedenti di questa serie, utilizzerò Visual Studio Code come IDE preferito. Se non ne hai uno, questo è uno che consiglio. Se, tuttavia, hai un IDE con cui ti senti a tuo agio nell’usare, questo è uno che consiglio.

• Il codice è sempre in fase di sviluppo,
• ha un’economia attiva di estensioni,
• funziona bene con una varietà di linguaggi, strumenti e così via,
• è leggero e funziona bene con le varie cose che potremmo essere utilizzate nello sviluppo di WordPress (come PHP, HTML e JavaScript).

Inoltre, Code ha anche un solido supporto per Xdebug. Per assicurarci che il debugger sia installato correttamente, tuttavia, dobbiamo assicurarci di avere l’estensione installata con la nostra installazione di PHP, che sia disponibile nel nostro sistema e che possa essere eseguita all’interno del nostro IDE. Cercheremo di farlo, ma prima dobbiamo assicurarci che Xdebug sia installato correttamente.

Installazione di Xdebug

Installare Xdebug è facile. Dall’interno della sessione del terminale, dovrai eseguire il seguente comando:

Una volta fatto, noterai che accadono diverse cose all’interno della finestra del terminale durante l’installazione. A meno che tu non sia particolarmente interessato, non devi preoccuparti di cosa sta facendo finché non ti riporta al prompt dei comandi.

A questo punto il modulo Xdebug è stato installato; tuttavia, dovrai dire a PHP che è installato e dove può trovare il modulo.

Per installare l’estensione con la tua versione corrente di PHP, è importante sapere quale versione di PHP hai installato. Se stai usando un gestore di pacchetti, allora potrebbero esserci più versioni e dovrai dire al file di configurazione di quella particolare versione dove trovare il modulo.

Al contrario, se hai una singola versione installata, dovrai indicare a una singola versione di PHP dove è installata. Innanzitutto, puoi trovare dove esiste Xdebug sul file system usando questo comando:

Quindi dovrai aggiornare il file di configurazione per la tua installazione di PHP. Per fare ciò, esegui semplicemente php -v dalla riga di comando e ti dirà quale versione stai utilizzando. Da qui, dovrai individuare il file di inizializzazione per la versione di PHP che stai utilizzando. Se, durante l’esecuzione di php -v, torni con qualcosa del genere:

Questo ci dice che stiamo eseguendo PHP 7.1.19 (sebbene la tua versione possa variare). Da qui, sappiamo cercare un determinato file di configurazione PHP per questa versione di PHP. Per fare ciò, cerca php.ini nella directory /usr/local/etc/php/7.1/ del tuo sistema (sebbene il numero esatto della versione possa variare).

Da lì, apri il file e quindi aggiungi la seguente riga di codice:

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

Questo dirà a PHP dove risiede Xdebug in modo che possa essere utilizzato all’interno del tuo lavoro.

Testare l’installazione

Per verificare che l’installazione sia andata correttamente, puoi eseguire il seguente codice nel tuo terminale:

E poi dovresti vedere qualcosa come il seguente output sullo schermo:

Nota che nello screenshot qui sopra, vedi quanto segue:

con Xdebug v2.6.0, Copyright (c) 2002-2018, di Derick Rethans

Ciò significa che il modulo è stato installato e che PHP ne è a conoscenza.

Configurazione del tuo IDE

Nel prossimo post, esamineremo il collegamento di Xdebug nel nostro IDE. Supponendo che tu abbia seguito i passaggi in questo post e che tutto sia andato bene, dovresti essere a posto per quanto riguarda la preparazione per il debug dei progetti WordPress.

Fino a quando non lo avremo in esecuzione all’interno di un IDE, tuttavia, non è così utile (o è più difficile di quanto dovrebbe essere). Quindi la prossima settimana vedremo esattamente come farlo.