2.x Fix PHPStan issues on level 2

[gchtr]

Issue

There are various issues raised by PHPStan on level 2.

Solution

This pull request fixes some of them.

One special case was that for menu items, we set some properties dynamically. Menu items are WP_Post objects that are extended with the following properties: object_id, menu_item_parent, object and type.

To allow these properties to be written dynamically, I added a Class Reflection Extension for PHPStan. You can see this in the new tests/phpstan/WPNavMenuItemPost.php class.

There are some issues that I couldn’t resolve yet.

Type is not subtype of native type

I didn’t know how to solve this one. Any help is welcome.

------ -------------------------------------------------------------------------------------------
  Line   AccessesPostsLazily.php (in context of class Timber\PostArrayObject)
 ------ -------------------------------------------------------------------------------------------
  71     PHPDoc tag @return with type Timber\PostCollectionInterface is not subtype of native type
         Timber\PostArrayObject.
 ------ -------------------------------------------------------------------------------------------

 ------ -------------------------------------------------------------------------------------------------------------
  Line   AccessesPostsLazily.php (in context of class Timber\PostQuery)
 ------ -------------------------------------------------------------------------------------------------------------
  71     PHPDoc tag @return with type Timber\PostCollectionInterface is not subtype of native type Timber\PostQuery.
 ------ -------------------------------------------------------------------------------------------------------------

Access to undefined property on WP_Post

 ------ -----------------------------------------------------------------------------------
  Line   Post.php
 ------ -----------------------------------------------------------------------------------
  505    Access to an undefined property WP_Post::$status.
  506    Access to an undefined property WP_Post::$id.
  507    Access to an undefined property WP_Post::$slug.
 ------ -----------------------------------------------------------------------------------

This is related to dynamically setting properties on a WP_Post object that will later be imported in the Post::get_info() function. It would be better to set these properties on the Timber\Post object after the other properties are imported. But there’s a timber/post/import_data filter, which might rely on these properties.

$data = $post->get_info($wp_post);

$post->import(apply_filters('timber/post/import_data', $data));

I think there are a couple of solutions:

1. Ignore the errors.
2. Don’t set the properties on WP_Post and update the filter.
3. Whitelist the properties through a Class Reflection Extension.

Impact

More robust code.

Usage Changes

None.

Considerations

None.

Testing

Covered through existing tests.

Todo

• Fix coverage

[gchtr]

With the changes in #2674, the Access to an undefined property shouldn’t be a problem anymore.

[Levdbas]

I went through all the code except the tests. That is not really (yet) in my ballpark.

[nlemoine]

Thanks for you work on this @gchtr. To pass PHPStan higher levels, we will probably have to be stricter regarding types, for method arguments as well as return types.

[nlemoine]

Thanks for you work on this @gchtr. To pass PHPStan higher levels, we will probably have to be stricter regarding types, for method arguments as well as return types.