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
Describe the bug
For some reason, downloadsRemaining is not always of type integer and sometimes is a numeric string.
To Reproduce
Not 100% how to reproduce since this doesn't seem to be mentioned in other issues and I'm not sure if it's a generalized issue of a feature no one uses or something more specific to my setup.
In my case I changed the downloadsRemaining field using the order ui after purchase. GraphiQL kept showing null as the value which invited me to look into this.
Maybe this change post-sale is what causes the type to be of type string instead of the expected integer.
Expected behavior
The plugin should handle the different possible types of the property to ensure it doesn't return null when it's a valid value of type string.
Screenshots
If applicable, add screenshots to help explain your problem.
Plugin Versions
WooGraphQL Version: 0.21.0
WPGraphQL Version: 1.28.1
WPGraphQL CORS Version: 2.1
WordPress Version: 6.8.1
WooCommerce Version: 9.1.2
I'm not currently using the latest versions for all plugins for compatibility reasons with another plugin (will update at a later date once development of the project is done).
Additional context
Opening a PR with the fix. It mirrors the approach used in WooCommerce's templates where they use is_numeric() to check for a valid value:
Describe the bug
For some reason,
downloadsRemaining
is not always of typeinteger
and sometimes is a numeric string.To Reproduce
Not 100% how to reproduce since this doesn't seem to be mentioned in other issues and I'm not sure if it's a generalized issue of a feature no one uses or something more specific to my setup.
In my case I changed the
downloadsRemaining
field using the order ui after purchase. GraphiQL kept showingnull
as the value which invited me to look into this.Maybe this change post-sale is what causes the type to be of type
string
instead of the expectedinteger
.Expected behavior
The plugin should handle the different possible types of the property to ensure it doesn't return
null
when it's a valid value of typestring
.Screenshots
If applicable, add screenshots to help explain your problem.
Plugin Versions
I'm not currently using the latest versions for all plugins for compatibility reasons with another plugin (will update at a later date once development of the project is done).
Additional context
Opening a PR with the fix. It mirrors the approach used in WooCommerce's templates where they use
is_numeric()
to check for a valid value:https://github.com/woocommerce/woocommerce/blob/e5cc0747d0cd997a947c0df6822925c9842d269a/plugins/woocommerce/templates/myaccount/my-downloads.php#L37
I then parse it as an integer using
intval()
.The fix doesn't change the intended behavior of the plugin, it only ensures a correct parsing of valid values in order to not nullify them on the API.
The text was updated successfully, but these errors were encountered: