Sviluppo WordPress: aggirare il codice
Se hai seguito la serie finora, probabilmente vedrai quanto può essere utile un corretto debug, specialmente quando lavori su WordPress.
Vale a dire che non solo sei in grado di ottenere preziose informazioni sui tuoi progetti, ma puoi anche vedere come funziona il core di WordPress.
A questo punto, però, non abbiamo fatto molto. Come ricorderai dal post precedente (o se non hai visto lo screencast, ora è un buon momento per farlo), puoi vedere quanto offre il debug.
La verità è che abbiamo appena scalfito la superficie. Come ho detto l’ultima volta, questo post e questo screencast si concentreranno specificamente su quanto segue:
Nel prossimo post, esamineremo le cose più avanzate che possiamo fare come entrare nelle funzioni, uscire dalle funzioni e scavalcare le funzioni.
Non siamo ancora a un punto in cui ci preoccuperemo di modificare al volo i valori delle variabili, ma vedremo sicuramente come possiamo utilizzare strategicamente il debugger per entrare in determinate funzioni, scavalcare determinate funzioni e uscire da determinate funzioni.
Intorno al codice
Prima di condividere lo screencast, voglio definire cosa significa aggirare il codice in un progetto. Sembra qualcosa che facciamo ogni volta che navighiamo nella base di codice.
Ma questo non è vero nel contesto del debug.
Ricorda che ai fini di questa particolare serie, sto utilizzando l’ultima versione di WordPress di Subversion. Puoi rivedere come configurarlo leggendo questo post.
Una parola sui passaggi
Prima di definire i termini imminenti, tieni presente che l’idea di un "passo" durante il debug è analoga all’andare riga per riga attraverso la base di codice.
Come abbiamo visto nel post precedente, l’esecuzione del programma si interromperà non appena viene raggiunto un punto di interruzione. Da lì, il risultato di come procede il programma è lasciato a noi. E con questo come sfondo, definiremo alcuni termini.
- Entrare in una funzione è un’azione che, quando si preme una chiamata di funzione, ti porterà nella funzione. A volte questo è utile, ad esempio se si desidera vedere cosa sta facendo la funzione o vedere come vengono impostati i valori; altre volte, non è necessario se ti interessa solo la funzione in esecuzione o ti interessa solo ciò che restituisce.
- Superare una chiamata di funzione ti consentirà di ignorare l’esecuzione di una funzione nel senso che è ancora in esecuzione, semplicemente non vediamo come funziona effettivamente. Al contrario, il controllo passerà alla riga successiva al termine dell’esecuzione della funzione.
- L’uscita da una funzione viene utilizzata quando sei entrato in una funzione, raggiungi un punto in cui hai finito di valutare il codice e quindi sei pronto per tornare indietro a qualsiasi cosa la codebase farà in seguito. Questo è utile se vuoi scoprire dove potrebbe trovarsi un bug e sospettarlo in una parte del codice (dove potrebbe essere o meno).
E questo è tutto. Se questo è nuovo di zecca, potrebbe sembrare strano o potrebbe essere difficile avvolgerci la testa. Se è così, va bene. È così che va con qualsiasi cosa nuova, giusto?
D’altra parte, se vi capita di conoscere questi termini o di grovigliarne facilmente le definizioni, allora considerate i punti precedenti un ripasso.
E ora uno Screencast
In questo screencast, eseguirò tutte le azioni di cui sopra utilizzando uno dei miei plugin: Estratti più facili. Tuttavia, questo non significa essere alcun tipo di autopromozione. Invece, conosco la base di codice e non devo preoccuparmi di mostrare effettivamente il lavoro che viene svolto per qualcun altro.
Ora che hai visto lo screencast e sai che è strettamente la mia base di codice, puoi scaricare il codice ed eseguire tu stesso tutte le stesse azioni per ottenere un handle su come eseguire le azioni descritte in questo post.
Ciò fornirà ancora più pratica per le tue capacità di debug e dovrebbe rendere più semplice continuare a migliorare le nostre capacità di debug mentre andiamo avanti nel prossimo post.
Avanti il prossimo
Questo è un post un po’ lungo e ho cercato di assicurarmi che tutte le spiegazioni fossero state fornite prima di visualizzare lo screencast. Dopotutto, è molto più facile leggere paragrafi di testo sul contenuto e poi vederlo riprodotto in un breve video piuttosto che avere un video di 15 minuti, vero?
Per quanto utile possa essere, c’è ancora di più. Ed è quello che esamineremo nel prossimo post. In particolare, esamineremo come ispezionare i valori delle variabili, esaminare cosa contiene un array e quindi come modificare le variabili al volo.
È roba potente, ma assicurati di aver esaminato il primo contenuto, di aver esaminato attentamente questo post e di fare un po’ di pratica prima di andare avanti.