Problems while image in queue or if missing in cache

Here is the configuration for nginx by media converter for wordpress plugin – which does not support avif in the free version – but I never had problems with images not loading – unlike this plugin:

# BEGIN Converter for Media
set $ext_avif ".avif";
if ($http_accept !~* "image/avif") {
    set $ext_avif "";
}

set $ext_webp ".webp";
if ($http_accept !~* "image/webp") {
    set $ext_webp "";
}

location ~ /wp-content/(?<path>.+)\.(?<ext>jpe?g|png|gif|webp)$ {
    add_header Vary Accept;
    expires 365d;
    try_files
        /wp-content/uploads-webpc/$path.$ext$ext_avif
        /wp-content/uploads-webpc/$path.$ext$ext_webp
        $uri =404;
}
# END Converter for Media

Basically I love that the images are NOT stored in the uploads folder – because it makes backups much easier. However if the drawback is that as long as files are stuck in conversion – but the website tells the browser to download the converted one – and it cannot fallback to the original image – then this is not acceptable. I really think there needs to be a fallback to the orignal wp-content/upload/ folder for not yet available images.

I think this is independant of caching plugins like wp fastest cache – or does webp & avif image optimizer alter the page sourcecode? I still don’t understand why I got this huge problem with pictures with JPG instead of jpg extension, and also problems with pictures that have a ” ” blank in their filename. I had to alter the page content and remove blanks to make them work.

Oh yeah – and htaccess on my website is ignored. I wonder why the plugin tries to write into htaccess at all on nginx. Maybe that’s where the problems come from?

Actually I think the solution is something like this:

https://stackoverflow.com/questions/40264617/using-try-files-alongside-rewrite-in-nginx-location-block

The rewrite has to be referenced within the try_files block, so it’s possible to fallback to the old directoryif the cache does not exist yet . The current way simply does not work.

Also to avoid a match with a browser not accepting avif or webp a solution like media converter for wordpress? needs to be taken. First test if the browser accepts avif or webp – then serve the file – otherwise render the try_files into a non match.

This is flawed – but it should be something similar:

// 1. set the extension to .webp or .avif if supported
	set $ext_avif ".avif";
	if ($http_accept !~* "image/avif") {
    set $ext_avif "";
	}

	set $ext_webp ".webp";
	if ($http_accept !~* "image/webp") {
    set $ext_webp "";
	}
	
// 2. Try_files for the files and rewrite if file exists - otherwise fallback to original file (however exchange extension with webp/avif if it exists locally e.g. created by another plugin)
	
location ~* wp\-content/(?!cache/fastware\-webpavif).+\.(jpe?g|png|gif|bmp|webp)${
add_header Vary Accept;
expires 365d;
try_files 
@rewrites$uri.pref$ext_avif @rewrites$uri.pref$ext_webp @rewrites$uri$ext_avif @rewrites$uri$ext_webp

$uri.pref$avif $uri.pref$webp $uri$avif $uri$webp $uri /?fw-webp-avif-ondemand=all;
		}
	
location @rewrites {location ~* wp\-content/(?!cache/fastware\-webpavif).+\.(jpe?g|png|gif|bmp|webp)$ {
		rewrite /wp\-content/(.+)$ /wp-content/cache/fastware-webpavif/$1;
	}
}

Hi @extremecarver ,

Thank you for your valuable input.

>>?but the website tells the browser to download the converted one – and it cannot fallback to the original image – then this is not acceptable

Let me first explain something: the functionality is: on the first request to “/?fw-webp-avif-ondemand=all” – the original image is hardlinked/copied to the cache folder to serve as an immediate fallback, while the conversion is queued. When this image does not exist (and it seems it doesnt in your case) – there is something wrong with the nginx rules. (maybe conflicting?)

>> if ($http_accept !~* “image/avif”)…

I tried to avoid if’s in nginx – as they are evil according to the nginx docs ;).

But I’ll try to use your feedback to improve the nginx rules in the next few weeks.

Hmm, did you delete my messages after your reply? I think I found the problem about the JPG vs jpg. your plugin picks up JPG for conversion – but the nginx rule will not fire if the file is called JPG. So while it is no problem for wordpress to load a file called

picture.jpg when requesting picture.JPG – your plugin will make this impossible because the nginx rule will not fire correctly then.

I guess changing to

location ~* cache/fastware-webpavif.+.(jpe?g|JPE?G|png|PNG|gif|GIF|bmp|BMP)$ {

would solve this problem. It’s not that uncommon to use JPG instead of jpg especially for windows users where case does not matter. I guess wordpress itself has some fallback for uppercase/lowercase on files

Hi @extremecarver

>>?I think I found the problem about the JPG vs jpg. your plugin picks up JPG for conversion

that’s correct, but I assumed uppercase extensions cannot occur in WordPress, because WordPress converts the filenames to lowercase when uploading.

I’ll solve this as soon as possible so that also uppercase extensions are handled correctly.

Many people upload images without media library. I never use the media library and upload via FTP. So such things can happen.

I solved another problem – using this plugin somehow increases memory usage a lot on first load of a page with many big pictures – and this clashed with the firewall rule

limit_conn_zone $limit_key zone=addr:2m;

No I don’t know where zone addr is defined (i looked quite long but couldn’t find it – maybe it’s something default by fail2ban or nginx), but I think the problem is just that it ran out of memory on this zone – and then crashed. So increases this to 20m solved it. Maybe this should be mentioned somewhere. I still don’t understand it really. even with addr:10; it sometimes crashed.

However the real reason is – this plugin somehow doesn’t work together with lazy load by wordpress fastest cache. I will open up another topic as this is not too related. Because lazy load isn’t working – it will crash any limits if you have a page with 20-30 pictures of each 1-2MB in size…

As for the main nginx block: I tried changing the nginx to this – but somethings doesn’t work and I get 404 – but this looks much better (if I find out the small error) – the rewrite should go to root – and then just put the path in front. The last two block setting png extension for browsers which cannot read webp (any browser that can read avif can also read webp I think) is maybe a bit more wrong…

But this way we can avoid the dreaded if inside location block and still use a separate cache folder.

location ~* wp\-content/(?!cache/fastware\-webpavif).+\.(jpe?g|png|gif|bmp|webp)$ {
		rewrite /wp\-content/(.+)$ /$1;
}
	
location ~* cache/fastware\-webpavif.+\.(jpe?g|png|gif|bmp)$ {
		add_header Vary Accept;
		expires 365d;
		try_files /wp-content/cache/fastware-webpavif/$uri.pref$avif /wp-content/cache/fastware-webpavif/$uri.pref$webp /wp-content/cache/fastware-webpavif/$uri$avif /wp-content/cache/fastware-webpavif/$uri$webp /wp-content/cache/fastware-webpavif/$uri /wp-content/uploads/$uri /wp-content/themes/$uri /wp-content/plugins/$uri /wp-content/$uri $uri /?fw-webp-avif-ondemand=all;
	}
	
set $ext_png ".png";
	if ($http_accept !~* "image/webp") {
    set $ext_png "";
	}
	
location ~* cache/fastware\-webpavif.+\.webp$ {
		add_header Vary Accept;
		expires 365d;
		try_files /wp-content/cache/fastware-webpavif/$uri$ext_png /?fw-webp-avif-ondemand=png;
	}

Oh no actually the above nginx command works perfect. I have the problem that this plugin partly destroys my lazy load – so that’s why I no get 503 on pages that have loads of non cached pictures.

Please check the above nginx – I’m not able to test the last line about webp not being accepted by the browser and if that one is correct. But it works way better than the original nginx command and doesn’t require a nested if inside location and has a real fallback to the original file. Maybe you can even skip the hardlink?

I’m not fully sure about pictures which are stored outside of wp-content – e.g. in website root /pictures – again yeah bad form but such a thing should not break a website. I think it works with my nginx but maybe not yet robust enough. Maybe this also fixes JPG jps and similar shenanigans.

• This reply was modified 1 year, 8 months ago by extremecarver.

Ups cannot edit anymore – but all problems are just to the rubbish nginx command. Below is a working one – Actually we do not need that fallback for browsers which don’t accept webp or avif – as they are covered in the first big command already, or am I still not understanding the redirects. Make sure this command follows directly after the root = folder command. If it comes before it will not work!

## Add support for "WebP + AVIF converter" WordPress plugin - full fallback in case plugin has error!
location ~* wp\-content/(?!cache/fastware\-webpavif).+\.(jpe?g|png|gif|bmp|webp)$ {
		rewrite /wp\-content/(.+)$ /$1;
}
	
location ~* (jpe?g|png|gif|bmp|webp)$ {
		add_header Vary Accept;
		expires 365d;
		try_files /wp-content/cache/fastware-webpavif$uri.pref.avif /wp-content/cache/fastware-webpavif$uri.pref.webp /wp-content/cache/fastware-webpavif$uri.avif /wp-content/cache/fastware-webpavif$uri.webp /wp-content/cache/fastware-webpavif$uri /wp-content/uploads$uri /wp-content/themes$uri /wp-content/plugins$uri /wp-content$uri /?fw-webp-avif-ondemand=all;
}
	
set $ext_png ".png";
	if ($http_accept !~* "image/webp") {
    set $ext_png "";
}
	
location ~* (jpe?g|png|gif|bmp|webp)$ {
		add_header Vary Accept;
		expires 365d;
		try_files /wp-content/cache/fastware-webpavif$uri$ext_png /?fw-webp-avif-ondemand=png;
}

Ups – the above breaks microsoft edge by showing avif pictures that it cannot load – so it should be like this (however strangely only works in Chrome – I cannot get edge to load webp, while it loads avif super strange. Chrome loads both avif and webp – so some bug related to edge?):

	## Add support for "WebP + AVIF converter" WordPress plugin
    ## https://www.ads-software.com/plugins/fastware-webpavif/#installation
	location ~* wp\-content/(?!cache/fastware\-webpavif).+\.(jpe?g|png|gif|bmp|webp)$ {
		rewrite /wp\-content/(.+)$ /$1;
	}
	
	set $ext_webp ".webp";
	if ($http_accept !~* "image/webp") {
    set $ext_webp "";
	}
	
	set $ext_avif ".avif";
	if ($http_accept !~* "image/avif") {
    set $ext_avif "";
	}
	
	location ~* (jpe?g|png|gif|bmp|webp|avif)$ {
		add_header Vary Accept;
		expires 365d;
		try_files /wp-content/cache/fastware-webpavif$uri.pref$ext_avif /wp-content/cache/fastware-webpavif$uri.pref$ext_webp /wp-content/cache/fastware-webpavif$uri$ext_avif /wp-content/cache/fastware-webpavif$uri$ext_webp /wp-content/cache/fastware-webpavif$uri /wp-content/uploads$uri /wp-content/themes$uri /wp-content/plugins$uri /wp-content$uri $uri /?fw-webp-avif-ondemand=all;
	}

• This reply was modified 1 year, 8 months ago by extremecarver.
• This reply was modified 1 year, 8 months ago by extremecarver.

And the plugin is not able to understand that nginx command – so stops converting new images and sticks with old cache only.

• This reply was modified 1 year, 8 months ago by extremecarver.

Alternatively this again works fine in Chrome but not in Edge…. It’s even simpler:

	set $ext_avif ".avif";
	if ($http_accept !~* "image/avif") {
    set $ext_avif "";
	}
 
	set $ext_webp ".webp";
	if ($http_accept !~* "image/webp") {
    set $ext_webp "";
	}
	
	
	location ~ /wp-content/(?<path>.+)\.(?<ext>jpe?g|png|gif|webp)$ {
    add_header Vary Accept;
    expires 365d;
    try_files 
	/wp-content/cache/fastware-webpavif/$path.$ext.pref$ext_avif
	/wp-content/cache/fastware-webpavif/$path.$ext.pref$ext_webp
	/wp-content/cache/fastware-webpavif/$path.$ext$ext_avif
	/wp-content/cache/fastware-webpavif/$path.$ext$ext_webp
	/wp-content/cache/fastware-webpavif/$path.$ext
	$uri
	/?fw-webp-avif-ondemand=all;
}

• This reply was modified 1 year, 8 months ago by extremecarver.

I don’t understand why webp is not served in edge on frontend (it is served for images on dashboard). All other browsers are fine and showing avif or webp (if avif not available)

Thinking about performance – this plugin should work a bit differently. First create webp file – if it is bigger than original – delete.

Then create avif file. If bigger than original or eventual webp delete. skip the pref naming stuff. Yeah it’s nice for debugging if something goes wrong – but it simply creates more try_files calls (and each try that does not hit costs performance) and it needs less space on disk.

The curent is really using unneeded resources. Based on the above the easiest is then the following nginx code (and skip all that map stuff, what is that needed for??)

Then a much easier code would be:

   set $ext_webp "";
	if ($http_accept ~* "image/webp") {
    set $ext_webp ".webp"; }
	if ($http_accept ~* "image/avif") {
	set $ext_avif ".avif"; }

	location ~ /wp-content/(?<path>.+)\.(?<ext>jpe?g|png|gif|webp)$ {
    add_header Vary Accept;
    expires 365d;
    try_files 
	/wp-content/cache/fastware-webpavif/$path.$ext$ext_avif
	/wp-content/cache/fastware-webpavif/$path.$ext$ext_webp
	$uri
	=404;
	}

Okay – finally got it working. No I don’t know why putting a dot in front of $ext mattered – and removing the dot from the extension. But now it works. So remove any kind of map craziness, any kind of redirect – and this simple code will work perfectly in all browsers and fall back to original image if it cannot find the newly created one.

It still would save some resources to not copy the original file – and to not do this .pref stuff – it just creates way more data and useless tries on the try_files. As most browsers support avif – and soon likely edge too – and avif in general being the smalles/best compression efficiency first call should go to avif, second to webp and third simply fallback to original image.

yeah maybe create .skipped so it doesnt try again – or handle that via database instead (not sure what is easier/more efficient).

## Add support for "WebP + AVIF converter" WordPress plugin - full fallback in case plugin has error!
	set $ext_avif "avif";
	if ($http_accept !~* "image/avif") {
    set $ext_avif "";
	}
 
	set $ext_webp "webp";
	if ($http_accept !~* "image/webp") {
    set $ext_webp "";
	}
	
	
	location ~ /wp-content/(?<path>.+)\.(?<ext>jpe?g|png|gif|webp)$ {
    add_header Vary Accept;
	add_header Access-Control-Allow-Origin *;
    expires 365d;
    try_files 
	/wp-content/cache/fastware-webpavif/$path.$ext.pref.$ext_avif
	/wp-content/cache/fastware-webpavif/$path.$ext.pref.$ext_webp
	/wp-content/cache/fastware-webpavif/$path.$ext.$ext_avif
	/wp-content/cache/fastware-webpavif/$path.$ext.$ext_webp
	$uri
	=406;
}