A space to discuss GraphQL queries, mutations, troubleshooting, throttling, and best practices.
Since this week it's not possible anymore to receive a single OnlineStorePage translation via GraphQL.
This is happening when I do a POST call to `/admin/api/graphql.json` with request data:
{ translatableResource(resourceId: "gid://shopify/OnlineStorePage/123") { resourceId translatableContent { key value digest locale } translations(locale: "nl") { key value locale } } }
I do this call via a GuzzleHttp Client, but that should not be the issue because the strange thing is that the query above works for other translatable resources, which are working perfectly.
Can you please check if there is something changed for the OnlineStorePage resource or if there is something going on?
Let me know if you need more details on this one.
Thanks in advance!
Solved! Go to the solution
This is an accepted solution.
Ok, I found the problem myself.
Looks like having the `read_translations` admin API access scope is not enough.
To receive translations for OnlineStoreBlog, OnlineStoreArticle and OnlineStorePage, you also need the `read_content` scope to access it.
For DeliveryMethodDefinition translations you need the `read_shipping` scope.
I'm a bit upset that Shopify didn't report anything related to this change in the changelog.
After this weekend also OnlineStoreBlog, OnlineStoreArticle and DeliveryMethodDefinition are affected...
OnlineStoreTheme was reported by a customer, but we can't reproduce it at this moment.
Can you please look into these affected translatable resources?
Thanks in advance!
This is an accepted solution.
Ok, I found the problem myself.
Looks like having the `read_translations` admin API access scope is not enough.
To receive translations for OnlineStoreBlog, OnlineStoreArticle and OnlineStorePage, you also need the `read_content` scope to access it.
For DeliveryMethodDefinition translations you need the `read_shipping` scope.
I'm a bit upset that Shopify didn't report anything related to this change in the changelog.
We should have caught this change of behavior. I will investigate what caused this, and why it was not exposed on changelog. Thanks for reporting a solution here.