Пишете код для WordPress, а колега просить «прибрати пробіли та відступи» під час кожного code review? Або сайт падає після оновлення плагіна, а помилку в логах не знайти, бо код написаний без жодного стандарту?

Знайома картина для кожного, хто розробляє під WordPress у команді. Різні звички форматування, Yoda-умови хтось ставить, хтось ні, а екранування виводу подекуди відсутнє.

PHP CodeSniffer вирішує це автоматично: він перевіряє код на відповідність стандартам кодування WordPress прямо в редакторі, підсвічує порушення та вміє виправляти їх однією командою. Далі, налаштування з нуля в PhpStorm 2026.

💡 Швидкий огляд:

• Встановіть PHP CodeSniffer і WordPress Coding Standards через Composer, у проєкт або глобально
• Пропишіть шлях до phpcs у конфігурації та додайте стандарт WordPress
• Налаштуйте віддалений PHP-інтерпретатор, якщо працюєте через Vagrant, Docker або SSH
• Увімкніть інспекцію PHP CodeSniffer Validation у PhpStorm, помилки підсвітяться на льоту
• Налаштуйте автоформатування через PHP Code Beautifier and Fixer, щоб правити код однією командою

Покрокове відео англійською (ті самі кроки, що й у тексті):

Шаг 1: налаштуйте віддалений PHP-інтерпретатор

Якщо ви розробляєте на локальному PHP (XAMPP, MAMP, Local, вбудованому сервері), пропустіть цей крок. Для Vagrant, Docker або віддаленого сервера через SSH інтерпретатор потрібно вказати явно.

Відкрийте Settings → PHP (Ctrl+Alt+S), натисніть […] поруч із CLI Interpreter і виберіть SSH Credentials або Docker Compose.

Заповніть:

• IP-адресу хоста, ту саму, що й для сайту (ping example.dev підкаже)
• vagrant для імені користувача та пароля (якщо Vagrant)
• /usr/bin/php, шлях до виконуваного файлу PHP на сервері

Збережіть і виберіть створеного інтерпретатора зі списку:

PhpStorm використовуватиме саме цей PHP для запуску CodeSniffer та інших інструментів якості коду.

Шаг 2: встановіть PHP CodeSniffer через Composer

Найнадійніший спосіб, поставити PHPCS як залежність проєкту. Додайте в composer.json:

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

Потім composer install. PhpStorm автоматично виявить phpcs і phpcbf у vendor/bin, вручну прописувати шляхи не доведеться.

Для глобального встановлення (якщо потрібно в усіх проєктах одразу):

1
composer global require "squizlabs/php_codesniffer=*"

Перевірте: виконуваний файл phpcs має лежати в ~/.composer/vendor/bin/ (Linux/Mac) або %APPDATA%/Composer/vendor/bin/ (Windows).

Крок 3: встановіть WordPress Coding Standards

WPCS — це набір правил (sniffs) для PHPCS, який перевіряє відповідність саме стандартам WordPress: екранування виводу, Yoda-умови, префікси функцій і все інше з WordPress Coding Standards Handbook.

Через Composer у проєкт:

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

Або глобально (старий перевірений метод):

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

Переконайтеся, що стандарт з’явився в ~/.composer/wpcs/ або vendor/wp-coding-standards/wpcs/.

Крок 4: пропишіть шлях до стандарту в конфігурації PHPCS

Перейдіть до теки з phpcs і вкажіть, де лежать встановлені стандарти:

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

Перевірте, що WordPress з’явився в переліку доступних стандартів:

1
phpcs -i

У виводі мають з’явитися чотири стандарти: WordPress, WordPress-Core, WordPress-Docs і WordPress-Extra.

Крок 5: додайте phpcs до PATH

Відкрийте ~/.bash_profile (або ~/.zshrc для ZSH) і додайте рядок:

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

Перезавантажте термінал або виконайте source ~/.bash_profile. Тепер команда phpcs доступна з будь-якої теки.

Перевірте на будь-якому файлі теми або плагіна:

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

Успішний вивід має такий вигляд:

Помилки поділяються на два рівні: ERROR для жорстких порушень і WARNING для рекомендацій. Кожен рядок містить номер правила та опис проблеми.

Крок 6: налаштуйте PHP CodeSniffer у PhpStorm

Відкрийте Settings → PHP → Quality Tools → PHP_CodeSniffer (Ctrl+Alt+S).

Якщо ставили через Composer у проєкт, PhpStorm підхопить phpcs із vendor/bin автоматично. Якщо глобально, натисніть […] поруч із Configuration і вкажіть шлях до виконуваного файлу: ~/.composer/vendor/bin/phpcs.

Виберіть PHP-інтерпретатор зі списку, той самий, що налаштовували на кроці 1.

Крок 7: увімкніть інспекцію PHP CodeSniffer Validation

Перейдіть у Settings → Editor → Inspections, розгорніть PHP → Quality Tools і поставте прапорець PHP_CodeSniffer validation.

У випадному списку Coding standard виберіть WordPress. Збережіть налаштування.

З цього моменту PhpStorm перевіряє відкритий PHP-файл на льоту. Порушення підсвічуються хвилястим підкресленням, як звичайні помилки IDE. При наведенні з’являється спливне вікно з описом: що не так і як виправити.

Крок 8: перевірте роботу

Створіть або відкрийте будь-який PHP-файл теми та напишіть свідомо нестандартний код:

1
if(true){echo 'Пробелы? Не, не слышал';}

PhpStorm підкреслить рядок: пропущено пробіли після if, навколо фігурних дужок і всередині умови. Наведіть курсор, побачите текст помилки та номер правила WordPress.

Крок 9: налаштуйте автовиправлення через PHP Code Beautifier and Fixer

Виправляти кожне порушення вручну не обов’язково. PHP Code Beautifier and Fixer (phpcbf) встановлюється разом із PHPCS і вміє автоматично виправляти код під обраний стандарт.

Відкрийте Settings → PHP → Quality Tools, у розділі External Formatters виберіть PHP Code Beautifier and Fixer. Тепер при виклику Code → Reformat Code (Ctrl+Alt+L / Cmd+Option+L) PhpStorm не лише вирівняє відступи своїм форматером, а й застосує правила WordPress через phpcbf.

Додатково налаштуйте стиль коду WordPress для вбудованого форматера: Settings → Editor → Code Style → PHP → Set From → Predefined Style → WordPress. Так обидва інструменти працюють в одному напрямку й не конфліктують.

Крок 10: що робити для нових проєктів

Для кожного нового WordPress-проєкту достатньо повторити крок 1 (інтерпретатор, якщо віддалений), крок 6 (вказати phpcs у налаштуваннях) і крок 7 (увімкнути інспекцію). Якщо використовуєте Composer у проєкті, кроки 2-4 закриваються одним рядком composer require --dev wp-coding-standards/wpcs.

⁉️🤔 Часті запитання

У чому різниця між WordPress, WordPress-Core, WordPress-Docs та WordPress-Extra?

WordPress, базовий набір усіх правил, крім документування. WordPress-Core, лише правила з офіційного посібника з кодування (відступи, іменування, Yoda-умови). WordPress-Extra додає перевірки безпеки: екранування виводу, валідація вхідних даних. WordPress-Docs перевіряє стандарти документування коду (PHPDoc). На практиці ставте WordPress, він включає Core та Extra.

PhpStorm не бачить phpcs після встановлення. Що робити?

Перевірте, що папка vendor/bin (або ~/.composer/vendor/bin) додана до PATH і містить виконуваний файл phpcs. У PhpStorm відкрийте Settings → PHP → Quality Tools → PHP_CodeSniffer, натисніть […] і вкажіть шлях до phpcs вручну. Після зміни інтерпретатора або перевстановлення залежностей може знадобитися скидання конфігурації, кнопка Reset у тому ж вікні.

Чи можна використовувати PHPCS без Composer, просто завантаживши phar-архів?

Так, але не рекомендуємо. При встановленні через Composer PhpStorm автоматично підхоплює і phpcs, і phpcbf, і всі зареєстровані стандарти. З phar-архівом доведеться прописувати шляхи вручну та стежити за оновленнями окремо. Для командної роботи Composer-залежність у composer.json фіксує версію, тож у всіх розробників однаковий набір правил.

Як виключити конкретні файли або папки з перевірки?

Створіть phpcs.xml у корені проєкту. У ньому можна виключити директорії (<exclude-pattern>vendor/*</exclude-pattern>), задати стандарт і змінити severity окремих правил. PhpStorm автоматично підхопить цей файл, якщо він лежить у корені проєкту та називається phpcs.xml або phpcs.xml.dist.

Чому PHPCS свариться на wp_redirect() без exit?

Стандарт WordPress вимагає exit або wp_die() після будь-якого редіректу: wp_redirect() лише виставляє заголовок, але не зупиняє виконання скрипту. Без exit код після редіректу продовжить виконуватися — це діра в безпеці. Правильно: wp_redirect( home_url() ); exit;.

Що робити, якщо кодова база вже велика, а стандарти тільки впроваджуєте

Запускати PHPCS на проєкті з тисячами порушень — це вірний спосіб демотивувати команду. Почніть з малого: виправте критичні помилки (error, не warning) через phpcbf, потім поступово знижуйте поріг. Додайте phpcs.xml з винятками для legacy-коду та підключайте нові правила по одному на місяць.

Ось покроковий план впровадження на живому проєкті:

• Запустіть phpcs --standard=WordPress --report=summary, побачите загальну кількість помилок.
• Виправте автофіксом усе, що можна: phpcbf --standard=WordPress .
• Решту помилок розберіть за severity, критичні спочатку.
• Додайте перевірку в CI (GitHub Actions, GitLab CI): нехай білд падає при нових violations у пул-реквесті.

Почніть з безкоштовного composer require --dev wp-coding-standards/wpcs в одному проєкті. За тиждень команда звикне до підсвічування, за місяць, до чистого коду. А який стандарт кодування використовуєте ви, напишіть у коментарях.