The Shopify docs describe how to detect if an app is embedded into the theme as app block or app embed block: Configure theme app extensions
To identify our own app block in the settings_data.json we need to check the type for this structure: <partner_name>://apps/<app_name>/blocks/<block_name>/<unique_ID>
However, the docs do not mention how the <app-name> is constructed, e.g. faceforms-better-pop-ups
I checked that that this is NOT the app handle. It looks like it is the actual app name, lowercased and whitespaces replaced with dashes. If that is true, then updating the app name does NOT update the <app-name> in the app blocks type field.
You’re right that the app name portion can be a bit tricky to work with, especially if you’re updating the handle.
At the moment, our recommended approach is actually to use the unique ID at the end of the type string to identify your app blocks. As mentioned in our docs, each app block type includes a unique ID that identifies your app (like f2173231-e611-461d-884b-bd8e6cc2ded4 in your example).
So instead of relying on the app name portion, you can detect your app blocks by checking if the type ends with your app’s unique ID.
You could also use your partner name as an additional identifier by checking if the type starts with your partner prefix (e.g., shopify://apps/), which gives you another stable way to filter for your app blocks if you wanted to look at that as a route.
Hope this helps clarify things, please feel free to ping me here if I can look into things further for you, happy to help!
thanks for the quick answer! The <unique_ID> is the Shopify extension ID SHOPIFY_<EXTENSION_NAME>_ID, right? Because the docs now say this ID is deprecated:
You could also use your partner name as an additional identifier by checking if the type starts with your partner prefix (e.g., shopify://apps/ ), which gives you another stable way to filter for your app blocks if you wanted to look at that as a route.
What do you mean with partner prefix? The type starts with shopify://apps/, or am I missing something?
Hey @zirkelc - no worries, appreciate you following up here. You’re right about the <partner-name> prefix, I did some digging and it does look like it’s always going to show up as shopify in the settings_data.json template file, even for third party apps.
It does look like the uuid value that’s appended to the end of your block’s type value does come from that deprecated field like you mentioned from what I can tell as well. I’m going to do some more digging internally to see if we have concrete recommendations for you, definitely fair questions on this, we’ll get this looked into!
Hey @zirkelc - No worries at all! I was able to touch base with our product team here and I can confirm that App blocks and app embeds can continue to rely on the UUID value to identify functionality related to your block/embeds. The UUID parameter is only deprecated for deep link functionality.
I was also able to confirm that for JSON templates, that prefix will always be shopify://apps.
Hope this helps - let me know if I can clarify anything more on my end here!
Hey @Alan_G thank you for getting back to me on this - very much appreciated!
That’s unfortunate, I was hoping I could get rid of UUID because there’s a bug in the Shopify CLI, so the UUID is only available after deploying a Shopify app. That makes the release flow of a new app version a little more complicated. I’ve described the problem in this issue: [Bug]: extension ID missing in `app env pull` · Issue #4225 · Shopify/cli · GitHub
Nevertheless, this topic is solved for now. Thank you again!
No problem at all @zirkelc, I’ll mark this thread as solved, but just want to make sure I’m understanding things correctly. Are you still seeing the issue you mentioned in that GH issue where the shopify app env pull command doesn’t pull extension IDs to the .env file?
It does look like our developers have confirmed this is expected behaviour as of September of last year, but I can see if I can confirm the current roadmap with them to see if there’s anything more we can share with you.
Can’t guarantee anything on my end, but happy to do a bit more digging or at least set up a documented feature request as well for you.
I was hoping the deprecation of the UUID (extension ID) in the docs would mean we don’t need the .env file at compile time.
The problem is that shopify app env pull creates an env file with only the SHOPIFY_API_KEY and SHOPIFY_API_SECRET values. The UUID of the extension (name SHOPIFY_<extension>_ID is missing.
Here is my current build and deploy workflow:
In order to get SHOPIFY_<extension>_ID, I first have to deploy a new version but without release: shopify app deploy --no-release. This creates the .env with the extensions UUID. Then I can build my app because all environment variables are available at build time. Now I have to either run shopify app deploy again to actually release a new version, or run shopify app release with the version created in the first build step.
The workflow works, it just takes unnecessary long and creates lots temporary (unreleased) versions:
Hey @zirkelc - Thanks for confirming and for the extra details here, really appreciated! This does seem like a bit of a tricky situation for sure.
I’ll follow up with the team internally here and loop back with you once I have more info or can confirm that I’ve sent up the feature request, appreciate your patience on this as well!
