PHP Stan Results

[kraftbj]

Level 1 PHPStan revealed the following issues, which are in the baseline file.

[pkevan]

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]

The same issue exists in many other classes, where multiple class variables are required in order to satisfy phpstan.

[kraftbj]

@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.

Open to other thoughts.

[pkevan]

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.