You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I attempted to tackle the remaining /includes as one, but hit some unlikely result:
This one in particular has me going back and forth, in order to tackle:
-
message: '#^Access to an undefined property acf_field_clone\:\:\$cloning\.$#'
identifier: property.notFound
count: 2
path: ../includes/fields/class-acf-field-clone.php
-
message: '#^Access to an undefined property acf_field_clone\:\:\$have_rows\.$#'
identifier: property.notFound
count: 1
path: ../includes/fields/class-acf-field-clone.php
I ended up with something like this, which isn't good - any suggestions on this?
class acf_field_clone extends acf_field {
/**
* Var.
*
* @var array $cloning Array to keep track of fields being cloned.
*/
public $cloning = array();
/**
* Var.
*
* @var array $have_rows The type of rows the field supports.
*/
public $have_rows = 'single';
@pkevan 🤔 TBH, my initial thought is to do what you did—declare the properties and explain their use. This would let phpstan catch legit issues of one of us using an expected property that actually impacts things negatively. With PHP 8.2, this would throw a deprecation notice too, that we get around by the acf_field class declaring #[AllowDynamicProperties]. PHPStan is being stricter by still asking for it despite that type being on the parent class, but if it was a new class, it would have caught that.
That said, we can also declare that acf_class is an universal object creator by updating phpstan.neon to include this under the parameters section
universalObjectCratesClasses:
- acf_field
PHPStan would ignore the undeclared properties since we expect acf_field (sub)classes to create properties at will.
TBH, my initial thought is to do what you did—declare the properties and explain their use.
I think looking back at this after some time away, it seems like the right way of doing it anyway.
There are probably still going to be some exception to the phpstan fixes that won't be resolved, which will live in baseline.neon, although that's not ideal.
How are we getting these results? When I run PHPStan with level 1, there are no errors (and if I go up to level 2, I get more than 400). What am I missing?
How are we getting these results? When I run PHPStan with level 1, there are no errors (and if I go up to level 2, I get more than 400). What am I missing?
Phpstan fixes that aren't resolved, live in the baseline.neon file. If you look at one of the closed PRs you can see the fixes and corresponding deletions from that file.
Activity
pkevan commentedon Apr 25, 2025
I attempted to tackle the remaining
/includesas one, but hit some unlikely result:This one in particular has me going back and forth, in order to tackle:
I ended up with something like this, which isn't good - any suggestions on this?
pkevan commentedon Apr 25, 2025
The same issue exists in many other classes, where multiple class variables are required in order to satisfy phpstan.
kraftbj commentedon Apr 28, 2025
@pkevan 🤔 TBH, my initial thought is to do what you did—declare the properties and explain their use. This would let phpstan catch legit issues of one of us using an expected property that actually impacts things negatively. With PHP 8.2, this would throw a deprecation notice too, that we get around by the
acf_fieldclass declaring#[AllowDynamicProperties]. PHPStan is being stricter by still asking for it despite that type being on the parent class, but if it was a new class, it would have caught that.That said, we can also declare that
acf_classis an universal object creator by updatingphpstan.neonto include this under theparameterssectionPHPStan would ignore the undeclared properties since we expect acf_field (sub)classes to create properties at will.
Open to other thoughts.
pkevan commentedon Apr 28, 2025
I think looking back at this after some time away, it seems like the right way of doing it anyway.
There are probably still going to be some exception to the phpstan fixes that won't be resolved, which will live in
baseline.neon, although that's not ideal.priethor commentedon May 6, 2025
How are we getting these results? When I run PHPStan with level 1, there are no errors (and if I go up to level 2, I get more than 400). What am I missing?
pkevan commentedon May 7, 2025
Phpstan fixes that aren't resolved, live in the
baseline.neonfile. If you look at one of the closed PRs you can see the fixes and corresponding deletions from that file.There is some docs on it here: https://phpstan.org/user-guide/baseline.
pkevan commentedon May 7, 2025
Closing based on linked issues being completed/closed.