Please support my work to avoid abandoning this package.

Thank you!

Static analysis for the WordPress ecosystem.

• PHPStan
• WordPress

Add this package to your project.

composer require --dev szepeviktor/phpstan-wordpress

Make PHPStan find it automatically using phpstan/extension-installer.

composer require --dev phpstan/extension-installer

Or manually include it in your phpstan.neon.

includes:
    - vendor/szepeviktor/phpstan-wordpress/extension.neon

Needs no extra configuration. 😃 Simply configure PHPStan - for example - this way.

parameters:
    level: 5
    paths:
        - plugin.php
        - inc/

Please read PHPStan Config Reference.

💡 Use Composer autoloader or a custom autoloader!

Just start the analysis: vendor/bin/phpstan analyze then fix an error and GOTO 10!

You find further information in the examples directory e.g. examples/phpstan.neon.dist

Please see WooCommerce Stubs

• Makes it possible to run PHPStan on WordPress plugins and themes
• Loads php-stubs/wordpress-stubs package
• Provides dynamic return type extensions for many core functions
• Defines some core constants
• Handles special functions and classes e.g. is_wp_error()
• Validates the optional docblock that precedes a call to apply_filters() and treats the type of its first @param as certain

WordPress core - and the wider WordPress ecosystem - uses PHPDoc docblocks in a non-standard manner to document the parameters passed to apply_filters(). Example:

/**
 * Filters the page title when creating an HTML drop-down list of pages.
 *
 * @param string  $title Page title.
 * @param WP_Post $page  Page data object.
 */
$title = apply_filters( 'list_pages', $title, $page );

This extension understands these docblocks when they're present in your code and uses them to instruct PHPStan to treat the return type of the filter as certain, according to the first @param tag. In the example above this means PHPStan treats the type of $title as string.

To make the best use of this feature, ensure that the type of the first @param tag in each of these such docblocks is accurate and correct.

• Write clean OOP code: 1 class per file, no other code in class files outside class Name { ... }
• Structure your code: uniform class names (WPCS or PSR-4), keep classes in a separate directory inc/
• Add proper PHPDoc blocks to classes, properties, methods, functions, and calls to apply_filters()
• Choose your main plugin file parts.
• Avoid using core constants, use core functions
• Avoid bad parts of PHP
  • functions: eval, extract, compact, list
  • type juggling: $a = '15'; if ($a) ...
• If you need robust code try avoiding all kinds of type juggling (e.g. if needs a boolean), see Variable handling functions
• If you are not bound by PHP 5 consider following Neutron Standard
• Do not enable exit_error in WP_CLI::launch or WP_CLI::runcommand to keep your code testable

WordPress uses conditional function and class definition for override purposes. Use sed command to exclude function stubs when they are previously defined.

sed -i -e 's#function is_gd_image#function __is_gd_image#' vendor/php-stubs/wordpress-stubs/wordpress-stubs.php