Пишете код для 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 в одном проекте. Через неделю команда привыкнет к подсветке, через месяц, к чистому коду. А какой стандарт кодирования используете вы, напишите в комментариях.