Når et WordPress-prosjekt feiler, er det sjelden én ting som redder dagen. Det er samspillet mellom gode vaner, riktige innstillinger og målrettede verktøy som gjør forskjellen. Denne guiden samler de beste verktøyene for debugging av WordPress-utvikling – fra innebygde konstanter i wp-config.php til proffe profilerings- og overvåkingsplattformer. Målet er enkelt: raskere feilsøk, færre regresjoner og mer forutsigbar ytelse, uansett om de jobber lokalt, på staging eller i produksjon.
Hovedpoeng
- Start debugging av WordPress-utvikling med grunninnstillingene: aktiver WP_DEBUG og WP_DEBUG_LOG, skjul output med WP_DEBUG_DISPLAY=false i produksjon, og styr per miljø med WP_ENVIRONMENT_TYPE.
- Bruk Xdebug for trinnvis debugging i VS Code/PHPStorm (port 9003) og aktiver det kun ved behov via XDEBUG_TRIGGER for minimal overhead.
- For ytelsesproblemer, profiler med Xdebug, Blackfire eller Tideways og prioriter flaskehalser i wall time, I/O og SQL.
- Få rask innsikt med Query Monitor: inspiser SQL, hooks, HTTP/REST og blokker, og bruk SAVEQUERIES kun lokalt for dypdykk.
- Øk sporbarhet med WP-CLI, PHP-error logs og strukturert logging (Monolog/PSR-3), og koble hendelser til deploys via Sentry, New Relic eller logg-aggregering.
- Fullfør debugging av WordPress-utvikling med Chrome DevTools/Lighthouse, Postman/Insomnia, database-EXPLAIN, Redis-inspeksjon og Mailhog/Mailpit + WP Mail Logging.
Byggestenene I WordPress-Feilsøking
WP_DEBUG, WP_DEBUG_LOG Og WP_DEBUG_DISPLAY
De innebygde feilsøkingskonstantene i WordPress er alltid første stopp. WP_DEBUG slår på PHP-notiser, advarsler og deprecated-meldinger, slik at problemer ikke skjules bak blanke skjermer. Kombiner med WP_DEBUG_LOG for å skrive alt til wp-content/debug.log – gull verdt når feil skjer før output eller i cron/CLI. I produksjon bør WP_DEBUG_DISPLAY settes til false for å hindre at sensitive detaljer vises for sluttbrukere, samtidig som loggingen fortsatt fanger alt i bakgrunnen.
SCRIPT_DEBUG, SAVEQUERIES Og WP_ENVIRONMENT_TYPE
SCRIPT_DEBUG tvinger WordPress til å laste ikke-minifiserte JS/CSS, nyttig når kildekart eller minifiserte filer står i veien for feilsøkingen. SAVEQUERIES registrerer SQL-spørringer og kostnader (bruk varsommelig – den er tung og bør aldri stå på i produksjon). WP_ENVIRONMENT_TYPE (f.eks. development, staging, production) gjør det enklere å styre konfig automatisert: vis feil i dev, logg stille i prod, og skreddersy oppførsel pr. miljø.
Step-Debugging Og Profilering Med Xdebug
Oppsett I VS Code/PHPStorm Og Lokale Miljøer
Xdebug er standarden for trinnvis debugging i PHP. I VS Code holder det med PHP Debug-utvidelsen: i PHPStorm er støtte innebygd. I Docker-baserte oppsett må Xdebug 3 konfigureres med xdebug.mode=debug,develop og riktig klientvert. Standard debug-port er 9003. Aktiver debugging bare når det trengs (via XDEBUG_TRIGGER-cookie/param), så unngås overhead for alle requests. Med LocalWP, Lando eller DDEV følger ofte ferdige profiler for rask aktivering.
Breakpoints, Watches, Traces Og Conditional Debugging
Når breakpoint treffer, kan utvikleren steppe gjennom WordPress-kjernen, temaer og plugins, inspisere variabler (watches), og legge til betingelser: «stopp kun når $post->post_type === 'product'». Traces gir kallstakker over tid – spesielt nyttig i hooks/filters hvor kontrollflyten kan være uoversiktlig. Et praktisk mønster er «just-in-time» debugging: slå på Xdebug kun for én URL eller bruker, så slipper teamet å påvirke andre som jobber på samme miljø.
Profilering Med Xdebug Og Alternativer Som Blackfire/Tideways
Når problemet er ytelse, ikke funksjonell feil, er profileringsdata avgjørende. Xdebug-profiler genererer callgrapher som kan analyseres i KCacheGrind/QCacheGrind/Webgrind for å se hvilke funksjoner som brenner CPU-tid. For produksjonsnære analyser uten for mye støy er Blackfire og Tideways mer skånsomme og gir tidsserier, sammenligninger mellom deploys, og fokus på «wall time», I/O og database. Dette gjør det langt lettere å identifisere flaskehalser i plugins, komplekse temaloops eller API-integrasjoner.
Diagnose Med Query Monitor Og Debug Bar
SQL-Spørringer, Hooks, HTTP-Kall Og Blokker
Query Monitor er ofte den raskeste veien til innsikt mens man klikker rundt i admin eller frontend. Den viser alle SQL-spørringer med tidsbruk, kallstack og hvilke komponenter som trigget dem, i tillegg til hooks, HTTP-kall, scripts/stiler og REST-forespørsler. Jobber man med Gutenberg-blokker, er det nyttig å se hvilke datastrømmer og forespørsler som fyres av ved redigering og publisering. Debug Bar gir et enklere panel, men Query Monitor dekker mest for daglig arbeid.
Ytelsesflaskehalser, PHP-Notiser Og Deprecations
Tunge WP_Query-kall, uindekserte meta-spørringer eller dupliserte API-kall blir synlige umiddelbart. Samtidig er deprecations og PHP-notiser lett tilgjengelige, slik at rammeverket holdes oppdatert før neste større PHP/WordPress-oppgradering. Kombiner med SAVEQUERIES lokalt for dypdykk, men slå det av igjen så snart roten til problemet er funnet.
Loggføring Og Feilsporing I Alle Miljøer
WP-CLI, PHP-Error Logs Og Structured Logging (Monolog/PSR-3)
Når feilen kun oppstår i cron, CLI eller bakgrunnsjobber, er WP-CLI uvurderlig: kjør oppgaver manuelt, inspiser output og bruk --debug-flagg for mer verbositet. PHPs egne error-logger, kombinert med WP_DEBUG_LOG, gir kontekst. I større prosjekter lønner det seg å innføre strukturert logging (PSR-3) via Monolog: loggnivåer, korrelasjons-IDer og JSON-format som kan sendes til logg-aggregering.
Overvåking Med Sentry, New Relic Og Log Aggregation
Sentry fanger PHP- og JavaScript-feil med stacktraces, brukerkontekst og release-tags. New Relic APM gir transaksjonstider, databaseoversikt og eksterne avhengigheter i sanntid. For samling og søk i logger er ELK (Elasticsearch/Logstash/Kibana), Grafana Loki eller Datadog vanlige valg. Poenget er det samme: oppdag feil tidlig, få et spor-nummer, og knytt hendelsen til en deploy eller feature toggle.
Frontend, API Og Editor-Debugging
Chrome DevTools, Lighthouse Og Nettverksanalyse
Frontend-feil krever frontend-verktøy. Med Chrome DevTools profileres rendering og scripting, mens Lighthouse måler Core Web Vitals og gir konkrete forslag til forbedringer. Network-panelet avslører trege REST-kall, cache-miss, CORS-feil og aggressive third-party scripts. Bruk Coverage for å finne ubrukte CSS/JS, og Source Maps for å navigere minifiserte bundler.
Gutenberg/React: React DevTools Og Redux DevTools
Gutenberg-editoren er React-basert. React DevTools lar utvikleren inspisere komponenttreet, props og state, og Redux DevTools viser dispatch av actions i @wordpress/data-store. Dette er nyttig når blokk-editoren oppfører seg «magisk», eller når egenutviklede blokker brått mister synk.
REST-API: Postman, Insomnia Og WP-CLI REST
For API-feilsøking er Postman/Insomnia raske å sette opp med miljøvariabler, auth (Application Passwords, OAuth, JWT) og testskript. Valider responser, headere og statuskoder, og sammenlign mot forventet schema. WP-CLI har i tillegg REST-kommandoer som gjør det lett å trigge endepunkter og skripte tester i CI.
Database, Cache Og E-Post
WP-CLI Db, Adminer/PhpMyAdmin Og Query Analyzer
Når databasen er flaskehalsen, er wp db-kommandoer nyttige for eksport/import, søk-og-erstatt og helsesjekk. Adminer/phpMyAdmin gir rask manuell inspeksjon. Bruk EXPLAIN for å avdekke kostbare JOINs og manglende indekser, og verifiser at postmeta/usermeta-spørringer er selektive nok.
Objektcache-Inspeksjon (Redis/Memcached) Og Transients
Objektcache kan være venn eller fiende. Med Redis kan man inspisere nøkler og TTL-er, validere at grupper er persistent, og fange cache-miss. Query Monitor hjelper også med å se cache-treffrate. Rydd opp i transients med WP-CLI (wp transient list/delete) og vurder Redis Object Cache-plugin for produksjonsmiljøer.
Mailhog/Mailpit Og WP Mail Logging
I lokale/staging-miljøer samler Mailhog eller Mailpit alle utgående e-poster slik at det ikke sendes til ekte brukere. Verifiser innhold, headere og vedlegg, og test edge cases (HTML/plain, store vedlegg). I produksjon gir WP Mail Logging sporbarhet når ordre- eller varslingseposter «forsvinner» – perfekt sammen med alarmer i Sentry/New Relic.
Conclusion
Effektiv WordPress-feilsøking er lagdelt: start med WP_DEBUG og gode logger, grav dypere med Xdebug og Query Monitor, og hold produksjon trygg med overvåking og strukturert logging. Sett opp lokale miljøer som speiler produksjon, aktiver verktøy kun når de trengs, og mål ytelse før og etter endringer. Med denne verktøykassen blir feil færre, raskere å finne – og sjeldnere å gjenta.
Ofte stilte spørsmål
Hvordan bruker jeg WP_DEBUG, WP_DEBUG_LOG og WP_DEBUG_DISPLAY riktig for trygg debugging av WordPress-utvikling i produksjon?
Aktiver logging uten å vise feil for brukere: sett WP_DEBUG_LOG til true og WP_DEBUG_DISPLAY til false. Bruk WP_DEBUG kun når du faktisk trenger å fange feil i produksjon, og slå det av etterpå. Styr dette per miljø med WP_ENVIRONMENT_TYPE (development, staging, production) for konsistent og sikker konfigurasjon.
Hva er beste måten å sette opp Xdebug for debugging av WordPress-utvikling i VS Code/PHPStorm?
Installer Xdebug 3 og sett xdebug.mode=debug,develop og port 9003. I containere konfigurer client_host (host.docker.internal eller vertens IP). Aktiver kun ved behov via XDEBUG_TRIGGER (cookie/GET). Bruk VS Code PHP Debug-utvidelsen eller innebygd støtte i PHPStorm, og legg breakpoints i kjerne, temaer og plugins.
Når bør jeg bruke Query Monitor i stedet for Debug Bar i WordPress?
Bruk Query Monitor for dyp innsikt mens du klikker rundt: SQL-spørringer med tidsbruk og kallstack, hooks, HTTP-kall, scripts/stiler og REST-forespørsler – også nyttig for Gutenberg-blokker. Debug Bar er enklere og lettere, men dekker mindre. Til daglig feilsøk er Query Monitor vanligvis raskeste vei til svar.
Hvordan profilerer jeg ytelse i WordPress – Xdebug vs Blackfire/Tideways?
Xdebug genererer detaljerte callgrapher (analyser i KCacheGrind/QCacheGrind/Webgrind), men har høyere overhead – best lokalt. Blackfire og Tideways er mer skånsomme, egner seg nær produksjon, gir tidsserier, sammenligninger mellom deploys og fokus på wall time/I/O/DB. Kombiner for presis debugging av WordPress-utvikling og verifiser forbedringer før/etter.
Hvordan fikser jeg «white screen of death» i WordPress?
Slå på WP_DEBUG_LOG og sjekk wp-content/debug.log og PHP-errorlogg for fatale feil. Deaktiver plugins og bytt til et standardtema via WP-CLI. Øk PHP memory_limit, regenerer .htaccess ved behov, og tøm cache. Når nettstedet er oppe igjen, gjenaktiver komponenter stegvis for å identifisere synderen og rette årsaken.
Påvirker caching debugging av WordPress-utvikling, og hvordan omgår jeg cache trygt?
Ja. Bypass sidecache med ?nocache=1, privat vindu eller midlertidig DONOTCACHE_PAGE. Tøm server-/CDN-cache, deaktiver objektcache-plugins midlertidig og flush Redis/Memcached ved behov. Bruk Query Monitor for å se cache-treffrate. Husk å reaktivere caching etter testen for å bevare ytelse i produksjon.