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
I believe i noted this in #136, but just in case: the ideal fix from a schema perspective is to make all width/height attributes a CssUnit { value: Int, unit:CssUnitTypeEnum } or similar, where the unit type defaults if there isn't an explicit one.
@justlevine I'm sure you did. We're in the process of converting from Jira to GitHub for the teams own work and, as much as I tried to catch all the dupes in moving over work, I'm sure there are a few.
Steps to Reproduce
Check CoreImageAttributes
width
type in GraphQLi. It is of type String.Issue
CoreImageAttributes.width is of type String.
Expected Behavior
CoreImageAttributes.width should be of type Float.
Additional Information
Note any other relevant details.
Related ticket:
CoreImageAttributes.width
is typeString
, but should be aFloat
· Issue #136 · wpengine/wp-graphql-content-blocksYou need to revert the following commit: Bug: CoreImage width attribute resolve throws error. (#130) · wpengine/wp-graphql-content-blocks@28fca4a
However we need to document the failing unit test case and provide a workaround for this error.
The workaround is to use an alias for the
attributes
field so that GrapgQL can resolve the types without any conflicts.The text was updated successfully, but these errors were encountered: