Cum poți depana plugin-uri?
Sunt destul de nou în dezvoltarea de plugin-uri și am avut dificultăți în depanare.
Am folosit multe comenzi echo și este dezordonat și urât.
Sunt sigur că există o metodă mai bună de a face asta, poate un IDE cu un debugger în care pot rula întregul site, inclusiv plugin-ul?

Accesează wp-config.php și modifică define('WP_DEBUG', false);
în define('WP_DEBUG', true);
. De asemenea, instalează plugin-ul Log Deprecated Notices al lui Andrew Nacin.

Aș recomanda să citiți și celălalt articol al lui Nacin: http://www.andrewnacin.com/2010/04/23/5-ways-to-debug-wordpress/

Cu PHP 5.4+ probabil veți fi copleșiți cu notificări E_STRICT. Adăugați acest gist în folderul de plugin-uri și activați-l pentru a elimina notificările Strict, dezactivați-l pentru a reveni la setările normale.

Dacă primești erori afișate, atunci x-debug este o extensie PHP excelentă care adaugă urmărire modernă (backtraces) în PHP.
Dacă încerci să înțelegi ce se întâmplă acolo unde nu există erori, abordarea mea preferată este să definesc o funcție care înregistrează ieșirea într-un fișier. Așa că folosesc plog($variabila) și aceasta apare în fișierul de log pe care îl pot examina ulterior. Acest lucru este util în special atunci când încerci să afli ce s-a întâmplat înainte de apelul header(), sau în alte situații în care nu poți afișa la STDOUT.

Folosește xdebug + NetBeans IDE. Când este configurat complet - ceea ce este ușor de făcut - poți seta puncte de întrerupere în plugin-ul tău și poți urmări variabilele la aceste puncte. Cred că este cea mai bună metodă de a depan plugin-uri sau orice aplicații PHP în general.

După ce am experimentat cu mai multe IDE-uri, am rămas la vechiul și bunul Notepad++ cu o schemă de culori pentru evidențierea sintaxei ultra-personalizată.
Am configurat o macrocomandă astfel încât, când apăs Shift-Ctrl-X, următorul cod este inserat în poziția cursorului:
echo "<pre>";
var_dump($);
echo "</pre>";
exit();
Este simplu, dar în general pot depista 90% dintre bug-uri cu această macrocomandă plus WP_DEBUG activat.

Depanez în stil vechi, folosind error_log()
și var_dump()
. Consider că este cea mai eficientă metodă pentru mine. Am câteva funcții helper pentru a gestiona diferite tipuri de date, deoarece folosirea error_log()
cu array-uri și obiecte poate fi dificilă. De asemenea, folosirea print_r()
poate fi greu de citit când nu este încadrată într-un <pre>
. Am tj_log()
pentru jurnalizarea erorilor și tj()
pentru afișarea output-ului (care practic afișează orice tip de date într-un mod prezentabil):
function tj( $code ) {
?>
<style>
.tj_debug { word-wrap: break-word; white-space: pre; text-align: left; position: relative; background-color: rgba(0, 0, 0, 0.8); font-size: 11px; color: #a1a1a1; margin: 10px; padding: 10px; margin: 0 auto; width: 80%; overflow: auto; -moz-box-shadow:0 10px 40px rgba(0, 0, 0, 0.75); -webkit-box-shadow:0 10px 40px rgba(0, 0, 0, 0.75); -moz-border-radius: 5px; -webkit-border-radius: 5px; text-shadow: none; }
</style>
<br /><pre class="tj_debug">
<?php
if ( is_null( $code ) || is_string($code) || is_int( $code ) || is_bool($code) || is_float( $code ) ) :
var_dump( $code );
else :
print_r( $code );
endif;
echo '</pre><br />';
}
function tj_log( $code ) {
if ( is_null( $code ) || is_string($code) || is_int( $code ) || is_bool($code) || is_float( $code ) ) :
$code = var_export( $code, true );
else :
$code = print_r( $code, true );
endif;
error_log( $code );
}
Așadar, pur și simplu folosesc: tj( $current_user );
sau orice altceva.

Am scris o mică clasă pentru a crea un fișier de jurnal, care este foarte utilă atunci când depanăm apeluri ajax.
http://github.com/hunk/Magic-Fields/blob/master/tools/debug.php
Tot ce trebuie să faci este ceva de genul:
Debug::log("Acesta este un mesaj de depanare");
Când acea linie este executată, mesajul va fi adăugat în fișierul de jurnal și după aceea poți folosi comanda tail (dacă folosești un sistem de operare de tip Unix)
tail -f mylogfile.log
De asemenea, poți transmite acestei funcții un array sau un obiect.
Notă trebuie să modifici linia 20 pentru a specifica calea unde dorești să salvezi fișierul tău de jurnal.

Eu folosesc Aptane IDE pe Linux și UltraEdit pe Windows, iar acesta din urmă are și un analizor PHP. De asemenea, vizualizez toate sugestiile din xDebug cu constanta WP_DEBUG
definită în wp-config.php
.
Vezi și articolul meu pe această temă și nu ezita să comentezi și să îmi dai feedback despre instrumentele tale de dezvoltare.

Vă recomand să încercați FirePHP. Puteți trimite informații de depanare către Firebug din Firefox prin intermediul antetelor HTTP, ceea ce oferă de obicei un rezultat mai curat la depanare.

Nu-i rău deloc: Eclipse. Este aproape de PhpStorm + gratuit.

Există două IDE-uri pe care le pot recomanda și pe care le-am folosit intensiv: PhpED (doar pentru Windows) și PhpStorm+XDEBUG (Mac, Windows și Linux). Acum sunt pe Mac, așa că pot folosi doar ultimul.
Ambele sunt EXCELENTE! Vestea bună este că PhpStorm costă $49 până în septembrie 2010 și doar $99 după aceea. Dacă aș fi pe Windows și ar trebui să aleg din nou, nu sunt sigur pe care l-aș alege.
Sincer, nu pot să nu simt că orice dezvoltator de plugin-uri care nu folosește unul dintre aceste două instrumente este sever dezavantajat, mai ales dacă este relativ nou în dezvoltarea de plugin-uri WordPress.

Krumo - clasa de depanare PHP stilizată
Un alt lucru foarte util este clasa PHP "krumo". Este implementată în ½ minut și oferă o modalitate ușoară de a depană diverse tipuri de variabile:
- obiecte,
- array-uri,
- șiruri de caractere/numere flotante/întregi/etc.
În plus, ajută cu urmărirea apelurilor, afișează clasele încărcate sau fișierele incluse și multe altele la cerere.
Și cel mai important - este GRATUIT!
Descărcare
Krumo @sourceforge

Folosesc un plugin de $13 numit LogPress pe care îl poți cumpăra pe ThemeForest și este o adevărată minune. Poți depana tot ce ține de plugin-urile și site-ul lor. Suportă logare în consola Firebug și multe altele. Nu mai pot trăi fără el, atât de mult îl folosesc.
Acest plugin este probabil cea mai bună investiție pe care am făcut-o vreodată și mi-a economisit nenumărate ore în dezvoltarea de plugin-uri pentru Wordpress.

Uau, am primit voturi negative pentru că am recomandat un plugin plătit cu care nu am nicio legătură? Nu e puțin cam dur, nu-i așa?

Nu eu sunt cel care votează negativ, dar nu sunt surprins. Folosești cuvinte ca și cum ai încerca să vinzi pluginul. A recomanda lucruri este în regulă, dar să forțezi vânzarea cu expresii de genul „adevărată minune divină”. Oamenii urăsc reclamele. Doar mai temperează limbajul și recomandarea va vorbi de la sine.

Folosesc phpED și xdebug, dar pentru mine (și se pare că și pentru alții) este imposibil să debughez fișierele plugin-urilor sau ale temei! Debugger-ul se oprește doar la punctele de întrerupere care sunt în fișierele principale sau originale din "core"! Cineva mă poate ajuta?

În primul rând, adaug define('WP_DEBUG', false);
în fișierul wp-config.php (așa cum au menționat majoritatea oamenilor) la instalarea mea locală, care este o copie recentă a unui site de producție relevant (atât fișiere, cât și date). Acest lucru face totul rapid, sigur, separat, dar reflectă bine cel puțin un loc în care plugin-ul va fi folosit efectiv.
De asemenea, adaug plugin-ul Debug Bar împreună cu unele dintre extensiile Debug Bar (de exemplu, Transients) - după cum se potrivește pentru plugin-urile tale.
De asemenea, folosesc extensia Firebug pentru Firefox, care este excelentă pentru a ajuta la identificarea problemelor legate de HTML, CSS și JavaScript, precum și pentru a analiza ciudățeniile de layout.
Codez folosind UltraEdit, pe care l-am folosit timp de peste 15 ani pentru o mulțime de tipuri de codare (de la PHP până la SQL), atât la serviciu, cât și acasă, așa că acest lucru funcționează bine pentru mine, dar poate nu are suficiente funcționalități pentru a fi considerat un IDE pentru mulți oameni. Are evidențierea sintaxei, completarea automată și funcții de aranjare a codului, precum și o serie de instrumente rapide pentru HTML și CSS care pot ajuta la evitarea greșelilor de tipar și altele asemenea. În principal, îmi aduce familiaritate, care este un aspect important adesea neglijat în graba după lucruri noi. Memoria musculară ajută la repetabilitate chiar și în codare.
Și, desigur, de obicei am deschisă o pagină relevantă din codex într-un alt tab, ca exemplu potrivit.
Toate acestea ajută în diferite moduri să evidențieze erorile de codare, parsare, funcționalitate și layout și nu interferează prea mult cu modul în care codez sau dacă nu este nimic în neregulă. Majoritatea pot fi ignorate sau dezactivate pentru un timp dacă experimentezi sau lucrezi la ceva pe care îl vei revizui mai târziu.
Ah, și nu este nimic în neregulă cu un echo
sau print_r
bine poziționat pentru a verifica ceva la un moment cheie (atâta timp cât le elimini când ai terminat).

Consultă plugin-ul Query Monitor combinat cu Query Monitor Extend pentru depanare completă în WordPress (erori/notificări/avertismente PHP, interogări la baza de date, căi, constante, cereri HTTP, transienti, variabile de sesiune, dump-uri de variabile).
De asemenea, verifică plugin-urile All Post Meta și Saving What pentru informații specifice despre postări.

Pur și simplu accesează site-ul lor de ajutor: https://www.jetbrains.com/help/phpstorm/2016.2/configuring-xdebug.html
