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!
Hey @zirkelc - no worries! I was able to speak with the product team on this for you and just wanted to confirm that after working with them on this, your current workaround is the best option for now and would be what we’d recommend at the moment.
Eventually, we are intending on moving away from using the registration UUIDs in favour of another solution like the handle of an app, but I can’t speak to specifics on that at the moment since it’s not something that we have on the roadmap for the near-term.
Another workaround our product team suggested is to grab your app’s UUID during the testing phase as you addapp blocks in your test stores. That should be easily retrievable from theme data on testing shops since it doesn’t change.
Hope this helps/makes sense - let me know if I can clarify anything on our end here as always!
I need to come back to this topic. Since this thread contains a lot of information already, I thought it’s best if I continue here instead of starting a new one.
They have now been migrated from an old UUID to the new UID which seems to be unique across multiple `shopify.app..toml` files.
Furthermore, the old `SHOPIFY__ID` environment variable containing the UUID not generated any longer.
However, checking if an app is embedded still requires the old UUID. I tested my app on a new dev store and it wasn’t using the new UID.
That means we currently have the situation that we do not know the UUID at development or deploy time. Rather, we only know it after we install and embed an app block and then read and parse the UUID from the `blocks`:
Here, the UUID is `f2173231-e611-461d-884b-bd8e6cc2ded4`.
Could you please check with the product team to verify this is still the right way to do it and we still need the UUID here? If so, I think it would be really helpful to add this info to the docs that 1) we still need the old UUID and 2) where we can find the old UUID.
Currently, we have the situation that there is a new UID format ( Migrate from the Partner Dashboard ) and the UUID is being deprecated ( Configure theme app extensions ).
Clarifying to make sure I’m understanding correctly. Essentially, the new platform is generating UIDs for extensions now instead of the old UUIDs, and the environment variable SHOPIFY_<extension>_ID that used to contain the UUID isn’t being generated anymore? But for older theme blocks, they’re still using the old UUID format in that type string?
And since you can’t know what that UUID is until after you’ve actually installed and embedded the app block, there’s no way to programmatically check if your app is embedded during development or deployment time?
Just to make sure I’m following, or is it that only the new UIDs are popping up and you’re no longer able to see the old ones, even on earlier installed blocks?
I’m happy to reach out internally about this, but wanted to confirm I’m understanding the situation correctly first so we can get this looked at properly. This does seem like something that needs addressing.
Let me know if I’ve got that right and I’ll look into this on our end here, hope to speak soon.
Yes, you got it right: all apps have been migrated from the Partner Dashboard to the Next-Gen Platform. Part of this transition is that the old extension UUIDs (that were available from SHOPIFY_<extension>_ID env variables) have to be mapped to a new UID that’s written down into the extensions’ shopify.extension.toml file.
This is all good, having one UID in the .toml file is much better than previous env variables.
The issue is that app embed blocks, both existing and new ones, still use the old UUID from the env variable. Example: I need to check if my app was embedded in the theme. The Detecting app blocks and app embed blocks recommend to use the Asset REST API to read the theme and look for this type of block:
Thanks for confirming @zirkelc, appreciate the clarification here. I’ll reach out to some folks internally on my end and dig into this further for you to clarify expected behaviour/if we’ve flagged this as a potential unintended effect on our end. I’ll loop back with you once I have more info to share
Hey @zirkelc - thanks for waiting on my response here, looping back with some info as I’ve had some time to work with folks internally on this.
Right now, the best immediate workaround we have is to use the theme editor to add the block, and then open the code editor and inspect the settings_data.json to grab the needed info. My understanding is that we are looking into adding functionality to check if blocks are enabled within the App Bridge API, but this would be more medium-term and I can’t guarantee exactly when that would be released or what the exact functionality would look like.
I did want to mention that this is something we’re aware of though as a limitation and some work has been done on this internally. Hope this helps, let me know if I can clarify anything on my end and thanks again for flagging this!
