Simplify PHPStan configuration

[szepeviktor]

All Submissions:

• Have you followed the plugin Contributing guideline?
• Does your code follow the WordPress' coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

[mscurtescu]

Thanks again @szepeviktor

Merging here on dev, will later merge into main.

[mscurtescu]

Hi @szepeviktor ,

I finally merged your simplification into main and started using it, thanks again.

Running into an issue with phpstan that I cannot figure, as far as I can tell it properly pulls in the WordPress stubs but it seems to be confused about number of parameters:

 236 Function site_url invoked with 1 parameter, 0 required. 337 Function admin_url invoked with 1 parameter, 0 required. 573 Function get_bloginfo invoked with 1 parameter, 0 required. 574 Function esc_attr invoked with 1 parameter, 0 required. 

It's not complaining about all WordPress functions, only some.

For now I am ignoring these specific errors so I can see the real issues being brought up.

Any idea where is this coming from? Some extra libraries being imported unnecessarily? Thanks in advance

Link to phpstan.neon.dist

[szepeviktor]

Investigating 🏃🏻‍♂️

[szepeviktor]

On PHP 7.4 I get

 -- -----------------------------------------------------------------------------------------------------------
Error
-- -----------------------------------------------------------------------------------------------------------
Ignored error pattern #^Function [^ ]+ invoked with [1234] parameters?, 0 required\.$# was not matched in
reported errors.
-- -----------------------------------------------------------------------------------------------------------

[mscurtescu]

I was getting the errors when running locally, either:

grunt shell:phpstan

or directly:

./vendor/bin/phpstan analyze

[szepeviktor]

Try clearing composer cache, removing vendor/ and doing a composer update.

[mscurtescu]

clearing the cache made no difference :-(

[szepeviktor]

I see.

All I can see static analysis here on GitHub Actions recognizes those functions.
(and on my Debian/Linux computer)

[mscurtescu]

Thanks, your help is much appreciated. Will try on a different computer with a clean state.

[szepeviktor]

I wish you to keep all of your computers clean all the time.

[mscurtescu]

On a clean computer it works as expected, thanks for your help. Yes, I have to figure what exactly is messing with phpstan.

[mscurtescu]

Really puzzling, still running into this error on one computer:

• run ./vendor/bin/phpstan clear-result-cache (this is not documented when running phpstan -h)
• run composer clear-cache
• brand new git clone in a new folder

Since I am seeing the error in a brand new git clone the cause must reside outside of the git repo folder. Beyond phpstan and composer caches not sure what it can be. I also nuked the npm cache, but I don't see how that would be related anyhow.

Also, using --debug with phpstan is not providing much insight, it only shows what files are being analysed and what configuration file was used. Where are the WordPress stubs loaded from? I assume through composer from the vendor subfolder, but deleting that folder made no difference.

[szepeviktor]

Where are the WordPress stubs loaded from?

From the extension's configuration: https://github.com/szepeviktor/phpstan-wordpress/blob/master/extension.neon#L116

[mscurtescu]

Where are the WordPress stubs loaded from?

From the extension's configuration: https://github.com/szepeviktor/phpstan-wordpress/blob/master/extension.neon#L116

So that's under vendor, a brand new git clone, or removing the vendor folder, should take care of a bad cache, and that's not the case. Is there any chance that stubs are also loaded from some other location?

[szepeviktor]

Is there any chance that stubs are also loaded from some other location?

No, it is loaded from the extension.

[mscurtescu]

Maybe I am looking at it the wrong way and it's not a caching issue, what would generate an error like:

Function admin_url invoked with 1 parameter, 0 required

How does phpstan determine that admin_url requires 0 parameters? I checked the stub and the stub has the expected signature which is:

functionadmin_url($path = '', $scheme = 'admin')
{
}

[szepeviktor]

Search for function admin_url in every file.
grep -rFn 'function admin_url'
If there is another definition than that is the cause.
Otherwise it is a PHPStan error.

[mscurtescu]

$ find . -name \*.php -exec grep -iHn "function admin_url" {} \;
./vendor/php-stubs/wordpress-stubs/wordpress-stubs.php:110462: functionadmin_url($path = '', $scheme = 'admin')
./wordpress/wp-includes/link-template.php:3522:function admin_url( $path = '', $scheme = 'admin' ) {
./wordpress/wp-admin/includes/noop.php:80:function admin_url() {}

This is the suspicious one: ./wordpress/wp-admin/includes/noop.php:80:function admin_url() {}

I deleted the whole wordpress folder, now phpstan runs as expected.

Questions:

1. Why is phpstan loading this folder?
2. Checking what is different on my other computer where it worked from the beginning...

[mscurtescu]

Answering question 2, on the machine where phpstan worked, there is also the exact same ./wordpress/wp-admin/includes/noop.php:80:function admin_url() {}, mind bugling

[szepeviktor]

PHPStan should be instructed to scan that file in phpstan.neon.dist

[szepeviktor]

Here is our perpetrator!!!

wordpress/composer.json

Line 65 in e842276

"wordpress/"

[mscurtescu]

The content of phpstan.neon.dist:

parameters:
level: 5inferPrivatePropertyTypeFromConstructor: truebootstrapFiles:
- tests/phpstan-bootstrap.phppaths:
- hello-login.php
- includes/

[szepeviktor]

The cause is in the previous comment!

[mscurtescu]

Here is our perpetrator!!!

wordpress/composer.json

Line 65 in e842276

"wordpress/"

So on some machines classes are loaded in some order and on other machines in a different one?

[szepeviktor]

So on some machines classes are loaded in some order and on other machines in a different one?

• composer install
• composer install --no-dev

That makes the difference.

[mscurtescu]

The cause is in the previous comment!

Yes, removing autoload-dev for now, it was inherited from the parent project (the one this project forked). Thanks.

[mscurtescu]

So on some machines classes are loaded in some order and on other machines in a different one?

• composer install
• composer install --no-dev

That makes the difference.

I don't think it's that, running composer install --no-dev will not download and install the wordpress folder, that definitely helps. but on my other machine the wordpress folder was installed and it still works, so it must be class loading order.

[mscurtescu]

adding:

excludePaths:
- wordpress/

also works, yay!

[mscurtescu]

köszönöm szépen