SOLVED: Generate image variation on upload (client-side image resizing)

[Clément Lambelet 2]

Hi all,

 

I'm really new to ProcessWire, maybe I missed the solution in the documentation.

I'm working on a site which involves a lot of image upload fields, and I'm always getting many timeout errors. I'm pretty sure it's because I generate too many variations on a single page load (around 20 images with 7 different sizes, for them to be responsive).

I can't use ImageSizerEngineIMagick to help (my host doesn't support it).

 

I was wondering if there was a way to hook to the process of client-side image resizing (https://processwire.com/blog/posts/processwire-3.0.63-adds-client-side-image-resizing/) to generate the different variations (as it seems really faster). If not, is there a way to generate the different variations on upload and not on page load ?

 

Any ideas and suggestions are welcome!

Edited February 6, 2018 by Clément Lambelet
Solved (not the best way…)

[dragan 1,678]

Hi Clément and welcome to the forums.

I'm not sure about hooks, but I just wanted to mention that each variation you use in your templates, is only generated once - when you first visit the page in the frontend. Every subsequent frontend visit to that page will load much faster, since PW checks if an image variation exists or not.

re: timeout errors: Are they occuring in the backend?

[Clément Lambelet 2]

Hi dragan,

thanks for your message.

I don't have any timeout error in the backend (or any error at all for that matter).

I saw that the variations are only generated once, but I'm still losing a lot of time to generate them. The last page I created had 15 pictures and it took about 7 minutes to generate all the variations (7 timeout errors). It kind of break my workflow to have to wait that much and it  really slows every other pages (which will be bad once I want to add pages to the public site).

 

Should I try to have less variations? It seems to me that for responsive images (srcset), it's okay to have 7 different sizes.

I would really prefer to have a way to generate them via the client-side image resizing script.

[dragan 1,678]

What you describe here is far, far away from what can be expected in a somewhat "normal" server / hosting setup.

If you can share a link to such pages, we could have a look at it. Or you could do this yourself - open the same page you opened as PW admin in FF/Chrome "anonymous mode".

You mentioned that IMagick is not allowed/installed on your server. Are you aware of any other server-side restrictions? Can you define custom settings via .htaccess, php.ini, user.ini or in php files with ini_set()?

Quote

I would really prefer to have a way to generate them via the client-side image resizing script.

I'm afraid someone else has to look into this (relatively new) method and check if there are options...

[Clément Lambelet 2]

Thanks for your help.

FYI, here's some server config I could find:

PHP version 		7.1
max_execution_time 	60 seconds
memory_limit 		640 Mo

I can modify .htaccess, but can't change php.ini or user.ini.

I could try to use ini_set() in a php file, but don't know what to put.

I will ask my host (infomaniak), if it would be possible to add IMagick.

 

As for the pages, they are quite simple: https://c-lambelet.com/new/en/projects/collateral-visions/

Here's the code responsible to generate the variations (excerpt):

$options = array(
  'quality' 	=> 71,
  'upscaling' 	=> false,
  'cropping' 	=> false,
  'sharpening' 	=> 'none'
);
		
if($size == 1) { // context specific, here's means full width of browser window
    $i400 = $image->width(400, $options);
	$i800 = $image->width(800, $options);
	$i1200 = $image->width(1200, $options);
	$i1600 = $image->width(1600, $options);
	$i1850 = $image->width(1850, $options);
	$i2250 = $image->width(2250, $options);
	$i2650 = $image->width(2650, $options);
	$i2880 = $image->width(2880, $options);
			
	$markup = '<img src="'.$domain.$i400->url.'"
					srcset="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw=="
					data-srcset="'.$domain.$i400->url.' 400w,
								'.$domain.$i800->url.' 800w,
								'.$domain.$i1200->url.' 1200w,
								'.$domain.$i1600->url.' 1600w,
								'.$domain.$i1850->url.' 1850w,
								'.$domain.$i2250->url.' 2250w,
								'.$domain.$i2650->url.' 2650w,
								'.$domain.$i2880->url.' 2880w"
					data-sizes="auto"
					class="lazyload"
					alt="'.$alt.' - © Clément Lambelet">';
}

---

14 hours ago, dragan said:

Quote

I would really prefer to have a way to generate them via the client-side image resizing script.

I'm afraid someone else has to look into this (relatively new) method and check if there are options...

Anyone would have an idea for this hook? I would be really interested for other uses as well (like auto tagging of the image).

[bernhard 4,721]

hi @Clément Lambelet and welcome to pw and the forum

you can also use a queue to split the work into several junks, either with your own technique or using this module: https://modules.processwire.com/modules/wire-queue/

[Clément Lambelet 2]

Hi all,

 

thanks @bernhard for this idea. I didn't know how to implement wire-queue properly.

So I went with a more simple way (for myself) which was to modify InputFieldImage.js (in wire/modules) , and make an ajax call to a script which resize the images.

I'm pretty sure it's not the best way to do that, but it's working better (the server seems to handle the resize better if it's from different requests).

It takes around 10 sec to generate the 7 sizes (with GD) compare to a 60 seconds timeout before.

 

Thanks for the help. I will mark the topic as solved.

[bernhard 4,721]

Are you aware that your changes to wire/modules/InputFieldImage.js will be lost when you update your processwire installation? I'm sure there's a better but also simple solution if you already have a working setup