-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add conditional return types for several functions #195
Conversation
No idea about
This refers to |
That's the part I find a bit challenging. 😅
Yes, it's documented, but it does not work because there is no actual code implementing |
|
@szepeviktor Should I split the pull request into several smaller ones - such as syncing with master, get_posts, get_approved_comments, get_sites, get_terms, get_tags, and the remaining functions - to make it easier to review? |
No. |
Core ticket for |
@szepeviktor I have added the count fields to the conditional return type, as well as checks for the first parameter and, if applicable, for the second parameter in |
This pull request moves the following extensions from szepeviktor/phpstan-wordpress to php-stubs/wordpress-stubs:
get_posts()
get_approved_comments()
get_sites()
get_terms()
get_tags()
wp_get_object_terms()
wp_get_post_categories()
wp_get_post_tags()
wp_get_post_terms()
Note on
wp_get_object_terms()
Despite what is suggested in the return type description ("Array of terms, a count thereof as a numeric string, or [...]") and the parameter description for
$args
("See WP_Term_Query::__construct() for supported arguments"), it appears thatwp_get_object_terms()
does not support$args = ['fields' => 'count']
. The output fromget_terms()
, which is a numeric string when['fields' => 'count']
is used, is combined/merged with an array (see src/wp-includes/taxonomy.php#L2319-L2323). This causes the function to returnnull
and trigger a warning in PHP 7.4, and is leading to a fatal error (uncaught type error) in PHP 8.0 and later.As
wp_get_post_categories()
,wp_get_post_tags()
, andwp_get_post_terms()
are wrapper functions forwp_get_object_terms()
, this limitation applies to them as well. While the documented return types forwp_get_post_tags()
,wp_get_post_terms()
, andwp_get_post_categories()
at least imply that they are not meant to return anumeric-string
(though possibly anumeric-string[]
), the parameter description for$args
still incorrectly states that "See WP_Term_Query::__construct() for supported arguments" is applicable.See core ticket: https://core.trac.wordpress.org/ticket/61936
@swissspidy, @johnbillion,
I would appreciate it if you could review what I've found regarding
wp_get_object_terms()
and the related functions. I suspect that simply casting the output ofget_terms()
to an array inwp_get_object_terms()
might allow$args = ['fields' => 'count']
to be supported with a return type oflist<numeric-string>
. I have not tested this, and I am uncertain if such a change would introduce any undesired side effects. However, this has to be fixed in WP core.Additionally, there is a
$count
query variable (distinct from the$fields
value) documented forWP_Term_Query
and referenced in the return type description for get_terms(). I couldn't determine its purpose. Could it be that this variable was mistakenly left after the corresponding functionality was removed? If so, this would also need to be fixed in WP core.