Hello 
We are trying to clone themes. We noticed a bug where an asset was not copied over properly.
These assets are rendered properly in the main theme, but in our copied theme, they show up as invalid image placeholders since they weren’t copied over.
Upon further investigation, the theme has two assets with the following behavior:
- The assets are returned if we don’t query for
body.
- The assets are not returned when we query for
body.
Here is our query:
const GET_THEME_FILES: DocumentNode = gql`
query getThemeFiles(
$themeId: ID!
$after: String
$filenames: [String!]
$includeContent: Boolean = false
) {
theme(id: $themeId) {
files(first: 250, after: $after, filenames: $filenames) {
nodes {
filename
checksumMd5
body @include(if: $includeContent) {
... on OnlineStoreThemeFileBodyText {
content
}
... on OnlineStoreThemeFileBodyUrl {
url
}
... on OnlineStoreThemeFileBodyBase64 {
contentBase64
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
}
`;
Speculation
GraphQL Theme Query: theme - GraphQL Admin
OnlineStoreThemeFile object: OnlineStoreThemeFile - GraphQL Admin
My theory: since body is non-null in the object, Shopify is filtering out assets with invalid / corrupted / non-existant bodies if we request the body.
Questions
- Am I making a silly mistake in my above query?
- Can anyone provide information about why these assets don’t have bodies?
- Is there any workaround to get the asset’s content?
1 Like
Hey @bsenescu
Thanks for reaching out! Could you share examples of the responses you’re getting when querying with and without the body field? I’m needing a little more clarity what type of assets are being affected and why they might be behaving differently with and without the body. It would also be helpful if you could provide the x-request-id from the API response headers that returned unexpected results.
For my own curiosity, I’m wondering what your use case is for using the admin API to clone a theme? The reason I ask is the CLI may be better suited for this task.
Thanks for the quick reply!
Use Case: We clone the theme because our app makes programmatic fixes via the API to the cloned theme. This allows our users to review and test them prior to release. We don’t have developer access to these stores so I don’t think we can use the CLI?
Response if I request the body:
x-request-id: 7cbd05fa-6b71-44f2-870d-72c570f53731-1745272843
{
"data": {
"theme": {
"files": {
"nodes": [],
"pageInfo": {
"hasNextPage": false,
"endCursor": "ImFzc2V0c1wvQXNzZXQgNC5zdmci"
}
}
}
},
"extensions": { .... }
}
Response if I don’t request the body:
x-request-id: e421c497-fe47-41c3-a38d-5c84f36a76bf-1745272687
{
"data": {
"theme": {
"files": {
"nodes": [
{
"checksumMd5": "adae0046b259b2ddd50d9e1beb3f81ca",
"contentType": "image/svg+xml",
"filename": "assets/Asset 3.svg",
"size": "579",
"createdAt": "2024-11-22T14:23:21Z",
"updatedAt": "2024-11-22T14:23:21Z"
},
{
"checksumMd5": "6b3812ea5a5e20d6de3cc6efdf38b7a3",
"contentType": "image/svg+xml",
"filename": "assets/Asset 4.svg",
"size": "428",
"createdAt": "2024-11-21T11:41:20Z",
"updatedAt": "2024-11-21T11:41:20Z"
}
],
"pageInfo": {
"hasNextPage": false,
"endCursor": "ImFzc2V0c1wvQXNzZXQgNC5zdmci"
}
}
}
},
"extensions": { ... }
}
Thanks for sharing that @bsenescu
That makes sense in your use case to do this. Looking at the responses, this does seem to be expected behavior in that an svg image isn’t one of those union types, although it is strange that the other requested fields weren’t returned at all.
I’ll look in to this some more to see what I can find out for you.
Thanks for looking into it further! Would love to hear what you find as I do believe this is a bug on shopify’s end or at least is undocumented behavior.
To clarify, this theme has other svg’s that do return valid bodies either via the content or url fields.
1 Like
Some more details:
As a workaround, I manually downloaded the svgs, converted them to base64, then reuploaded them via themeFileUpsert graphql mutation.
Now the files appear properly in the theme, but same problem where when we query for them, they don’t appear if we request the body (in this case contentBase64).
However, I made a request for all assets and confirmed that other assets with contentBase64 bodies are being returned.
x-request-id: 9d3c17b1-35e2-41d1-9efa-16b13d6505b9-1745528555
Here is the request id for my upsert as well if that helps: x-request-id: 502f7c79-004c-4c17-a05c-975eeb0d64f3-1745512900
1 Like
Thank you! I’m still looking to get more information on why this is happening. The request ID’s should help 
Thank you! Do you have any general idea of timelines? We’re trying to decide whether we should build a more robust workaround.
Hi @KyleG-Shopify,
I just narrowed down what’s going on here. Hopefully, this is a quick fix on Shopify’s end.
The assets which aren’t being returned when $includeContent is true all have spaces " " in the file name.
If I upload the same asset value, but with a filename with no spaces, then the body is returned when $includeContent is true
Request Ids
Here is the request id creating the new assets: 4d11c8c8-7e83-4a69-8c85-53a3cfb4cf1a-1746809485
Here is the request id fetching the asset bodies for these new assets (Note: these are the same asset bodies from the previous request ids): 5858064b-03c2-4ed6-835c-897c6b4fedb3-1746810197
Thank’s for sharing that! I have passed your findings on and will update you here when I can!