I have the following problem, we use metafields added to the SHOP variable, but on this site we can’t see it from the storefront api.
On the rest of the sites we have no problems, but looking at the documentation it said it had expired. It’s not clear to me if metafieldStorefrontVisibilityCreate will stop working now because we really use a lot of things there and it would be very cumbersome for us.
I’m trying to get the metafields that are in the SHOP variable from the front using the storefrontpi API and I’m not getting them. However, when I make the call through pstman, those metafields are there.
When I make the request through postman I can get the metafield information, as well as install an app to view from the shopify board.
Connecting with our internal teams on this, but just for our understanding, are you able to access metafields added to the Shop variable via the Storefront API on other Shopify stores, but just not one specific store? Or is this the behaviour on all stores?
I work in the same team with Alfonso.
It started happening with the last couple of stores we created.
In previous stores, we created a private app with storefront access, and made the metafields visible through metafieldStorefrontVisibilityCreate. With the last couple of stores we noticed that mutation answers with Definition not found.
As Alfonso mentioned, we know the metafields are correct because with the Admin API we can see them.
Hey @amcroce and @Alfonso_Porteous — I can’t tell exactly what you’re doing here, but it sounds very close to an edge we’ve seen a few folks run into. If my hunch is right, you’re hitting one these:
To change permissions from their default, you must have a metafield definition (as of 2024-01)
You can only change permissions for metafields you “own.” Here’s the docs that highlight this. We’ve seen a number of partners hit a wall with this, so you may see some changes here
It makes sense by the error message that we need a definition, but are you sure this is since January 2024? We created probably half a dozen of stores the first half of the year and just with the last two is we are facing issues reading the SHOP metafields.
Here´s the response given by the metafieldStorefrontVisibilityCreate mutation:
{“data”:{“metafieldStorefrontVisibilityCreate”:{“metafieldStorefrontVisibility”:null,“userErrors”:[{“field”:[“input”],“message”:“Definition not found.”}]}},“extensions”:{“cost”:{“requestedQueryCost”:10,“actualQueryCost”:10,“throttleStatus”:{“maximumAvailable”:2000.0,“currentlyAvailable”:1990,“restoreRate”:100.0}}}}
I just tried with other API versions and is doing the same.
By the way I cannot create a definition for a SHOP so there’s that.
I’m not sure how the Storefronts token can read a SHOP metafield without a definition, but I’m really eager to find out if there’s a workaround. If not, it means we’ll need to update our system to use metaobjects (I think that’s the only alternative), and doing that on short notice isn’t ideal
We were using a namespace called retailsystem for a few year until now.
It does not matter now, because last week we implemented logic to crate the metafields definitions with namespace app:retailsystem and then use the metafieldsSet mutation.
Heavy work to do in a hurry, but we have more incoming clients and we needed our features to be able to work on new sites.
Got it - that was the primary reason I was asking about the namespace. Using the app reserved version like you are now will let you control the storefront visibility bit. Let me know if you run into issues.
Hi all. I’m having a similar issue, but can’t figure out the solution here. We create metafields on articles and need these exposed via the Storefront API. We’ve always used the same mutation of metafieldStorefrontVisibilityCreate and it has always worked, until 1-2 months ago when this Definition not found error occurred.
In the grand scheme we are switching to defined metaobjects which should resolve this, but right now we have a lot of angry customers that rely on the storefront API, and we don’t know how to solve this even temporarily.
Is the stopgap solution to downgrade to before 2024-01 version?
I’m trying to avoid changing the metafield structure / creation logic as that would impact thousands of customers who have old Liquid code on their store and don’t care about the Storefront API. Again, this change will be required eventually; but doing it right before BFCM? No thanks.