Wordpress Cache-Enabler Plugin Cache Enabler Plugin best config?

Yeah cache enabler header is a hit more miss. Best way to test if it's working is if you benchmark/stress test your server and check which processes are loaded nginx and/or php-fpm. If advanced caching is working, then under load most of it will be from nginx and not php-fpm.

 

Well there's conflicting info from Cody at KeyCDN for cache enabler at Please Explain This | WordPress.org

and their advanced-cache.php code line at keycdn/cache-enabler also suggests if x-cache-handler wp is set then advanced cache is in use

PHP:

// set cache handler header
header('x-cache-handler: wp');


 

no if you get that header means advance caching is working as expected = optimal

again, best way to test if it's working is if you benchmark/stress test your server and check which processes are loaded nginx and/or php-fpm. If advanced caching is working, then under load most of it will be from nginx and not php-fpm.

You can see in my thread at https://community.centminmod.com/th...ugins-for-page-load-speed-optimization.15039/ as well.

 

PHP has to run to create the initial cache entry. Then advanced cache at Nginx level handles logic of whether to serve from cache or not - the logic is handled by Nginx and not PHP (normal non-advanced mode).

Code (Text):

try_files $cache_enabler_uri $uri $uri/ $custom_subdir/index.php?$args;

where $cache_enabler_uri is defined by

Code (Text):

    # default html file
    set $cache_enabler_uri '${custom_subdir}/wp-content/cache/cache-enabler/${http_host}${cache_uri}index.html';

    # webp html file
    if ($http_accept ~* "image/webp") {
        set $cache_enabler_uri '${custom_subdir}/wp-content/cache/cache-enabler/${http_host}${cache_uri}index-webp.html';
    }

again, best way to test if it's working is if you benchmark/stress test your server and check which processes are loaded nginx and/or php-fpm. If advanced caching is working, then under load most of it will be from nginx and not php-fpm.

 

that is required otherwise you will served cached webP versions of your HTML pages to non-webP supported web browsers

 

Guess it can be removed if you don't serve webP image files. It's part of official cache enabler advanced configuration so has it's purpose otherwise.

 

you can also benchmark the speed between removed code vs code intact too and see if there's a difference

 

from official cache enabler page regarding webP code in nginx advanced config

So technically if you do not serve webP files, there will be no webP cached HTML file so served from Nginx via normal cached HTML file. I'd expect if your case with versus without the webP html line, performance would be the same then as cached files are served via Nginx - as would same be for webP served files, just served via Nginx webP HTML generated cache file instead.

 

Did your benchmark load tests confirm this or you assuming just behind PHP-FPM service stopped and still served from cache, that it's better ? See https://community.centminmod.com/threads/cache-enabler-plugin-best-config.19113/#post-81397 conflicting info but you're mixing cache logic versus cache creation.

I am pretty sure x-cache-handler: wp load tests still only show majority of the load from Nginx and not PHP-FPM the last time I tested. Unless it has changed since.

 

Just did a fresh centmin.sh menu option 22 wordpress with cache enabler install on 123.09beta01 and x-cache-handler: wp does bypass PHP-FPM and stress test load is only on Nginx. However, seems I came across an interetsing bug on cache enabler plugin activation it should add

Code (Text):

define('WP_CACHE', true);

to wp-config.php

but it seems to not do that on initial install. Manually adding makes it work. If i deactivate cache enabler plugin from wp-admin, it does remove WP_CACHE true setting so it isn't a wp-config.php file permission issue. But re-activating cache enabler plugin, doesn't re-add WP_CACHE true setting in wp-config.php.

Using PHP 7.4.2 so not sure if it's related

 

yes within browser sessions dev network tab but not with SSH curl header checks