Replies: 7 comments
-
Oh man, so very much this. The time for hardcore processor crunching is on edit, not when a member of the public is trying to see a page. |
Beta Was this translation helpful? Give feedback.
-
Great feature. Might also be worth looking into the processing happening via task as well. |
Beta Was this translation helpful? Give feedback.
-
(Sort of related: #1690) |
Beta Was this translation helpful? Give feedback.
-
So if this never gets rolled into core, this plugin does it for you: https://github.com/nystudio107/craft3-imageoptimize (amongst other things) |
Beta Was this translation helpful? Give feedback.
-
Adding my +1 for this (having just changed an image source over and witnessed a painful rebuild of all the thumbs everywhere) |
Beta Was this translation helpful? Give feedback.
-
Not to necro and old thread here but... I also ran into this issue. :) I found a hacky way to do this using the WebHooks plugin. I created a webhook which fires on asset save and then used twig to make a get request to the asset url transform (i.e. Edit: The above does work, but with a big caveat. The webhooks plugin by default stores the response body of a request and tries to insert it into the database. This is problematic for large binaries to say the least. My workaround was to create a site module with a simple controller that took the assetId and transform handle as parameters and then made a GET request to the transform url via Guzzel... Working so far. :) Hope this helps any other poor souls who stumble across here. |
Beta Was this translation helpful? Give feedback.
-
Jumping off of @kara-todd 's suggestion I created a module but instead of using Guzzle, I called the getUrl function on the Asset directly. Imagetransforms added using the CMS can be used but I already had existing images and I didn't want to change the URL. Hence I used arrays. Code below: class ArticleThumbnailsModule extends Module
{
private const THUMBNAIL_SIZES = [
['width' => 100, 'height' => 200],
['width' => 200, 'height' => 400],
['width' => 300, 'height' => 600],
];
...
public function init()
{
parent::init();
self::$instance = $this;
Craft::info(
Craft::t(
'article-thumbnails-module',
'{name} module loaded',
['name' => 'Article Thumbnails']
),
__METHOD__
);
Event::on(
Elements::class,
Elements::EVENT_AFTER_SAVE_ELEMENT,
function (ElementEvent $event) {
$element = $event->element;
if (!($element instanceof Entry)) {
return;
}
$this->generateArticleThumbnails($element);
}
);
}
private function generateArticleThumbnails(Entry $entry)
{
$section = $entry->getSection() ?? null;
if (!$section || $section->handle != 'article') {
return;
}
$thumbnailImageQuery = $entry->fieldValues['thumbnailImage'] ?? null;
if (!$thumbnailImageQuery) {
return;
}
$thumbnailImageAsset = $thumbnailImageQuery->first();
if (!($thumbnailImageAsset && $thumbnailImageAsset instanceof Asset)) {
return;
}
// All required images.
foreach (self::THUMBNAIL_SIZES as $size) {
$this->getThumbnailUrl($thumbnailImageAsset, $size);
}
}
private function getThumbnailUrl(Asset $asset, array $size)
{
$transformBase = ['mode' => 'crop', 'position' => 'center-center'];
$transform = array_merge($transformBase, $size);
// Generate the images.
$asset->getUrl($transform);
}
} |
Beta Was this translation helpful? Give feedback.
-
Generating asset transforms can be very time-consuming, and they happen when speed is critical: when servicing frontend requests, either when the page is loaded, or when the transform is requested (depending on the config setting).
Instead, it would be very useful to be able to have the asset transforms when an Asset is uploaded, at which time performance is not critical.
The way I'd envision it working would be that there would be a checkbox per Asset source:
[X] Generate transforms on Asset upload
And then with a list of the available transforms so you can choose which ones should be generated, and which ones would not. Thus as soon as a client uploads an image, the transforms needed on the frontend will automatically be created for them.
This has the added bonus of triggering
EVENT_GENERATE_TRANSFORM
so plugins like my ImageOptim plugin would be able to optimize the images—which can also be time-consuming—on image upload, rather than slowing down front-end requests.The fallback path of it checking to see if the transformed image exists on the frontend request would still be there, of course, in case the transformed images are somehow removed after they've been uploaded.
If the user chooses to
Update Asset Indexes
it would similarly cause all of this to be rebuilt at a time when performance is non-critical.If you use dynamic transforms in your templates, they would not be able to benefit from this, but I think that's a reasonable separation to make.
Beta Was this translation helpful? Give feedback.
All reactions