Kirjoitat koodia WordPressille ja tiimikaverisi pyytää sinua jatkuvasti "siistimään välilyönnit ja sisennykset" jokaisessa koodikatselmoinnissa? Tai sivustosi kaatuu liitännäispäivityksen jälkeen, etkä löydä virhettä lokeista, koska koodi on kirjoitettu ilman minkäänlaista johdonmukaista standardia?

Tämä on tuttu tilanne kaikille, jotka kehittävät WordPressiä tiimissä. Erilaiset muotoilutottumukset, jotkut käyttävät Yoda-ehtoja ja toiset eivät, ja tulosteen escapet puuttuvat sieltä täältä.

PHP CodeSniffer ratkaisee tämän automaattisesti: se tarkistaa koodisi WordPressin koodausstandardeja vasten suoraan editorissasi, korostaa rikkomukset ja voi korjata ne yhdellä komennolla. Alla on alusta alkaen etenevä asennusopas PhpStorm 2026:lle.

💡 Pikaopas:

• Asenna PHP CodeSniffer ja WordPress Coding Standards Composerin kautta joko projektiisi tai globaalisti
• Aseta polku phpcs:ään asetuksiin ja lisää WordPress-standardi
• Määritä etä-PHP-tulkki, jos työskentelet Vagrantin, Dockerin tai SSH:n kautta
• Ota käyttöön PHP CodeSniffer Validation -tarkistus PhpStormissa, niin virheet korostuvat lennossa
• Määritä automaattimuotoilu PHP Code Beautifier and Fixerin kautta, jotta voit korjata koodin yhdellä komennolla

Vaiheittainen video englanniksi (samat vaiheet kuin tekstissä):

Vaihe 1: määritä etä-PHP-tulkki

Jos kehität paikallisella PHP:llä (XAMPP, MAMP, Local, sisäänrakennettu palvelin), ohita tämä vaihe. Vagrantille, Dockerille tai etäpalvelimelle SSH:n kautta sinun on määritettävä tulkki erikseen.

Avaa Settings → PHP (Ctrl+Alt+S), napsauta […] CLI Interpreterin vieressä ja valitse SSH Credentials tai Docker Compose.

Täytä:

• Palvelimen IP-osoite, sama jota käytetään sivustolle (ping example.dev auttaa)
• vagrant käyttäjätunnukseksi ja salasanaksi (jos käytät Vagrantia)
• /usr/bin/php, polku PHP-suoritettavaan tiedostoon palvelimella

Tallenna ja valitse luotu tulkki listasta:

PhpStorm käyttää tätä nimenomaista PHP:tä CodeSnifferin ja muiden koodinlaatutyökalujen ajamiseen.

Vaihe 2: asenna PHP CodeSniffer Composerin kautta

Luotettavin tapa on asentaa PHPCS projektiriippuvuutena. Lisää composer.json-tiedostoosi:

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

Suorita sitten composer install. PhpStorm tunnistaa automaattisesti phpcs:n ja phpcbf:n hakemistossa vendor/bin, joten sinun ei tarvitse asettaa polkuja manuaalisesti.

Globaalia asennusta varten (jos tarvitset sitä kaikissa projekteissa):

1
composer global require "squizlabs/php_codesniffer=*"

Varmista: phpcs-suoritettavan tulisi löytyä polusta ~/.composer/vendor/bin/ (Linux/Mac) tai %APPDATA%/Composer/vendor/bin/ (Windows).

Vaihe 3: asenna WordPress Coding Standards

WPCS on joukko sääntöjä (sniffejä) PHPCS:lle, joka tarkistaa nimenomaan WordPress-standardien noudattamisen: tulosteen escapauksen, Yoda-ehdot, funktioiden etuliitteet ja kaiken muun WordPress Coding Standards Handbookista.

Composerin kautta projektissasi:

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

Tai globaalisti (vanha hyväksi havaittu tapa):

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

Varmista, että standardi löytyy polusta ~/.composer/wpcs/ tai vendor/wp-coding-standards/wpcs/.

Vaihe 4: aseta polku standardiin PHPCS:n asetuksissa

Siirry phpcs-kansioon ja määritä, missä asennetut standardit sijaitsevat:

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

Varmista, että WordPress näkyy saatavilla olevien standardien listalla:

1
phpcs -i

Tulosteen pitäisi näyttää neljä standardia: WordPress, WordPress-Core, WordPress-Docs ja WordPress-Extra.

Vaihe 5: lisää phpcs PATH:iin

Avaa ~/.bash_profile (tai ~/.zshrc ZSH:lle) ja lisää rivi:

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

Käynnistä terminaali uudelleen tai aja source ~/.bash_profile. Nyt phpcs-komento on käytettävissä mistä tahansa kansiosta.

Testaa se millä tahansa teema- tai lisäosatiedostolla:

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

Onnistunut tuloste näyttää tältä:

Virheet jaetaan kahteen tasoon: ERROR koville rikkomuksille ja WARNING suosituksille. Jokainen rivi sisältää säännön numeron ja kuvauksen ongelmasta.

Vaihe 6: määritä PHP CodeSniffer PhpStormissa

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

Jos asensit Composerin kautta projektiisi, PhpStorm poimii phpcs:n automaattisesti vendor/bin-kansiosta. Jos asensit globaalisti, klikkaa […] Configuration-kohdan vieressä ja määritä polku suoritettavaan tiedostoon: ~/.composer/vendor/bin/phpcs.

Valitse PHP-tulkki listasta, sama jonka määritit vaiheessa 1.

Vaihe 7: ota käyttöön PHP CodeSniffer Validation -tarkistus

Siirry kohtaan Settings → Editor → Inspections, laajenna PHP → Quality Tools ja valitse PHP_CodeSniffer validation.

Valitse Coding standard -pudotusvalikosta WordPress. Tallenna asetukset.

Tästä eteenpäin PhpStorm tarkistaa avoinna olevat PHP-tiedostot lennossa. Rikkomukset korostetaan aaltoviivalla, aivan kuten tavalliset IDE-virheet. Vie kursori niiden päälle, niin näet työkaluvihjeen, jossa kerrotaan, mikä on vialla ja miten se korjataan.

Vaihe 8: varmista, että se toimii

Luo tai avaa mikä tahansa teeman PHP-tiedosto ja kirjoita tarkoituksella standardin vastaista koodia:

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

PhpStorm alleviivaa rivin: välilyönnit puuttuvat if-sanan jälkeen, aaltosulkeiden ympäriltä ja ehdon sisältä. Vie kursori kohdan päälle, niin näet virheilmoituksen ja WordPress-säännön numeron.

Vaihe 9: ota käyttöön automaattinen korjaus PHP Code Beautifier and Fixerillä

Sinun ei tarvitse korjata jokaista rikkomusta käsin. PHP Code Beautifier and Fixer (phpcbf) asentuu PHPCS:n mukana ja osaa korjata koodin automaattisesti valitun standardin mukaan.

Avaa Settings → PHP → Quality Tools ja valitse External Formatters -osiosta PHP Code Beautifier and Fixer. Kun nyt käytät toimintoa Code → Reformat Code (Ctrl+Alt+L / Cmd+Option+L), PhpStorm ei ainoastaan tasaa sisennyksiä omalla muotoilijallaan, vaan soveltaa myös WordPress-sääntöjä phpcbf:n kautta.

Määritä lisäksi WordPress-koodityyli sisäänrakennetulle muotoilijalle: Settings → Editor → Code Style → PHP → Set From → Predefined Style → WordPress. Näin molemmat työkalut toimivat samaan suuntaan eivätkä ole ristiriidassa keskenään.

Vaihe 10: mitä tehdä uusissa projekteissa

Jokaisessa uudessa WordPress-projektissa toista vain vaihe 1 (tulkki, jos etäyhteys), vaihe 6 (aseta phpcs asetuksissa) ja vaihe 7 (ota tarkistus käyttöön). Jos käytät projektissasi Composeria, vaiheet 2-4 hoituvat yhdellä rivillä: composer require --dev wp-coding-standards/wpcs.

⁉️🤔 Usein kysytyt kysymykset

Mitä eroa on WordPress-, WordPress-Core-, WordPress-Docs- ja WordPress-Extra-standardeilla?

WordPress on perussääntökokoelma, joka sisältää kaikki säännöt dokumentaatiota lukuun ottamatta. WordPress-Core sisältää vain virallisen koodausohjeen säännöt (sisennys, nimeäminen, Yoda-ehdot). WordPress-Extra lisää tietoturvatarkistukset: tulosteen escapauksen, syötetiedon validoinnin. WordPress-Docs tarkistaa koodin dokumentointistandardit (PHPDoc). Käytännössä kannattaa käyttää WordPress-standardia, koska se sisältää Coren ja Extran.

PhpStorm ei löydä phpcs:ää asennuksen jälkeen. Mitä teen?

Varmista, että vendor/bin-kansio (tai ~/.composer/vendor/bin) on lisätty PATH:iin ja sisältää phpcs-suoritettavan. Avaa PhpStormissa Settings → PHP → Quality Tools → PHP_CodeSniffer, klikkaa […] ja määritä polku phpcs-tiedostoon manuaalisesti. Tulkin vaihtamisen tai riippuvuuksien uudelleenasennuksen jälkeen asetus on ehkä nollattava saman ikkunan Reset-painikkeella.

Voinko käyttää PHPCS:ää ilman Composeria lataamalla vain phar-arkiston?

Kyllä, mutta emme suosittele sitä. Composer-asennuksessa PhpStorm tunnistaa automaattisesti phpcs- ja phpcbf-työkalut sekä kaikki rekisteröidyt standardit. Phar-arkiston kanssa joudut asettamaan polut manuaalisesti ja seuraamaan päivityksiä erikseen. Tiimityössä Composer-riippuvuus composer.json-tiedostossa lukitsee version, jolloin kaikilla kehittäjillä on sama sääntökokoelma.

Miten jätän tietyt tiedostot tai kansiot tarkistuksen ulkopuolelle?

Luo phpcs.xml-tiedosto projektisi juureen. Voit sulkea pois hakemistoja (<exclude-pattern>vendor/*</exclude-pattern>), asettaa standardin ja muuttaa yksittäisten sääntöjen vakavuusastetta. PhpStorm tunnistaa tämän tiedoston automaattisesti, jos se on projektin juuressa ja nimetty phpcs.xml tai phpcs.xml.dist.

Miksi PHPCS valittaa wp_redirect()-funktiosta ilman exit-komentoa?

WordPress-standardi vaatii exit- tai wp_die()-komennon jokaisen uudelleenohjauksen jälkeen: wp_redirect() asettaa vain otsakkeen, mutta ei pysäytä skriptin suoritusta. Ilman exit-komentoa uudelleenohjauksen jälkeinen koodi jatkaa suoritusta, mikä on tietoturva-aukko. Oikea käyttötapa: wp_redirect( home_url() ); exit;.

Mitä tehdä, jos koodipohja on jo laaja ja otat standardeja vasta käyttöön

PHPCS:n ajaminen projektissa, jossa on tuhansia rikkomuksia, on varma tapa lannistaa tiimisi. Aloita pienesti: korjaa kriittiset virheet (error, ei warning) phpcbf-työkalulla ja laske kynnystä vähitellen. Lisää phpcs.xml-tiedosto, jossa vanha koodi suljetaan pois, ja ota uusia sääntöjä käyttöön yksi kerrallaan joka kuukausi.

Tässä vaiheittainen suunnitelma standardien käyttöönottoon elävässä projektissa:

• Aja phpcs --standard=WordPress --report=summary nähdäksesi virheiden kokonaismäärän.
• Korjaa automaattisesti kaikki mahdollinen: phpcbf --standard=WordPress .
• Järjestä jäljelle jääneet virheet vakavuuden mukaan ja tartu kriittisimpiin ensin.
• Lisää tarkistus CI-putkeen (GitHub Actions, GitLab CI): anna buildin epäonnistua uusista rikkomuksista pull requesteissa.

Aloita ilmaisella composer require --dev wp-coding-standards/wpcs -komennolla yhdessä projektissa. Viikon kuluttua tiimi tottuu korostuksiin. Kuukauden kuluttua he ovat tottuneet siistiin koodiin. Mitä koodausstandardia sinä käytät? Kerro kommenteissa.