Closed therealpecus closed 1 year ago
Have you set the generateTransformsBeforePageLoad
config setting to true
?
Have you set the
generateTransformsBeforePageLoad
config setting totrue
?
yes, and transforms are available on the file system
Hmm, I’ll need to look into it and will give you an update on what I find.
This seems to point to a configuration (possibly in the asset path) for console requests in the LocalWarmer.
What is the asset path set to? And if it contains an alias, how is that defined?
Hi Ben, here's the config for the asset volume
handle: assets
hasUrls: true
name: Assets
settings:
path: assets
sortOrder: 1
titleTranslationKeyFormat: null
titleTranslationMethod: site
type: craft\volumes\Local
url: $ASSET_URL
the .env sets $ASSET_URL
to:
ASSET_URL=https://mydomain.ddev.site/assets
(the example is from the dev setup, it is matched with the correct domain in staging and prod.)
Aliases are defined as:
// Custom aliases
'aliases' => [
'@rootUrl' => App::env('DEFAULT_SITE_URL'),
'@webroot' => dirname(__DIR__) . '/web',
],
From your asset volume config, it looks like the path
is set to assets
. This should be set to an absolute path such as @webroot/assets/site
, otherwise the path will not be resolvable when the request is called via a console command.
Hi Ben,
thanks, your suggestion was spot on and fixed it. I did not know that paths needed to be absolute.
Now that images work, I realized all cached pages are saved with the content of the first page being generated, despite progressing through the URLs and calling each one (debug is on). Again, only with the localWarmer. This seems like the request not being reset, or the Yii app somehow not releasing completely the previous execution.
Let me know if you prefer to track this issue in a separate ticket.
Now that images work, I realized all cached pages are saved with the content of the first page being generated, despite progressing through the URLs and calling each one (debug is on). Again, only with the localWarmer.
Is this happening in a local development environment only? The local warmer was never fully robust in all local dev environments, hence the “experimental” warning on it.
unfortunately no, it happens in production environments too.
it seems the response object is not cleared after the first emission, but there seem to be no method to reset it after saving it. I understand this is a high effort/low return issue, since the plugin has moved to v4.
unfortunately no, it happens in production environments too.
In that case, I’d put your efforts into getting the GuzzleWarmer to work (or update to Blitz 4). Even with a CDN/WAF it should be possible to add the server’s IP address to a safe list.
I understand this is a high effort/low return issue, since the plugin has moved to v4.
Indeed, this is an experimental feature of a version that is no longer in active development.
I think we can close the issue as solved. Thanks Ben
Running Craft CMS 3.8.16 with Blitz 3.12.10 and LocalWarmer.
Due to a combination of CDN+WAF setup that prevents us from using GuzzleWarmer, we're forced to generate pages via the LocalWarmer driver.
The issue we're experiencing is that image transforms come out empty in the HTML. Meaning that a call to
asset.getUrl(transform)
yieldssrc=""
, whereas calls toasset.getUrl()
yield the full URL to the asset, e.g.src="https://site/asset/resource.ext"
.Running Blitz in dev mode provides a hint, but I have not been able to trace back the code to find where the issue actually is. For some reason, mocking the request as it is done in the LocalWarmer throws when accessing the image transform:
This happens when running the console command
craft blitz/cache/warm
, which is a cron job we need to run to ensure all pages of the site are fresh and available. If the page is accessed via a regular HTTP request, the cached file content is correct.This seems to point to a configuration (possibly in the asset path) for console requests in the LocalWarmer.
I am available for further troubleshooting. I realize the LocalWarmer is experimental in v3 and that it has been completely rewritten in v4, but we cannot upgrade yet.