wp-phpstan

par wordpress

We need to translate the given text from English to French. The text describes a skill for PHPStan configuration, error fixing, and baseline management for WordPress projects. It mentions specific technical terms like WP_REST_Request, @param types, Action Scheduler, stubs, etc. We must preserve product names, protocol names, URLs, numbers, and technical terms. Also, we should not include the name "wp-phpstan" unless it appears in the source text. The source text does not include the name, so we don't include it. We translate only the text inside <text>. No extra commentary. Let's translate: "PHPStan configuration, error fixing, and baseline management for WordPress projects." -> "Configuration PHPStan, correction d'erreurs et gestion de baseline pour les projets WordPress." "Handles WordPress-specific typing patterns: REST endpoints with WP_REST_Request, hook callbacks with accurate @param types, database results, and Action Scheduler job arguments" -> "Gère les modèles de typage spécifiques à WordPress : endpoints REST avec WP_R

npx skills add https://github.com/wordpress/agent-skills --skill wp-phpstan

Télécharger ZIP GitHub

WP PHPStan

When to use

Use this skill when working on PHPStan in a WordPress codebase, for example:

setting up or updating phpstan.neon / phpstan.neon.dist
generating or updating phpstan-baseline.neon
fixing PHPStan errors via WordPress-friendly PHPDoc (REST requests, hooks, query results)
handling third-party plugin/theme classes safely (stubs/autoload/targeted ignores)

Inputs required

wp-project-triage output (run first if you haven't)
Whether adding/updating Composer dev dependencies is allowed (stubs).
Whether changing the baseline is allowed for this task.

Procedure

0) Discover PHPStan entrypoints (deterministic)

Inspect PHPStan setup (config, baseline, scripts):
- node skills/wp-phpstan/scripts/phpstan_inspect.mjs

Prefer the repo’s existing composer script (e.g. composer run phpstan) when present.

1) Ensure WordPress core stubs are loaded

szepeviktor/phpstan-wordpress or php-stubs/wordpress-stubs are effectively required for most WordPress plugin/theme repos. Without it, expect a high volume of errors about unknown WordPress core functions.

Confirm the package is installed (see composer.dependencies in the inspect report).
Ensure the PHPStan config references the stubs (see references/third-party-classes.md).

2) Ensure a sane `phpstan.neon` for WordPress projects

Keep paths focused on first-party code (plugin/theme directories).
Exclude generated and vendored code (vendor/, node_modules/, build artifacts, tests unless explicitly analyzed).
Keep ignoreErrors entries narrow and documented.

See:

references/configuration.md

3) Fix errors with WordPress-specific typing (preferred)

Prefer correcting types over ignoring errors. Common WP patterns that need help:

REST endpoints: type request parameters using WP_REST_Request<...>
Hook callbacks: add accurate @param types for callback args
Database results and iterables: use array shapes or object shapes for query results
Action Scheduler: type $args array shapes for job callbacks

See:

references/wordpress-annotations.md

4) Handle third-party plugin/theme classes (only when needed)

When integrating with plugins/themes not present in the analysis environment:

First, confirm the dependency is real (installed/required).
Prefer plugin-specific stubs already used in the repo (common examples: php-stubs/woocommerce-stubs, php-stubs/acf-pro-stubs).
If PHPStan still cannot resolve classes, add targeted ignoreErrors patterns for the specific vendor prefix.

See:

references/third-party-classes.md

5) Baseline management (use as a migration tool, not a trash bin)

Generate a baseline once for legacy code, then reduce it over time.
Do not “baseline” newly introduced errors.

See:

references/configuration.md

Verification

Run PHPStan using the discovered command (composer run ... or vendor/bin/phpstan analyse).
Confirm the baseline file (if used) is included and didn’t grow unexpectedly.
Re-run after changing ignoreErrors to ensure patterns are not masking unrelated issues.

Failure modes / debugging

“Class not found”:
- confirm autoloading/stubs, or add a narrow ignore pattern
Huge error counts after enabling PHPStan:
- reduce paths, add excludePaths, start at a lower level, then ratchet up
Inconsistent types around hooks / REST params:
- add explicit PHPDoc (see references) rather than runtime guards

Escalation

If a type depends on a third-party plugin API you can’t confirm, ask for the dependency version or source before inventing types.
If fixing requires adding new Composer dependencies (stubs/extensions), confirm it with the user first.