WordPress-virheenkorjauslokit ovat tärkeämpiä kuin luulet
Mitä tulee WordPressin kanssa työskentelyyn, Codex tekee hyvää työtä osoittaessaan, kuinka sovellus määritetään virheenkorjausta varten.
Lyhyesti sanottuna lisäät seuraavat tiedostoon wp-config.php :
// 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 );Voit lisätä muitakin, mutta tämä on yleinen ajatus siitä, mitä pidän hyödyllisenä.
Mutta miksi vaivautua peittelemään tätä?
WordPress-virheenkorjauslokit
Joskus virheenkorjauslokin edut näyttävät ilmeisiltä. Toisinaan se ei kuitenkaan välttämättä aina ole selvää, miksi siitä on hyötyä.
Olemme kaikki kuulleet tekosyyn (jossa se on todellakin vitsi):
Toimii koneellani.
Mutta meidän ei todellakaan pitäisi laiminlyödä sitä. Se siirtää vastuun, se on vähättelevää, eikä meidän pitäisi toimia näin.
Pikavihje virheenkorjaukseen
Tämä on kuitenkin enemmän tai vähemmän nopea vinkki siitä, miten ja miksi sinun pitäisi luoda sellainen kehitys- ja lavastusympäristösi väliin.
Ensinnäkin, aina kun sinulla on virheenkorjausasetukset, se luo debug.log- tiedoston, jonka voit tarkastella aina, kun työskentelet kehitysympäristössäsi.
Tämän hyödyt ovat yleensä ilmeisiä:
- voit viitata PHP-ilmoituksiin, varoituksiin ja virheisiin koneessasi,
- näet tiedoston ja rivin, jossa ongelma ilmenee,
- saat aikaleiman, jolloin ongelma ilmenee
Mitä sitten, eikö niin? Tarkoitan, että tämä on jotain, mitä meidän pitäisi tehdä jokaisessa paikallisessa projektissa.
Mutta esitysympäristössäsi on mielestäni myös tärkeää varmistaa, että virheenkorjaus on käytössä. Voit määrittää lähes kaikki asiat samalla tavalla, mutta jos yksikin asia on erilainen, ohjelmisto ei välttämättä toimi samalla tavalla.
Ja tässä ja miksi virheenkorjausasetukset ovat samat lavastusasioissa. Voit usein löytää, mistä erot ovat olemassa.
Jos koodisi on olemassa, sinun on ratkaistava ne. Muuten se paljastaa ainakin, missä ympäristössä on ongelmia – olipa kyseessä sitten palvelin tai kolmannen osapuolen ohjelmisto.