Å skrive kode for WordPress og teamkollegaen din fortsetter å be deg «rydde opp i mellomrom og innrykk» ved hver kodegjennomgang? Eller nettstedet ditt krasjer etter en plugin-oppdatering, og du finner ikke feilen i loggene fordi koden ble skrevet uten noen konsekvent standard?

Dette er et kjent scenario for alle som utvikler WordPress i et team. Ulike formateringsvaner, noen bruker Yoda-conditions mens andre ikke gjør det, og escaping av output mangler enkelte steder.

PHP CodeSniffer løser dette automatisk: det sjekker koden din mot WordPress' kodestandarder direkte i editoren, markerer brudd og kan fikse dem med én enkelt kommando. Nedenfor finner du en oppsettsguide fra bunnen av for PhpStorm 2026.

💡 Rask oversikt:

• Installer PHP CodeSniffer og WordPress Coding Standards via Composer, enten i prosjektet ditt eller globalt
• Angi banen til phpcs i konfigurasjonen og legg til WordPress-standarden
• Konfigurer en ekstern PHP-tolker hvis du jobber via Vagrant, Docker eller SSH
• Aktiver inspeksjonen PHP CodeSniffer Validation i PhpStorm, så vil feil bli uthevet direkte
• Sett opp autoformatering gjennom PHP Code Beautifier and Fixer for å fikse kode med én kommando

Steg-for-steg-video på engelsk (samme trinn som i teksten):

Trinn 1: konfigurer en ekstern PHP-tolker

Hvis du utvikler med lokal PHP (XAMPP, MAMP, Local, innebygd server), kan du hoppe over dette trinnet. For Vagrant, Docker eller en ekstern server via SSH må du spesifisere tolkeren eksplisitt.

Åpne Settings → PHP (Ctrl+Alt+S), klikk […] ved siden av CLI Interpreter og velg SSH Credentials eller Docker Compose.

Fyll inn:

• Verts-IP-adresse, den samme som brukes for nettstedet (ping example.dev vil hjelpe)
• vagrant for brukernavn og passord (hvis du bruker Vagrant)
• /usr/bin/php, banen til PHP-filen på serveren

Lagre og velg den opprettede tolkeren fra listen:

PhpStorm vil bruke denne spesifikke PHP-en til å kjøre CodeSniffer og andre kodekvalitetsverktøy.

Trinn 2: installer PHP CodeSniffer via Composer

Den mest pålitelige tilnærmingen er å installere PHPCS som en prosjektavhengighet. Legg til i composer.json:

1
{
2
  "require-dev": {
3
    "squizlabs/php_codesniffer": "^3.10"
4
  }
5
}

Kjør deretter composer install. PhpStorm vil automatisk oppdage phpcs og phpcbf i vendor/bin, slik at du slipper å angi baner manuelt.

For global installasjon (hvis du trenger det på tvers av alle prosjekter):

1
composer global require "squizlabs/php_codesniffer=*"

Bekreft: den kjørbare filen phpcs skal ligge i ~/.composer/vendor/bin/ (Linux/Mac) eller %APPDATA%/Composer/vendor/bin/ (Windows).

Steg 3: installer WordPress Coding Standards

WPCS er et sett med regler (sniffs) for PHPCS som sjekker samsvar spesifikt med WordPress-standarder: output escaping, Yoda conditions, funksjonsprefikser og alt annet fra WordPress Coding Standards Handbook.

Via Composer i prosjektet ditt:

1
composer require --dev wp-coding-standards/wpcs:"^3.0"

Eller globalt (den gamle, velprøvde metoden):

1
composer create-project wp-coding-standards/wpcs:dev-master --no-dev

Forsikre deg om at standarden dukker opp i ~/.composer/wpcs/ eller vendor/wp-coding-standards/wpcs/.

Steg 4: angi sti til standarden i PHPCS-konfigurasjonen

Naviger til phpcs-mappen og spesifiser hvor de installerte standardene befinner seg:

1
cd ~/.composer/vendor/bin
2
phpcs --config-set installed_paths ~/.composer/wpcs

Bekreft at WordPress vises i listen over tilgjengelige standarder:

1
phpcs -i

Utdataene skal vise fire standarder: WordPress, WordPress-Core, WordPress-Docs og WordPress-Extra.

Steg 5: legg phpcs til PATH

Åpne ~/.bash_profile (eller ~/.zshrc for ZSH) og legg til linjen:

1
PATH=$PATH:~/.composer/vendor/bin

Start terminalen på nytt eller kjør source ~/.bash_profile. Nå er phpcs-kommandoen tilgjengelig fra alle mapper.

Test den på en hvilken som helst tema- eller plugin-fil:

1
cd wp-content/themes/your-theme
2
phpcs --standard=WordPress functions.php

Vellykkede utdata ser slik ut:

Feil er delt inn i to nivåer: ERROR for harde brudd og WARNING for anbefalinger. Hver linje inneholder regelnummeret og en beskrivelse av problemet.

Steg 6: konfigurer PHP CodeSniffer i PhpStorm

Åpne Settings → PHP → Quality Tools → PHP_CodeSniffer (Ctrl+Alt+S).

Hvis du installerte via Composer i prosjektet ditt, vil PhpStorm automatisk plukke opp phpcs fra vendor/bin. Hvis den er installert globalt, klikker du […] ved siden av Configuration og angir stien til den kjørbare filen: ~/.composer/vendor/bin/phpcs.

Velg PHP-tolkeren fra listen, den samme som du konfigurerte i steg 1.

Steg 7: aktiver inspeksjonen PHP CodeSniffer Validation

Gå til Settings → Editor → Inspections, utvid PHP → Quality Tools og kryss av for PHP_CodeSniffer validation.

I nedtrekkslisten Coding standard velger du WordPress. Lagre innstillingene.

Fra nå av sjekker PhpStorm åpne PHP-filer fortløpende. Brudd markeres med bølgete understreker, akkurat som vanlige IDE-feil. Hold musepekeren over dem, så vises en verktøytips med en beskrivelse: hva som er galt og hvordan du fikser det.

Steg 8: bekreft at det virker

Opprett eller åpne en hvilken som helst tema-PHP-fil og skriv bevisst kode som bryter standarden:

1
if(true){echo 'Spaces? Never heard of them';}

PhpStorm vil understreke linjen: manglende mellomrom etter if, rundt krøllparenteser og inne i betingelsen. Hold musepekeren over, så ser du feilteksten og WordPress-regelnummeret.

Steg 9: sett opp automatisk retting via PHP Code Beautifier and Fixer

Du trenger ikke å rette hvert brudd manuelt. PHP Code Beautifier and Fixer (phpcbf) installeres sammen med PHPCS og kan automatisk rette kode i henhold til den valgte standarden.

Åpne Settings → PHP → Quality Tools, og velg PHP Code Beautifier and Fixer i seksjonen External Formatters. Når du nå kaller opp Code → Reformat Code (Ctrl+Alt+L / Cmd+Option+L), vil PhpStorm ikke bare justere innrykk med sin egen formatterer, men også anvende WordPress-regler via phpcbf.

Konfigurer i tillegg WordPress-kodestilen for den innebygde formattereren: Settings → Editor → Code Style → PHP → Set From → Predefined Style → WordPress. Da jobber begge verktøyene i samme retning og kommer ikke i konflikt.

Steg 10: hva du gjør for nye prosjekter

For hvert nye WordPress-prosjekt er det bare å gjenta steg 1 (tolk, hvis ekstern), steg 6 (angi phpcs i innstillingene) og steg 7 (aktiver inspeksjon). Bruker du Composer i prosjektet, dekkes steg 2-4 av én enkelt linje: composer require --dev wp-coding-standards/wpcs.

⁉️🤔 Ofte stilte spørsmål

Hva er forskjellen på WordPress, WordPress-Core, WordPress-Docs og WordPress-Extra?

WordPress er grunnsettet med alle regler unntatt dokumentasjon. WordPress-Core inneholder bare regler fra den offisielle kodeveiledningen (innrykk, navngivning, Yoda-betingelser). WordPress-Extra legger til sikkerhetssjekker: escaping av output, validering av inndata. WordPress-Docs sjekker standarder for kodedokumentasjon (PHPDoc). I praksis bruker du WordPress fordi den inkluderer Core og Extra.

PhpStorm finner ikke phpcs etter installasjon. Hva bør jeg gjøre?

Sjekk at mappen vendor/bin (eller ~/.composer/vendor/bin) er lagt til i PATH og inneholder den kjørbare filen phpcs. I PhpStorm åpner du Settings → PHP → Quality Tools → PHP_CodeSniffer, klikker på […] og oppgir banen til phpcs manuelt. Etter bytte av tolk eller reinstallering av avhengigheter kan det hende du må tilbakestille konfigurasjonen med Reset-knappen i samme vindu.

Kan jeg bruke PHPCS uten Composer ved bare å laste ned phar-arkivet?

Ja, men vi anbefaler det ikke. Ved installasjon via Composer fanger PhpStorm automatisk opp phpcs, phpcbf og alle registrerte standarder. Med phar-arkivet må du angi baner manuelt og holde oversikt over oppdateringer separat. For teamsamarbeid låser en Composer-avhengighet i composer.json versjonen slik at alle utviklere har samme regelsett.

Hvordan ekskluderer jeg bestemte filer eller mapper fra sjekking?

Opprett en phpcs.xml-fil i prosjektroten. Du kan ekskludere kataloger (<exclude-pattern>vendor/*</exclude-pattern>), angi standarden og endre alvorlighetsgraden for enkeltregler. PhpStorm vil automatisk plukke opp denne filen hvis den ligger i prosjektroten og heter phpcs.xml eller phpcs.xml.dist.

Hvorfor klager PHPCS på wp_redirect() uten exit?

WordPress-standarden krever exit eller wp_die() etter enhver omdirigering: wp_redirect() setter bare headeren, men stopper ikke kjøringen av skriptet. Uten exit vil kode etter omdirigeringen fortsette å kjøre, noe som er et sikkerhetshull. Riktig bruk: wp_redirect( home_url() ); exit;.

Hva du gjør hvis kodebasen allerede er stor og du nettopp skal innføre standarder

Å kjøre PHPCS på et prosjekt med tusenvis av avvik er en sikker måte å demotivere teamet på. Start i det små: fiks kritiske feil (error, ikke warning) med phpcbf, og senk deretter terskelen gradvis. Legg til en phpcs.xml med ekskluderinger for gammel kode og skru på nye regler én om gangen hver måned.

Her er en trinnvis plan for innføring av standarder på et aktivt prosjekt:

• Kjør phpcs --standard=WordPress --report=summary for å se totalt antall feil.
• Autofiks alt som er mulig: phpcbf --standard=WordPress .
• Sorter gjenværende feil etter alvorlighetsgrad, og ta de kritiske først.
• Legg til sjekking i CI (GitHub Actions, GitLab CI): la bygget feile ved nye avvik i pull requests.

Start med en gratis composer require --dev wp-coding-standards/wpcs i ett prosjekt. Etter en uke vil teamet venne seg til uthevingen. Etter en måned vil de være vant til ren kode. Hvilken kodestandard bruker du? Fortell oss i kommentarfeltet.