Rewrite Rules for Serving WebP Images with Imagify Plugin

Keywords: WordPress + NGINX + SSL - Google Cloud Platform - Technical issue - Plugins installation/configuration

bnsupport ID: 3e91ca20-4265-8193-a5fd-9930f7848f83

bndiagnostic output:

? Nginx: Found possible issues
? Wordpress: Found possible issues
https://docs.bitnami.com/installer/infrastructure/nginx/troubleshooting/

bndiagnostic failure reason: The suggested guides are not related with my issue

Description:
Hello!

I am trying to serve images in WebP format using the Imagify Wordpress plugin, but I have not been able to after multiple attempts. The plugin documentation states that I need to add the following code to my NGINX configuration:

location ~* ^(/.+).(jpg|jpeg|jpe|png|gif)$ {
add_header Vary Accept;

if ($http_accept ~* “webp”){
set $imwebp A;
}
if (-f $request_filename.webp) {
set $imwebp “${imwebp}B”;
}
if ($imwebp = AB) {
rewrite ^(.*) $1.webp;
}
}

I tried adding it in a separate configuration file in /opt/bitnami/nginx/conf/bitnami, but the images are not being served as WebP so far. I reckon it has to do with the code block that sets the cache expiry for images in the wordpress-https-server-block.conf, but I am stuck on how to make both rules work. I appreciate any help you can provide!

Best regards,

Jose Balanza

Hi @statheros,

Thanks for using Bitnami. I see the bndiagnostic tool reported some errors in the Apache logs related to a WordPress plugin. Can you check them just in case it is affecting somehow the behavior of the Imagify Plugin?

2021/09/02 18:53:42 [error] 18038#18038: *9 FastCGI sent in stderr: "PHP message: PHP Warning: Invalid argument supplied for foreach() in /bitnami/wordpress/wp-content/plugins/wp-rocket/inc/classes/dependencies/wp-media/background-processing/wp-background-process.php on line 314" while reading response header from upstream, client: **ip_address**, server: _, request: "POST /wp-admin/admin-ajax.php?action=rocket_preload&nonce=99acabbde9 HTTP/1.1", upstream: "fastcgi://unix:/opt/bitnami/php/var/run/www.sock:", host: "gelmanvision.com", referrer: "https://gelmanvision.com/wp-admin/admin-ajax.php?action=rocket_preload&nonce=99acabbde9"
 2021/09/02 19:30:14 [error] 18542#18542: *162 FastCGI sent in stderr: "PHP message: WordPress database error Access denied; you need (at least one of) the SUPER privilege(s) for this operation for query SET GLOBAL max_allowed_packet=33554432 made by do_action('wp_ajax_updraft_ajax'), WP_Hook->do_action, WP_Hook->apply_filters, UpdraftPlus_Admin->updraft_ajax_handler, UpdraftPlus_WPAdmin_Commands->restore_alldownloaded, UpdraftPlus->analyse_db_file, UpdraftPlus->max_packet_size" while reading response header from upstream, client: **ip_address**, server: _, request: "POST /wp-admin/admin-ajax.php HTTP/1.1", upstream: "fastcgi://unix:/opt/bitnami/php/var/run/www.sock:", host: "gelmanvision.com", referrer: "https://gelmanvision.com/wp-admin/options-general.php?page=updraftplus"
 2021/09/02 19:31:34 [error] 18542#18542: *185 FastCGI sent in stderr: "PHP message: WordPress database error Access denied; you need (at least one of) the SUPER privilege(s) for this operation for query SET GLOBAL max_allowed_packet=33554432 made by do_action('wp_ajax_updraft_ajaxrestore'), WP_Hook->do_action, WP_Hook->apply_filters, UpdraftPlus_Admin->updraft_ajaxrestore, UpdraftPlus_Admin->prepare_restore, UpdraftPlus_Admin->restore_backup, Updraft_Restorer->perform_restore, Updraft_Restorer->restore_backup, Updraft_Restorer->restore_backup_db, UpdraftPlus->max_packet_size" while reading upstream, client: **ip_address**, server: _, request: "POST /wp-admin/admin-ajax.php HTTP/1.1", upstream: "fastcgi://unix:/opt/bitnami/php/var/run/www.sock:", host: "gelmanvision.com", referrer: "https://gelmanvision.com/wp-admin/options-general.php?page=updraftplus"

Apart from that, the bndiagnostic tool didn’t get the information in the wordpress-https-server-block.conf file, can you share it with us? If you are following any guide to configure the plugin and NGINX for WebP support, can you share it with us so we can take a look at it?

Hi @gongomgra,

So the last two errors are related to a backup plugin, and are more than likely unrelated. The first error is coming from the cache plugin WP Rocket, which might be related. However, not a lot of info online.

Here is my wordpress-https-server-block.conf:

server {
# Port to listen on, can also be set in IP:PORT format
listen 443 ssl default_server;
root /opt/bitnami/wordpress;
# Catch-all server block
# See: https://nginx.org/en/docs/http/server_names.html#miscellaneous_names
server_name _;
ssl_certificate      bitnami/certs/server.crt;
ssl_certificate_key  bitnami/certs/server.key;
# BEGIN Fix for WordPress plugins and themes
# Certain WordPress plugins and themes do not properly link to PHP files because of symbolic links
# https://github.com/bitnami/bitnami-docker-wordpress-nginx/issues/43
rewrite ^/bitnami/wordpress(/.*) $1 last;
# END Fix for WordPress plugins and themes
# BEGIN WordPress
# https://wordpress.org/support/article/nginx/#general-wordpress-rules
location = /favicon.ico {
    log_not_found off;
    access_log off;
}
location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
}
location / {
    try_files $uri $uri/ /index.php?$args;
}
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires max;
    log_not_found off;
}
# END WordPress
include  "/opt/bitnami/nginx/conf/bitnami/*.conf";

}

Sadly, there is no guide to follow for this plugin. It just states to copy the code in the NGINX configuration file.

Hi @statheros,

Thanks for your message. According to what you shared, you didn’t edit the wordpress-https-server-block.conf file with the information mentioned in the docs you linked. I also think the wordpress-server-block.conf file needs to be updated.

After doing the configuration changes, you can restart the NGINX service by running the command below

sudo /opt/bitnami/ctlscript.sh restart nginx

Hi @gongomgra,

Sorry, I deleted my comments above due to bad formatting, and for the life of me I cant find the edit button, maybe I can’t edit because my account is fairly new lol.

I have added a .conf file in /opt/bitnami/nginx/conf/bitnami/ which should be included at the end of the server block of all the .conf files in /server_blocks. The file contains the following:

# BEGIN Imagify: rewrite rules for webp
location ~* ^(/.+)\.(jpg|jpeg|jpe|png)$ {
        add_header Vary Accept;

        expires max;
        log_not_found off;

            if ($http_accept ~* "webp"){
                set $imwebp A;
        }
        if (-f $request_filename.webp) {
                set $imwebp  "${imwebp}B";
        }
        if ($imwebp = AB) {
                rewrite ^(.*) $1.webp;
        }
}

# END Imagify: rewrite rules for webp

I followed your recommendation of adding the code above directly to both wordpress-https-server-block.conf and wordpress-https-server-block.conf, but the images are still not being served in webp format.

I have also hosted a simple test instance on a separate vm with just the imagify plugin and with the above code on both wordrpess-https-server-block.conf and wordrpess-server-block.conf files and the test image is not being served in webp either.

I am attaching the diagnostic code for the instance:

1555f9b4-850d-03a3-1426-b42476b62e43

Thank you so much for your help!

Hello @statheros,

As far as I know, those changes should be enough. I couldn’t access your site to double-check, but did you verify the content is not being served as .webp inspecting the network traffic when downloading your images? Sometimes, even if the final image appears as a .png, the served one is a .webp. You can find more info and how to check this in imagify documentation:

https://imagify.io/documentation/how-to-check-if-webp-image-is-displayed-on-your-site/

Regards,
Francisco de Paz

Hi @fdepaz,

Yes, I have checked the networking tool and I am attaching a picture. The picture in question is the todler_piano_compressed.jpg (excuse the bad spelling lol).

I am also going to leave the test instance online for a while. Its IP is http://104.196.21.38/. Let me know if you get to check it.

Hello @statheros,

You are right, it seems your site is serving the .jpg image. I suppose you enabled the option Display images in WebP format on the site using Rewrite rules in your Imagify configuration, right? Let me try to reproduce this issue on my end and come back with my findings.

Regards,
Francisco de Paz

Ok, I have managed to fix the issue.

In a desperate attempt I changed to the ShortPixel plugin instead of the Imagify plugin, but the problem was still not fixed. The solution is a little bit different, but it should work on the Imagify plugin. The problem is with the

location / {
    try_files $uri $uri/ /index.php?$args;
}

directive in the wordpress-https-server-block.conf and the wordpress-server-block.conf. This is how my wordpress-https-server-block.conf file looks now:

include "/opt/bitnami/nginx/conf/bitnami/before_server_block/*.conf";
server {
    # Port to listen on, can also be set in IP:PORT format
    listen 443 ssl default_server;
    root /opt/bitnami/wordpress;
    # Catch-all server block
    # See: https://nginx.org/en/docs/http/server_names.html#miscellaneous_names
    server_name _;
    ssl_certificate      bitnami/certs/server.crt;
    ssl_certificate_key  bitnami/certs/server.key;
    # BEGIN Fix for WordPress plugins and themes
    # Certain WordPress plugins and themes do not properly link to PHP files because of symbolic links
    # https://github.com/bitnami/bitnami-docker-wordpress-nginx/issues/43
    rewrite ^/bitnami/wordpress(/.*) $1 last;
    # END Fix for WordPress plugins and themes
    # BEGIN WordPress
    # https://wordpress.org/support/article/nginx/#general-wordpress-rules
    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }
    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }
    location / 
        include  "/opt/bitnami/nginx/conf/bitnami/shortpixel/webp-config.conf";
        try_files $uri $uri/ /index.php?$args;
    }
    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
        expires max;
        log_not_found off;
    }
    # END WordPress
    include  "/opt/bitnami/nginx/conf/bitnami/*.conf";
}

/opt/bitnami/nginx/conf/bitnami/before_server_block/webp-mapping.conf

map $http_accept $webp_suffix {
default "";
"~*webp" ".webp";
}

/opt/bitnami/nginx/conf/bitnami/shortpixel/webp-config.conf

#BEGIN Shortpixel directive
location ~* (/wp-content/.+)\.(png|jpe?g)$ {
    set $base $1;
    set $webp_uri $base$webp_suffix;
    set $webp_old_uri $base.$2$webp_suffix;
    set $root "/opt/bitnami/wordpress/";
    root $root;
    add_header Vary Accept;
    if ( !-f $root$webp_uri ) {
        add_header X_WebP_SP_Miss $root$webp_uri;
    }
    try_files $webp_uri $webp_old_uri $uri =404;
}
#END Shortpixel directive

So it is possible the try_files $uri $uri/ /index.php?$args; is messing with the nginx directives. I still don’t know if it could be solved through a better method.

1 Like

Also, this issue seems to affect all WebP serving, so it might be a good idea to create a tutorial on how to fix the directives.

Hello @statheros,

I’m glad you managed to solve the issue and thanks for sharing your solution! Given time limitations, creating a whole new guide on this may be something that our Documentation team won’t be able to work on. Nevertheless, I agree this could be really helpful for other users. As such, we will redirect any issue related to this configuration to your solution so other users can also benefit from it :smiley:

Regards,
Francisco de Paz