WordPressiga töötades teeb Codex head tööd, näidates, kuidas rakendust silumiseks konfigureerida.
Lühidalt, lisate failile wp-config.php järgmise :
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Saate lisada veel, kuid see on üldine idee, mida ma pean kasulikuks.
Aga milleks seda vaeva näha?
WordPressi silumislogid
Mõnikord tunduvad silumislogi eelised ilmsed. Muul ajal ei pruugi see aga alati selgeks saada, miks see kasulik on.
Me kõik oleme kuulnud vabandust (tõesti kuni punktini, kus see on nali):
Minu masinal töötab.
Kuid me ei tohiks sellest vaikimisi jääda. See võtab vastutuse üle, on tõrjuv ja see ei ole see, kuidas me peaksime tegutsema.
Silumise kiirnõuanne
Sellegipoolest on see enam-vähem kiire näpunäide selle kohta, kuidas ja miks peaksite oma arendus- ja lavastuskeskkondade vahele seadma.
Esiteks, kui teil on silumise seadistus, genereerib see faili debug.log, mida saate alati oma arenduskeskkonnas töötades üle vaadata.
Selle eelised on tavaliselt ilmsed:
- saate oma arvutis viidata PHP teatistele, hoiatustele ja vigadele,
- näete faili ja rida, millel probleem ilmneb,
- saate probleemi ilmnemise ajatempli
Mis siis ikkagi, eks? See on midagi, mida me peaksime iga kohaliku projektiga tegema.
Kuid teie lavastuskeskkonnas on minu arvates samuti oluline veenduda, et silumine on sisse lülitatud. Peaaegu kõik asjad saab samamoodi konfigureerida, kuid kui isegi üks asi on erinev, ei pruugi tarkvara samamoodi töötada.
Ja see on koht, kus ja miks on silumisseade lavastuses samasugune. Sageli võite leida, kus esinevad lahknevused.
Kui teie kood on olemas, siis vastutate nende lahendamise eest. Vastasel juhul näitab see vähemalt, kus on keskkonnaprobleemid – olgu see siis server või kolmanda osapoole tarkvara.