⚙️ PHP CodeSnifferi seadistamine PhpStormis WordPressi kodeerimisstandarditega

Kirjutad koodi WordPressile ja su meeskonnakaaslane palub sul igal koodiülevaatusel "tühikud ja taanded ära koristada"? Või su sait jookseb pärast pluginauuendust kokku ja sa ei leia logidest viga, sest kood on kirjutatud ilma ühegi järjepideva standardita?

See on tuttav stsenaarium kõigile, kes arendavad WordPressi meeskonnas. Erinevad vormindamisharjumused, mõni kasutab Yoda tingimusi, teine mitte, ja väljundi escapimine on kohati puudu.

PHP CodeSniffer lahendab selle automaatselt: see kontrollib sinu koodi WordPressi kodeerimisstandardite vastu otse sinu redaktoris, tõstab rikkumised esile ja suudab need ühe käsuga parandada. Allpool on nullist seadistamise juhend PhpStorm 2026 jaoks.

💡 Kiirülevaade:

• Paigalda PHP CodeSniffer ja WordPressi kodeerimisstandardid Composeriga, kas projekti siseselt või globaalselt
• Määra seadistustes phpcs-i asukoht ja lisa WordPressi standard
• Seadista kaug-PHP interpretaator, kui töötad läbi Vagranti, Dockeri või SSH
• Luba PhpStormis PHP CodeSniffer Validation inspektsioon ja vead tõstetakse jooksvalt esile
• Seadista automaatvormindamine PHP Code Beautifier and Fixeriga, et koodi ühe käsuga parandada

Samm-sammuline video inglise keeles (samad sammud, mis tekstis):

1. Samm: seadista kaug-PHP interpretaator

Kui arendad kohaliku PHP-ga (XAMPP, MAMP, Local, sisseehitatud server), jäta see samm vahele. Vagranti, Dockeri või SSH kaudu kaugserveri puhul pead interpretaatori selgelt määrama.

Ava Settings → PHP (Ctrl+Alt+S), klõpsa CLI Interpreter kõrval oleval ikoonil […] ja vali SSH Credentials või Docker Compose.

Täida:

• Hosti IP-aadress, sama, mida kasutatakse saidi jaoks (ping example.dev aitab)
• vagrant kasutajanime ja paroolina (kui kasutad Vagranti)
• /usr/bin/php, PHP käivitatava faili asukoht serveris

Salvesta ja vali loodud interpretaator nimekirjast:

PhpStorm kasutab seda konkreetset PHP-d CodeSnifferi ja teiste koodikvaliteedi tööriistade käivitamiseks.

2. Samm: paigalda PHP CodeSniffer Composeriga

Kõige usaldusväärsem viis on paigaldada PHPCS projekti sõltuvusena. Lisa oma composer.json faili:

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

Seejärel käivita composer install. PhpStorm tuvastab automaatselt phpcs ja phpcbf kaustas vendor/bin, nii et teekondi pole vaja käsitsi määrata.

Globaalseks paigalduseks (kui vajad seda kõigis projektides):

1
composer global require "squizlabs/php_codesniffer=*"

Kontrolli: phpcs käivitatav fail peaks asuma kohas ~/.composer/vendor/bin/ (Linux/Mac) või %APPDATA%/Composer/vendor/bin/ (Windows).

2. Samm: paigalda WordPressi kodeerimisstandardid

WPCS on PHPCS-i reeglistik (sniffs), mis kontrollib vastavust konkreetselt WordPressi standarditele: väljundi escapimine, Yoda tingimused, funktsioonide prefiksid ja kõik muu WordPressi kodeerimisstandardite käsiraamatust.

Composeriga oma projektis:

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

Või globaalselt (vana läbiproovitud meetod):

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

Veendu, et standard asub kaustas ~/.composer/wpcs/ või vendor/wp-coding-standards/wpcs/.

3. Samm: määra standardi asukoht PHPCS-i konfiguratsioonis

Liigu phpcs kausta ja määra, kus paigaldatud standardid asuvad:

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

Kontrolli, et WordPress kuvatakse saadaolevate standardite nimekirjas:

1
phpcs -i

Väljund peaks näitama nelja standardit: WordPress, WordPress-Core, WordPress-Docs ja WordPress-Extra.

4. Samm: lisa phpcs PATH-i

Ava ~/.bash_profile (või ~/.zshrc ZSH puhul) ja lisa rida:

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

Taaskäivita terminal või käivita source ~/.bash_profile. Nüüd on phpcs käsk saadaval igast kaustast.

Testi seda mõne teema või plugin faili peal:

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

Edukas väljund näeb välja selline:

Vead jagunevad kahele tasemele: ERROR raskete rikkumiste jaoks ja WARNING soovituste jaoks. Iga rida sisaldab reegli numbrit ja probleemi kirjeldust.

5. Samm: seadista PHP CodeSniffer PhpStormis

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

Kui paigaldasid Composeriga oma projekti, tuvastab PhpStorm phpcsi vendor/bin kaustast automaatselt. Kui paigaldasid globaalselt, klõpsa […] Configuration kõrval ja määra käivitatava faili asukoht: ~/.composer/vendor/bin/phpcs.

Vali loendist PHP interpretaator, sama mille seadistasid esimeses sammus.

6. Samm: luba PHP CodeSniffer Validation inspektsioon

Mine Settings → Editor → Inspections, laienda PHP → Quality Tools ja märgi PHP_CodeSniffer validation.

Valige rippmenüüst Coding standard suvand WordPress. Salvestage seaded.

Nüüdsest kontrollib PhpStorm avatud PHP-faile jooksvalt. Rikkumised tõstetakse esile lainelise allajoonimisega, täpselt nagu tavalised IDE vead. Liikuge kursoriga nende kohale ja ilmub kohtspikker kirjeldusega: mis on valesti ja kuidas parandada.

8. Samm: kontrollige, kas see töötab

Looge või avage mõni teema PHP-fail ja kirjutage tahtlikult standardile mittevastav kood:

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

PhpStorm joonib rea alla: puuduvad tühikud if järel, looksulgude ümber ja tingimuse sees. Liigutage kursor kohale ja näete vea teksti ning WordPressi reegli numbrit.

9. Samm: seadistage automaatne parandamine PHP Code Beautifier and Fixer abil

Te ei pea iga rikkumist käsitsi parandama. PHP Code Beautifier and Fixer (phpcbf) on paigaldatud koos PHPCS-iga ja suudab koodi automaatselt vastavalt valitud standardile parandada.

Avage Settings → PHP → Quality Tools, jaotises External Formatters valige PHP Code Beautifier and Fixer. Nüüd, kui käivitate Code → Reformat Code (Ctrl+Alt+L / Cmd+Option+L), ei joonda PhpStorm mitte ainult taandeid oma vormindajaga, vaid rakendab phpcbf-i kaudu ka WordPressi reegleid.

Lisaks seadistage sisseehitatud vormindaja jaoks WordPressi koodistiil: Settings → Editor → Code Style → PHP → Set From → Predefined Style → WordPress. Nii töötavad mõlemad tööriistad samas suunas ega lähe vastuollu.

10. Samm: mida teha uute projektide puhul

Iga uue WordPressi projekti puhul korrake lihtsalt 1. sammu (interpretaator, kui see on kaugühendusega), 6. sammu (määrake phpcs seadetes) ja 7. sammu (lubage inspektsioon). Kui kasutate oma projektis Composerit, on 2., 4. samm kaetud ühe reaga: composer require --dev wp-coding-standards/wpcs.

⁉️🤔 Korduma kippuvad küsimused

Mis vahe on WordPressil, WordPress-Core'il, WordPress-Docsil ja WordPress-Extral?

WordPress on kõigi reeglite baaskomplekt, välja arvatud dokumentatsioon. WordPress-Core sisaldab ainult ametliku kodeerimisjuhendi reegleid (taandamine, nimetamine, Yoda tingimused). WordPress-Extra lisab turvakontrollid: väljundi escapimine, sisendandmete valideerimine. WordPress-Docs kontrollib koodi dokumentatsiooni standardeid (PHPDoc). Praktikas kasuta WordPressi, sest see sisaldab Core'i ja Extrat.

PhpStorm ei näe phpcs'i pärast paigaldamist. Mida teha?

Veendu, et vendor/bin kaust (või ~/.composer/vendor/bin) on lisatud PATH-i ja sisaldab phpcs käivitatavat faili. PhpStormis ava Settings → PHP → Quality Tools → PHP_CodeSniffer, klõpsa […] ja määra käsitsi tee phpcs-ini. Pärast interpretaatori vahetamist või sõltuvuste uuesti paigaldamist võib olla vajalik seadistus lähtestada, kasutades samas aknas nuppu Reset.

Kas ma saan PHPCS-i kasutada ilma Composerita, lihtsalt phar-arhiivi alla laadides?

Jah, aga me ei soovita seda. Composeriga paigaldades tuvastab PhpStorm automaatselt phpcsi, phpcbfi ja kõik registreeritud standardid. Phar-arhiivi puhul pead teed käsitsi määrama ja uuendusi eraldi jälgima. Meeskonnatöö jaoks lukustab Composeri sõltuvus failis composer.json versiooni, nii et kõigil arendajatel on samad reeglid.

Kuidas välistada kindlaid faile või kaustu kontrollimisest?

Loo oma projekti juurkausta phpcs.xml fail. Saad välistada katalooge (<exclude-pattern>vendor/*</exclude-pattern>), määrata standardi ja muuta üksikute reeglite tõsidusastet. PhpStorm tuvastab selle faili automaatselt, kui see on projekti juurkaustas ja nimega phpcs.xml või phpcs.xml.dist.

Miks PHPCS kaebab wp_redirect() üle ilma exit'ita?

WordPressi standard nõuab exit'it või wp_die()'d pärast igat ümbersuunamist: wp_redirect() määrab ainult päise, kuid ei peata skripti täitmist. Ilma exit'ita jätkub koodi käivitamine pärast ümbersuunamist, mis on turvaauk. Õige kasutus: wp_redirect( home_url() ); exit;.

Mida teha, kui su koodibaas on juba suur ja sa alles juurutad standardeid

PHPCS-i käivitamine projektis, kus on tuhandeid rikkumisi, on kindel viis oma meeskonna motivatsiooni pärssida. Alusta väikeselt: paranda kriitilised vead (error, mitte warning), kasutades phpcbfi, seejärel alanda järk-järgult lävendit. Lisa phpcs.xml koos välistustega pärandkoodile ja lülita iga kuu ükshaaval sisse uued reeglid.

Siin on samm-sammuline plaan standardite juurutamiseks elavas projektis:

• Käivita phpcs --standard=WordPress --report=summary, et näha vigade koguarvu.
• Paranda automaatselt kõik võimalik: phpcbf --standard=WordPress .
• Sorteeri järelejäänud vead tõsiduse järgi, tegeledes esmalt kriitilistega.
• Lisa kontrollimine CI-sse (GitHub Actions, GitLab CI): lase buildil ebaõnnestuda uute rikkumiste korral tõmbepäringutes.

Alusta tasuta käsuga composer require --dev wp-coding-standards/wpcs ühes projektis. Nädala pärast harjub meeskond esiletõstmisega. Kuu aja pärast on nad harjunud puhta koodiga. Millist kodeerimisstandardit sina kasutad? Anna meile kommentaarides teada.