Skriver du kod för WordPress och din teamkollega ber dig städa upp blanksteg och indentering vid varje kodgranskning? Eller kraschar sajten efter en plugin-uppdatering och du hittar inte felet i loggarna för att koden skrevs utan någon konsekvent standard?

Det här är ett välbekant scenario för alla som utvecklar WordPress i team. Olika formateringsvanor, en del använder Yoda conditions medan andra inte gör det, och output escaping saknas på sina ställen.

PHP CodeSniffer löser detta automatiskt: det kontrollerar din kod mot WordPress kodningsstandarder direkt i editorn, markerar avvikelser och kan åtgärda dem med ett enda kommando. Här är en installationsguide från grunden för PhpStorm 2026.

💡 Snabb översikt:

• Installera PHP CodeSniffer och WordPress Coding Standards via Composer, antingen i ditt projekt eller globalt
• Ange sökvägen till phpcs i konfigurationen och lägg till WordPress-standarden
• Konfigurera en fjärrstyrd PHP-tolk om du arbetar via Vagrant, Docker eller SSH
• Aktivera inspektionen PHP CodeSniffer Validation i PhpStorm, så markeras fel direkt
• Ställ in autoformatering via PHP Code Beautifier and Fixer för att fixa kod med ett enda kommando

Steg-för-steg-video på engelska (samma steg som i texten):

Steg 1: konfigurera en fjärrstyrd PHP-tolk

Om du utvecklar med lokal PHP (XAMPP, MAMP, Local, inbyggd server), hoppa över detta steg. För Vagrant, Docker eller en fjärrserver via SSH behöver du ange tolken explicit.

Öppna Settings → PHP (Ctrl+Alt+S), klicka på […] bredvid CLI Interpreter och välj SSH Credentials eller Docker Compose.

Fyll i:

• Värdens IP-adress, samma som används för sajten (ping example.dev hjälper dig)
• vagrant som användarnamn och lösenord (om du använder Vagrant)
• /usr/bin/php, sökvägen till PHP-körfilen på servern

Spara och välj den skapade tolken från listan:

PhpStorm kommer att använda just denna PHP för att köra CodeSniffer och andra kodkvalitetsverktyg.

Steg 2: installera PHP CodeSniffer via Composer

Det mest pålitliga sättet är att installera PHPCS som ett projektberoende. Lägg till i din composer.json:

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

Kör sedan composer install. PhpStorm upptäcker automatiskt phpcs och phpcbf i vendor/bin, så du slipper ange sökvägar manuellt.

För global installation (om du behöver det i alla projekt):

1
composer global require "squizlabs/php_codesniffer=*"

Kontrollera: den körbara filen phpcs ska finnas i ~/.composer/vendor/bin/ (Linux/Mac) eller %APPDATA%/Composer/vendor/bin/ (Windows).

Steg 3: installera WordPress Coding Standards

WPCS är en uppsättning regler (sniffs) för PHPCS som kontrollerar efterlevnad specifikt mot WordPress standarder: output escaping, Yoda conditions, funktionsprefix och allt annat från WordPress Coding Standards Handbook.

Via Composer i ditt projekt:

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

Eller globalt (den gamla beprövade metoden):

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

Se till att standarden finns i ~/.composer/wpcs/ eller vendor/wp-coding-standards/wpcs/.

Steg 4: ange sökvägen till standarden i PHPCS-konfigurationen

Navigera till phpcs-mappen och ange var de installerade standarderna finns:

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

Kontrollera att WordPress visas i listan över tillgängliga standarder:

1
phpcs -i

Utdata ska visa fyra standarder: WordPress, WordPress-Core, WordPress-Docs och WordPress-Extra.

Steg 5: lägg till phpcs i PATH

Öppna ~/.bash_profile (eller ~/.zshrc för ZSH) och lägg till raden:

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

Starta om terminalen eller kör source ~/.bash_profile. Nu är kommandot phpcs tillgängligt från vilken mapp som helst.

Testa det på valfri tema- eller plugin-fil:

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

Lyckad utdata ser ut så här:

Fel delas in i två nivåer: ERROR för hårda överträdelser och WARNING för rekommendationer. Varje rad innehåller regelnumret och en beskrivning av problemet.

Steg 6: konfigurera PHP CodeSniffer i PhpStorm

Öppna Settings → PHP → Quality Tools → PHP_CodeSniffer (Ctrl+Alt+S).

Om du installerade via Composer i ditt projekt kommer PhpStorm automatiskt att hitta phpcs från vendor/bin. Om den installerades globalt, klicka på […] bredvid Configuration och ange sökvägen till den körbara filen: ~/.composer/vendor/bin/phpcs.

Välj PHP-tolken från listan, samma som du konfigurerade i steg 1.

Steg 7: aktivera inspektionen PHP CodeSniffer Validation

Gå till Settings → Editor → Inspections, expandera PHP → Quality Tools och markera PHP_CodeSniffer validation.

I rullgardinsmenyn Coding standard väljer du WordPress. Spara inställningarna.

Från och med nu kontrollerar PhpStorm öppna PHP-filer i realtid. Regelbrott markeras med vågiga understrykningar, precis som vanliga IDE-fel. Håll muspekaren över dem så visas en tooltip med en beskrivning: vad som är fel och hur du åtgärdar det.

Steg 8: kontrollera att det fungerar

Skapa eller öppna en valfri PHP-fil i temat och skriv kod som avsiktligt bryter mot standarden:

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

PhpStorm kommer att stryka under raden: mellanslag saknas efter if, runt klammerparenteserna och inuti villkoret. Håll muspekaren över så ser du feltexten och WordPress regelnummer.

Steg 9: ställ in automatisk rättning via PHP Code Beautifier and Fixer

Du behöver inte rätta varje regelbrott manuellt. PHP Code Beautifier and Fixer (phpcbf) installeras tillsammans med PHPCS och kan automatiskt rätta kod enligt den valda standarden.

Öppna Settings → PHP → Quality Tools, och under External Formatters väljer du PHP Code Beautifier and Fixer. När du nu anropar Code → Reformat Code (Ctrl+Alt+L / Cmd+Option+L) kommer PhpStorm inte bara att justera indentering med sin egen formaterare utan också tillämpa WordPress regler via phpcbf.

Konfigurera dessutom WordPress kodstil för den inbyggda formateraren: Settings → Editor → Code Style → PHP → Set From → Predefined Style → WordPress. På så sätt arbetar båda verktygen i samma riktning och krockar inte.

Steg 10: vad du gör för nya projekt

För varje nytt WordPress-projekt behöver du bara upprepa steg 1 (tolk, om fjärransluten), steg 6 (ange phpcs i inställningarna) och steg 7 (aktivera inspektionen). Om du använder Composer i ditt projekt täcks steg 2-4 av en enda rad: composer require --dev wp-coding-standards/wpcs.

⁉️🤔 Vanliga frågor

Vad är skillnaden mellan WordPress, WordPress-Core, WordPress-Docs och WordPress-Extra?

WordPress är basuppsättningen med alla regler utom dokumentation. WordPress-Core innehåller bara regler från den officiella kodguiden (indentering, namngivning, Yoda conditions). WordPress-Extra lägger till säkerhetskontroller: escaping av utdata, validering av indata. WordPress-Docs kontrollerar standarder för koddokumentation (PHPDoc). I praktiken använder du WordPress eftersom den inkluderar Core och Extra.

PhpStorm hittar inte phpcs efter installation. Vad ska jag göra?

Kontrollera att mappen vendor/bin (eller ~/.composer/vendor/bin) är tillagd i PATH och innehåller den körbara filen phpcs. I PhpStorm öppnar du Settings → PHP → Quality Tools → PHP_CodeSniffer, klickar på […] och anger sökvägen till phpcs manuellt. Efter byte av interpretator eller ominstallation av beroenden kan du behöva återställa konfigurationen med knappen Reset i samma fönster.

Kan jag använda PHPCS utan Composer genom att bara ladda ner phar-arkivet?

Ja, men vi rekommenderar det inte. Vid installation via Composer hittar PhpStorm automatiskt phpcs, phpcbf och alla registrerade standarder. Med phar-arkivet måste du ange sökvägar manuellt och hålla koll på uppdateringar separat. För teamsamarbete låser ett Composer-beroende i composer.json versionen så att alla utvecklare har samma regeluppsättning.

Hur exkluderar jag specifika filer eller mappar från kontroll?

Skapa en phpcs.xml-fil i projektroten. Du kan exkludera kataloger (<exclude-pattern>vendor/*</exclude-pattern>), ange standard och ändra allvarlighetsgrad för enskilda regler. PhpStorm hittar automatiskt denna fil om den ligger i projektroten och heter phpcs.xml eller phpcs.xml.dist.

Varför klagar PHPCS på wp_redirect() utan exit?

WordPress-standarden kräver exit eller wp_die() efter varje omdirigering: wp_redirect() sätter bara headern men stoppar inte skriptkörningen. Utan exit fortsätter kod efter omdirigeringen att köras, vilket är ett säkerhetshål. Korrekt användning: wp_redirect( home_url() ); exit;.

Vad du ska göra om din kodbas redan är stor och du precis börjar införa standarder

Att köra PHPCS på ett projekt med tusentals överträdelser är ett säkert sätt att demotivera teamet. Börja smått: åtgärda kritiska fel (error, inte warning) med phpcbf, sänk sedan tröskeln gradvis. Lägg till en phpcs.xml med undantag för äldre kod och aktivera nya regler en i taget varje månad.

Här är en steg-för-steg-plan för att införa standarder i ett aktivt projekt:

• Kör phpcs --standard=WordPress --report=summary för att se det totala antalet fel.
• Autofixa allt som går: phpcbf --standard=WordPress .
• Sortera kvarvarande fel efter allvarlighetsgrad och ta itu med de kritiska först.
• Lägg till kontroll i CI (GitHub Actions, GitLab CI): låt bygget misslyckas vid nya överträdelser i pull requests.

Börja med ett kostnadsfritt composer require --dev wp-coding-standards/wpcs i ett projekt. Efter en vecka vänjer sig teamet vid markeringarna. Efter en månad är de vana vid ren kod. Vilken kodstandard använder du? Berätta i kommentarerna.