wp-bootstrap / wp-bootstrap-navwalker

A nav item is an instance of WP_Post. There's nothing like WP_Nav_Menu_Item in WordPress. If I want to know what to expect from $item, I won't find anything when searching for WP_Nav_Menu_Item because I have to search for WP_Post to find the properties and methods of $item and I will find it here https://developer.wordpress.org/reference/classes/wp_post/. And then I know that I can do, eg $item->to_array(). Also, you won't find anything if you search the core files for WP_Nav_Menu_Item. That's what people do. They're not going to test and then to phpstan and then to eg class-wp-nav-menu-item.php. Why would they?

The same goes for WP_Nav_Menu_Args. It simply does not exist in the WP world. You won't find any occurrence in the WP core. Why? Because it is an object and not an instance of a class. WP_Post, WP_Customize, WP_Query and so on indicate instances of the WP_Post, WP_Customize, WP_Query class and so on.

If the only reason to introduce WP_Nav_Menu_Args and WP_Nav_Menu_Item is to

wp-bootstrap-navwalker/tests/phpstan/class-wp-nav-menu-item.php

Line 5 in 0743d59

* Created to aid static analysis by PHPStan.

then IMHO it should be dropped. The purpose of an inline documention is documention and not testing/analysing. In this case I even find it misleading. It forces everyone (!) to dig around what WP_Nav_Menu_Args and WP_Nav_Menu_Item actually are, because those 'classes' just don't exist outside phpstan. Apart from that IMO this deviates from WordPress coding standards. In core files you will find WP_Post instead of WP_Nav_Menu_Item.

And last but not least the intended usage of the WP Bootstrap Navwalker is to place the class-wp-bootstrap-navwalker.php in the theme folder. There even won't be a tests/phpstand/class-wp-nav-menu-item.php where I can find what WP_Nav_Menu_Args or WP_Nav_Menu_Item is.

No offense, I know you took the time to implement the phpstan stuff and everyone appreciates the time people are devoting to FOSS projects, but still I think we should discuss this.

Hello! Thank you for the long issue!
WP_Post cannot be extended but WordPress core stuffs extra properties into it when dealing with nav menus.
That is their bad part.

What you have written is our bad part :)

-1 and +1 cancel each other and voila you can run static analysis to make your code robust!

Maybe it's me but looking at the code I don't really see the benefit. Could you please give me a hint where to look at? The only code change I see is this

wp-bootstrap-navwalker/class-wp-bootstrap-navwalker.php

Lines 338 to 340 in 0743d59

    
           if ( ! current_user_can( 'edit_theme_options' ) ) { 
        
           	return; 
        
           }

Instead of having the long if statement it's an early return. Calling that making the code robust may be a little exaggeration though it's good for readability. Also if { ... } changed to if ... endif;. I don't think that this is an robustness issue but someone's preference (and imo inconsistent).
However, maybe I just don't feel comfortable with calling an instance of WP_Post WP_Nav_Menu_Item...

Calling that making the code robust

Robustness means static analysis will run on every commit and looks much deeper than humans. That's it.

Hi @szepeviktor , can we fix this?

This must be WP 5.6 stubs...
I think the only way is it to put these two into ignoreErrors:

What is `WP_Nav_Menu_Args` and `WP_Nav_Menu_Item`?