I have cms.domain.com with Craft installed and www.domain.com at my public, statically generated site. My config contains:
'siteUrl' => 'https://www.domain.com',
'baseCpUrl' => 'https://cms.domain.com',
My GraphQL query is:
query getTower($slug:[String!]) {
entries(slug:$slug) {
... on towers_tower_Entry {
image { url @transform(width: 1920) }
}
}
}
The response contains:
"image": "https://www.domain.com/index.php?p=actions/assets/generate-transform&transformId=1"
I expected it to contain:
"image": "https://cms.domain.com/index.php?p=actions/assets/generate-transform&transformId=1"
My guess is that baseCpUrl isn't being used by the transform graphql directive.
I looked at #5145 but thought this could be a seperate issue in the event it's unique to the graphql API.
Thanks!
I believe it’s just based on the base URL set on the asset volume – have you checked that?
Thanks for the quick reply! In my case, that is set to something different since I'm using Digital Ocean Spaces for the asset volume. In my case, it's like: https://example.sfo2.digitaloceanspaces.com/. Which is working properly, fwiw, when I set the @transform directive to be immediately.
Sorry, I had missed that this is for an asset transform generation URL. In that case it’s going to use the base URL of the current site, as GraphQL requests are technically “site requests”.
I’m thinking we should probably just always generate transforms immediately over GraphQL API requests, since it’s not like the GraphQL request is holding up the web page’s TTFB or anything, like normal web requests can.
Yeah, that sounds fair. I was trying to use non-immediately during dev/staging to speed up the response time from the API.
Another workaround option is to transform the URL returned by the GraphQL query before I use it, swapping one hostname with the other.
Made that change for the next 3.4 release.
Craft 3.4.2 is out now with that change.
I have some questions about this report, I have a use-case where I don't want the images to be transformed immediately because for me they do block TTFB. I don't mind the transform urls to be cached for a short time.
I'm using Craft behind a javascript SSR site and the GQL query to show a page blocks for a long time if there are lots of transforms to be done, and this blocks the server from rendering the page which blocks the pageload.
The biggest problem I have is that the urls that are generated are just wrong, and honestly I think that is still a bug. The site is using craft as a headless CMS using GQL and the url that the CMS generates is plain wrong.
Is there a way to add some kind of config setting or hook so urls to actions are correctly generated by craft?
If this is the wrong place to discuss this I can open a new ticket if you want.
@Zae what URL would you expect and what is the URL generated?
Also, if you set the immediately argument to false, the images won't be transformed immediately.
Hi @andris-sevcenko
I'm expecting the same URL as weotch was: https://cms.domain.com/index.php?p=actions/assets/generate-transform&transformId=1
https://domain.com/index.php?p=actions/assets/generate-transform&transformId=1 is the URL of another application using Craft as a backend using GQL. That action URL will not work here, because that is not the URL of Craft.
If I set the argument immediately to false craft generates an action url to transform the image later, but the url is wrong.
@Zae There is an open feature request to make it possible for GraphQL transforms to be lazy-generated: #6597
We’ve just implemented the original request here, for the next 3.6 release. Going forward, all action URLs (such as assets/generate-transform) will point to the control panel, when Craft is running in headless mode.
Craft 3.6 has now been officially released ✨
Most helpful comment
We’ve just implemented the original request here, for the next 3.6 release. Going forward, all action URLs (such as
assets/generate-transform) will point to the control panel, when Craft is running in headless mode.