keycdn / cache-enabler Goto Github PK

Probably what would be one of the most useful features of this plugin.

Thanks for this really helpful plug-in first!

I think it'll be very cool if brotli or zopfli support can be added in this plug-in, not sure what do you think?

Currently, the plugin only targets only the following attributes: src, srcset and *-ref for changing the output to use .webp if the file exists.

It would be good to also target background images and those lazy-loaded (using attributes like 'data-bg'.

I have come up with a crude implementation:

# ... From line 286 cache_enable_disk.class.php

// Call the webp converter on background images
// TODO: Optimise this regex
$bg_regex_rule = '#(?:(?<=background-image: url)|(?<=background: url)|(?<=background-image:url)|(?<=background:url))(?:\([\'"]?)(.*?)(\.png|\.jp[e]?g)(.*?)(?:[\'"]?\))#';

$converted_data = preg_replace_callback($bg_regex_rule, function ($asset) {
    return _convert_webp_bg($asset[1] . $asset[2]);
}, $converted_data);

// Call the webp converter on data-bg
$databg_regex_rule = '#(?<=(?:(data-bg)=[\"\']))(?:http[s]?[^\"\']+)(\.png|\.jp[e]?g)(?:[^\"\']+)?(?=[\"\')])#';

$converted_data = preg_replace_callback($databg_regex_rule, function($asset) {
    return self::_convert_webp_src($asset[0]);
}, $converted_data);

The function _convert_webp_bg is based off of _convert_webp_src

function _convert_webp_bg($src) {
    $upload_dir = wp_upload_dir();
    $src_url = parse_url($upload_dir['baseurl']);
    $upload_path = $src_url['path'];

    if (strpos($src, $upload_path) !== false) {

        $src_webp = str_replace('.jpg', '.webp', $src);
        $src_webp = str_replace('.jpeg', '.webp', $src_webp);
        $src_webp = str_replace('.png', '.webp', $src_webp);

        $parts = explode($upload_path, $src_webp);
        $relative_path = $parts[1];

        // check if relative path is not empty and file exists
        if (!empty($relative_path) && file_exists($upload_dir['basedir'] . $relative_path)) {
            return sprintf('(%s)', $src_webp);
        } else {
            // try appended webp extension
            $src_webp_appended = $src . '.webp';
            $parts_appended = explode($upload_path, $src_webp_appended);
            $relative_path_appended = $parts_appended[1];

            // check if relative path is not empty and file exists
            if (!empty($relative_path_appended) && file_exists($upload_dir['basedir'] . $relative_path_appended)) {
                return sprintf('(%s)', $src_webp_appended);
            }
        }

    }

    return sprintf('(%s)', $src);
}

but we return the $src wrapped in parenthesis

I prepared Polish language for your plugin. It seems to me it's complete. It's here:

lang-PL.zip

Some WordPress themes add background-images via inline style on divs or even inline-css etc.

I am using webp express for auto generating webp files and that plugin works for background images.

It would be nice if cache enabler also replaces the inline background images with .webp if the image exists, like it does for -Tags.

examples:
style="background-image: url(https://www.DOMAIN.de/wp-content/uploads/2015/10/4.jpg)"

.header-bg { background-image: url(/wp-content/uploads/silder/themen.jpg) !important; }

1.3.5 is not released, but is listed in the changelog.

Would love to see it released so we can use the wp-cli :)

Hi there,
Is there any chance we can get a filter or constant added to override the "CDN URL" var?
This should be settable programmatically / configurable in code imo.
Cheers.

It would be great if I could manually cache files and not wait for the user to visit the said in order to be cache. My cached folder mounted on tmps, which means access is really fast. The problem with my site is that there is an enormous amount of traffic any given time, so when I update the website, all the caches get deleted and CPU usage is off the rail until the cache fills up by any reasonable level, which can hours. if there was a CLI option of manually create cache file all the current content. It would be great. Also, I think there is a bug and even when you choose not to clear the whole cache when a new post is submitted, it still clears the whole cache.

Hope you will take this suggestion into consideration.

Hello,

I have a lot of php warnings in the debug log.

Here is an example :

[03-Jun-2019 12:52:07 UTC] PHP Warning:  scandir(/srv/.../htdocs/wp-content/cache/cache-enabler/www.wesbite.com/lycee-general/2nde-generale-et-technologique): failed to open dir: No such file or directory in /srv/.../htdocs/wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php on line 355
[03-Jun-2019 12:52:07 UTC] PHP Warning:  scandir(): (errno 2): No such file or directory in /srv/.../htdocs/wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php on line 355
[03-Jun-2019 12:52:07 UTC] PHP Warning:  array_diff(): Argument #1 is not an array in /srv/.../htdocs/wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php on line 357
[03-Jun-2019 12:52:07 UTC] PHP Warning:  unlink(/srv/.../htdocs/wp-content/cache/cache-enabler/www.wesbite.com/lycee-general/baccalaureat-general-specialite-numerique-et-sciences-informatiques-nsi): No such file or directory in /srv/.../htdocs/wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php on line 371
[03-Jun-2019 12:52:07 UTC] PHP Warning:  unlink(/srv/.../htdocs/wp-content/cache/cache-enabler/www.wesbite.com/lycee-general/baccalaureat-s-sciences-de-ingenieur-si): No such file or directory in /srv/.../htdocs/wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php on line 371
[03-Jun-2019 12:52:07 UTC] PHP Warning:  unlink(/srv/.../htdocs/wp-content/cache/cache-enabler/www.wesbite.com/lycee-general/index.html): No such file or directory in /srv/.../htdocs/wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php on line 371
[03-Jun-2019 12:52:07 UTC] PHP Warning:  unlink(/srv/.../htdocs/wp-content/cache/cache-enabler/www.another-website.fr): No such file or directory in /srv/.../htdocs/wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php on line 371

Environnement :

WPMU 4.9.8
PHP 5.6
Cache Enabler 1.3.4

Other things to know :

The cache expiration is set to 0, in order the cache never expires.
I use mapbox for my maps and so I generate all hours a new temporary token.
Each time I get this new temporary token, I clear the cache for all the websites via third party

Hi,

great plugin. It would be even better if the plugin could be configured by wp-cli :)

Especially:
Clear the complete cache if a new post has been published
Clear the complete cache if a new comment has been posted
Clear the complete cache if any plugin has been upgraded

PHP Notice: Undefined index: HTTP_HOST in /var/www/superstore.wearede.com/public/plugins/cache-enabler/inc/cache_enabler_disk.class.php on line 603

My custom wp-cli command creates WooCommerce product drafts. Why is it triggering delete settings at all?

Would be great to have the plugin tie into the wp cache flush command and purge the cache/cache-enabler/* directory, or have its own wp-cli command to clear those pages. We run wp transient delete-all && wp cache flush after each Jenkins deployment. While that takes care of the Redis object cache, it does not affect the advanced-cache which must be purged from the UI or a scripted rm -rf <path-to-cache-dir> command.

I can do this, however, wp eval "Cache_Enabler::clear_total_cache();"

Hey, guys!
Thank you for the helpful plugin!

I have a small question: does plugin have some filters/actions to execute my function on clearing cache?

Allow the cache to be completely cleared if a plugin is activated or deactivated. In my opinion extending the option that clears the cache if a plugin has been updated would work best (e.g. Clear the complete cache if a plugin has been activated, updated, or deactivated.).

WordPress topic: https://wordpress.org/support/topic/suggestion-clear-the-complete-cache-if-plugin-disabled-enabled/

Hey there,
great plugin! I love cache enabler.
The description lists that this is "HTTP/2 focused".
What does that mean?
Are the page assets like css & js being pushed?

First of all, thanks for providing CacheEnabler-Plugin. It works great and appears to be the best solution I tried so far.

When having CacheEnabler, Autoptimizer plus (probably) one other Plugin (e.g. Yoast SEO which itself only shows an icon here) being displayed on the adminbar, it messes up layout for smaller desktop screens.

Actually one could hardly call this a bug and also, it's not related to CacheEnabler in particular. Moreover it is because of the plugin nature of Wordpress and its dynamic toolbar. Might also not be seen as critical because only a certain range of dimensions is affected in some cases.
It's a common issue with header navigation having lots of entries, in particular regarding localization.

But since it could be easily fixed or let's say "disarmed" on your side, it would be great if this could be improved.

Possible Solutions would of course be, e.g. Using an icon with the label as title-tooltip or having both menu items collapsed in a dropdown.

It was indeed good news when Firefox added webp support in Firefox 65. And this works fine with Cache Enabler, as Firefox 65 adds "image/webp" to the Accept request header, both when making image requests, and for the document.

However, Firefox 66.0 has changed the behavior. It still adds "image/webp" to image requests, but no longer adds it for documents. This means that Cache Enabler fails to serve webp files to Firefox 66.

Do you have any idea on how to overcome this?

I have thought about inspecting the User-Agent header, looking for Firefox/66 and above. However, it is possible for users to disable webp support in Firefox. That setting will probably only be used by very few people, but still.

Perhaps you could let the user decide. That is, add an option if Cache Enabler should serve the webp version to Firefox 66 and above.

One of the best if not the best plugin for caching. I was wondering how difficult it would be to add Varnish?

I just did a fresh test install of Wordpress 5.3.2 with cache enabler on CentOS 7.7 64bit, Nginx 1.17.8 with PHP 7.4.2 and on activation of plugin, define('WP_CACHE', true); is not being added to wp-config.php. The advanced-cache.php is being properly copied to wp-content directory though. So I manually added define('WP_CACHE', true); to wp-config.php.

However, it seems to properly add define('WP_CACHE', true); to wp-config.php when using PHP 7.3.14 !

On deactivation of cache enabler plugin, define('WP_CACHE', true); is properly removed on wp-config.php. So this suggests it isn't a wp-config.php permissions issue at least ? So what would prevent the auto addition of define('WP_CACHE', true); to wp-config.php on cache enable plugin activation ? PHP 7.4 vs 7.3 related ? I have tried with autoptimize related wp plugins disabled as well and same issue.

php -v
PHP 7.4.2 (cli) (built: Jan 29 2020 04:35:37) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.2, Copyright (c), by Zend Technologies

php -v
PHP 7.3.14 (cli) (built: Feb  3 2020 23:30:56) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.14, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.14, Copyright (c) 1999-2018, by Zend Technologies

WP-CLI 2.4.0
WP-Home    http://cache-enabler.domain.com
WP-SiteURL http://cache-enabler.domain.com
WordPress  version:   5.3.2
Database   revision:  45805
TinyMCE    version:   4.960  (4960-20190918)
Package    language:  en_US

+--------------------+----------+--------+---------+
| name               | status   | update | version |
+--------------------+----------+--------+---------+
| akismet            | inactive | none   | 4.1.3   |
| autoptimize        | active   | none   | 2.6.1   |
| autoptimize-gzip   | active   | none   | 0.1     |
| cache-enabler      | active   | none   | 1.3.4   |
| cdn-enabler        | inactive | none   | 1.0.9   |
| classic-editor     | active   | none   | 1.5     |
| disable-xml-rpc    | active   | none   | 1.0.1   |
| sucuri-scanner     | active   | none   | 1.8.22  |
| advanced-cache.php | dropin   | none   |         |
+--------------------+----------+--------+---------+

On file cache_enabler_disk.class.php, line 290, would be great to have a filter inside $converted_data variable, e.g.:

$converted_data = apply_filters( 'cache_enabler_disk_converted_content', preg_replace_callback($regex_rule,'self::_convert_webp',$data) )

This way anyone can filter the content to make any replacements and have them store in cache (e.g. add webp to bg images).

Hi there, I believe I've found a bug. I've been installing this on old sites that are http but occasionally cache enabler caches the pages with all the assets as https. This results in none of the page assets loading and I get an html only site. I could fix this with my htaccess but it seems like something the plugin should handle.

CE 1.4.1
WP 5.5

i run ConfigServer on the server and use it to monitor for changed files - since the 1.4.1 update, i'm getting notices of changes to /cache-enabler/settings/cache-enabler-advcache-.json every few minutes, yet there seems to be no changes made to the file

this was not the case with the previous version

possible bug?

Cache is currently saved to WP_CONTENT_DIR. '/cache/cache-enabler'.

This makes cached pages accessible if you hit the file URL (ex: http://domain.com/wp-content/cache/cache-enabler/domain.com/hello-world).

It would be nice to allow developers to filter this location.

Cache Enabler v1.4.4 seems to be breaking the default WP v5.5 sitemap (/wp-sitemap.xml) - it looks like /wp-sitemap-index.xsl is not loading

when CE is enabled, it takes 1 or 2 refreshes of wp-sitemap and i'm seeing this where all formatting is gone...

https://12bytes.org/wp-sitemap-posts-post-1.xmlhttps://12bytes.org/wp-sitemap-posts-page-1.xmlhttps://12bytes.org/wp-sitemap-taxonomies-category-1.xmlhttps://12bytes.org/wp-sitemap-users-1.xml

this is reproducible about 90% of the time, but not 100%

I use wp-cli to install keycdn cache enabler. What would be best way to auto enable some of those cache enabler options for compression etc ?

I have illustrated the problems and limitations of the regex here: https://regexr.com/46isf

I can see Cache Enabler creating the directory and .html structure as the website gets browsed and everything works fine except for the homepage.

Under the directory (in this case), /wp-content/cache/cache-enabler/beardifulman.com/

Is empty, there is no index.html file. I can't figure it out. Could it be a conflicting rule from htaccess preventing this page being cached properly?

Any help is appreciated. Site in question is Beardifulman

Hi, I ran into these errors in the server log:
[21-Jan-2019 11:22:17 UTC] PHP Fatal error: Uncaught TypeError: Argument 1 passed to timezone_offset_get() must be an instance of DateTimeZone, instance of DateTimeZone given in /home/xxxxx/public_html/wp-includes/functions.php:4610 Stack trace: #0 /home/xxxxx/public_html/wp-includes/functions.php(4610): timezone_offset_get(Object(DateTimeZone), Object(DateTime)) #1 /home/xxxxx/public_html/wp-includes/class-wp-hook.php(288): wp_timezone_override_offset(false) #2 /home/xxxxx/public_html/wp-includes/plugin.php(203): WP_Hook->apply_filters(false, Array) #3 /home/xxxxx/public_html/wp-includes/option.php(58): apply_filters('pre_option_gmt_...', false, 'gmt_offset', false) #4 /home/xxxxx/public_html/wp-includes/functions.php(66): get_option('gmt_offset') #5 /home/xxxxx/public_html/wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php(248): current_time('timestamp') #6 /home/xxxxx/public_html/wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php(271): Cache_Enabler_Disk::_cache_signatur() #7 /home/xxxxx/public_html/wp in /home/xxxxx/public_html/wp-includes/functions.php on line 4610

No idea why or when this is caused...

I've managed to make Cache Enabler cach search results when setup via advanced caching with Nginx server as outlined at https://github.com/centminmod/pretty-search-url. But would be much easier if you can update Cache Enabler to support a configurable admin option as to whether search is cacheable or not. This would allow folks to not have to modify cache_enabler.class.php

with https://github.com/centminmod/pretty-search-url plugin and nginx changes

    if ($args ~* s=(.*)) {
      set $cache_uri $request_uri;
      set $check_surl $cache_uri;
      set $cache_uri /search/$1;
    }
    add_header Check-Uri "$check_surl";
    add_header Set-Uri "$cache_uri";

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

with wordpress search cached

load test with my forked wrk

wrk-cmm -t4 -c50 -d20s --latency --breakout http://cache-enabler.domain.com/search/worldpress+cache/
Running 20s test @ http://cache-enabler.domain.com/search/worldpress+cache/
  4 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.01ms    4.16ms  99.65ms   97.01%
    Connect   159.21us   71.17us 288.00us   58.33%
    TTFB        1.00ms    4.16ms  99.64ms   97.01%
    TTLB       10.21us   32.01us  11.02ms   99.97%
    Req/Sec    23.94k     9.82k   45.89k    64.12%
  Latency Distribution
     50%  415.00us
     75%  603.00us
     90%    1.19ms
     99%   10.78ms
  1907359 requests in 20.04s, 35.79GB read
Requests/sec:  95189.83
Transfer/sec:      1.79GB

direct query search cached

wrk-cmm -t4 -c50 -d20s --latency --breakout http://cache-enabler.domain.com/?s=wordpress+cache             
Running 20s test @ http://cache-enabler.domain.com/?s=wordpress+cache
  4 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   738.15us    2.44ms 108.60ms   95.81%
    Connect   144.73us   69.16us 280.00us   60.42%
    TTFB      724.86us    2.44ms 108.58ms   95.81%
    TTLB       13.46us   58.63us  14.02ms   99.96%
    Req/Sec    26.26k     6.27k   39.64k    70.00%
  Latency Distribution
     50%  351.00us
     75%  546.00us
     90%    1.21ms
     99%    7.54ms
  2092164 requests in 20.03s, 50.16GB read
Requests/sec: 104448.19
Transfer/sec:      2.50GB

versus with wordpress search non-cached

compared to default without wordpress search cache

cached search at 95,189 OR 104,448 requests/sec versus non-cached search at 332 requests/sec

wrk-cmm -t4 -c50 -d20s --latency --breakout http://cache-enabler.domain.com/?s=wordpress+cache            
Running 20s test @ http://cache-enabler.domain.com/?s=wordpress+cache
  4 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   143.66ms   16.60ms 238.90ms   68.44%
    Connect   165.79us   83.37us 334.00us   56.25%
    TTFB      143.60ms   16.60ms 238.79ms   68.47%
    TTLB       63.16us   25.84us   1.19ms   85.77%
    Req/Sec    83.38     14.48   121.00     68.62%
  Latency Distribution
     50%  144.40ms
     75%  154.74ms
     90%  163.80ms
     99%  185.14ms
  6663 requests in 20.02s, 181.04MB read
Requests/sec:    332.85
Transfer/sec:      9.04MB

Dead code

In advanced-cache.php file

the line 91 have a undefined variable $timeout_file.

unlink($timeout_file);

In some cases when a page is requested without a trailing slash (e.g. https://www.example.com/about) the cached file is returned instead of bypassing the cache to allow a redirect to a location with the trailing slash appended (e.g. https://www.example.com/about/).

Bypassing the cache to allow a redirect when a request to a page is missing the trailing slash, as WordPress currently does by default, was introduced to the Cache Enabler plugin in version 1.2.3 and added to in 1.3.1.

WordPress topic: https://wordpress.org/support/topic/do-not-cache-redirect-pages/

d81cd47 fixed a critical bug but you did not release a new version. You just silently updated the 1.3.1 version that I installed before the fix. So I never got the critical update.

If WordPress is installed in a subdirectory and the Site Address (URL) setting is different than the WordPress Address (URL) setting the wrong URL will be retrieved when clearing the home page cache through Cache_Enabler::clear_home_page_cache() or site(s) cache by blog ID through Cache_Enabler::clear_blog_id_cache(). This would lead to unsuccessful cache clearing in those events.

If the hosts are different then an incorrectly named advanced cache settings file would be created in wp-content/plugins/cache-enabler/settings. This would lead to the Cache Enabler settings not working when the cache is handled by the advanced cache.

Solution would be using get_home_url(), which gets the Site Address (URL) setting, instead of get_site_url(), which gets the WordPress Address (URL) setting. The Site Address (URL) setting is where the front end is accessible and will determine the cache structure.

WordPress topic: https://wordpress.org/support/topic/updating-a-post-does-not-clear-homepage-cache/

Site requests using any special patterns should not result in the request being cached by Cache Enabler.

Some of the example patterns which can cause recursive issues are as follows.
Double pipes
Parentheses
Double backslash

Hi !

I have been using Cache Enabler + Autoptimize for a few days without any issue.

Yesterday I changed the Expiry setting from 24 to 0, and after that change my cache was cleared but it has not been rebuilt again.

No matters what I try (disabling, deleting and reinstalling the plugin), the cache size is always "empty" and even the cache-enabler folder under "wp-content/cache" does not exist anymore.

Any suggestion about how to force a new cache?

Thanks !!

First thanks for your great plugin - we first used another caching solution for a high-traffic website but unfortunately none really worked as we needed it to. Nevertheless there is still one issue I hope you can help with (by adding a new feature ;-)

Currently if you publish a post, the related html file only gets created if the URL is called once by a non-logged in user. On our site (where an additional htcache is used in front of Wordpress) this lead to database timeouts, as we experienced a peak immediately after the post was published (and as there was not enough time to initialize the htcache based on the html file created by cache enabler).

In the best case, the risk for this to happen again could be reduced by adding two features/option to the plugin:

1. add an option to initialize a single cache html file immediately after a post is published

2. add an option to initialize the full cache for all content if a sitemap url is given (in this case, the plugin could trigger a job to crawl all URLs from the sitemap so that the cache gets prefilled before a real person hits the page)

I think these feature could be helpful to other high-traffic sites too.

If this is not possible, is there perhaps a best practice on how to best automatically initialize the cache without waiting for the first non-logged-in user?

Related thread on WP.org forums https://wordpress.org/support/topic/fatal-error-call-to-a-member-function-cache_size-on-null/

[06-Nov-2018 15:13:17 UTC] PHP Fatal error:  Uncaught Error: Call to a member function cache_size() on null in /home/xxx/public_html/wp-content/plugins/cache-enabler/inc/cache_enabler.class.php:822
Stack trace:
#0 /home/xxx/public_html/wp-content/plugins/cache-enabler/inc/cache_enabler.class.php(789): Cache_Enabler::get_cache_size()
#1 /home/xxx/public_html/wp-includes/class-wp-hook.php(286): Cache_Enabler::add_dashboard_count(Array)
#2 /home/xxx/public_html/wp-includes/plugin.php(203): WP_Hook->apply_filters(Array, Array)
#3 /home/xxx/public_html/wp-admin/includes/dashboard.php(316): apply_filters('dashboard_glanc...', Array)
#4 /home/xxx/public_html/wp-admin/includes/template.php(1073): wp_dashboard_right_now('', Array)
#5 /home/xxx/public_html/wp-admin/includes/dashboard.php(230): do_meta_boxes(Object(WP_Screen), 'normal', '')
#6 /home/xxx/public_html/wp-admin/index.php(160): wp_dashboard()
#7 {main}
  thrown in /home/xxx/public_html/wp-content/plugins/cache-enabler/inc/cache_enabler.class.php on line 822

seems to be happening on the admin dashboard.

I've received a few reports regarding Cache Enabler breaking AMP pages as generated by the AMP plugin:

• https://wordpress.org/support/topic/move-from-amp-to-amp/
• https://wordpress.org/support/topic/lot-of-amp-error-in-the-google-searsh-console/
• https://wordpress.org/support/topic/really-sick-of-getting-errors-from-amp/
• https://wordpress.org/support/topic/website-bugging-and-not-showing-amp-version/
• https://wordpress.org/support/topic/gsc-showing-errors/

There seems to be some fundamental conflict with the output buffering being done by the AMP plugin and the output buffering done by Cache Enabler. The AMP plugin starts output buffering at the template_redirect action. I don't see why this would be a conflict, nevertheless.

Anyway, I wanted to alert you to the issue. I'm a developer of the AMP plugin, and I'm happy to help investigate why it is incompatible.

There is a workaround for sites using the AMP plugin in Transitional mode or Reader mode, but not Standard mode.

After switching from more complex caching solutions, Cache Enabler works like a charm. Thank you for this great, minimalistic plugin!

There is however one shortcoming:

Caching currently only works if the HTTP request contains either no GET variables at all, or some of the GET variables used for campaign tracking by Google Analytics (utm_source, utm_medium, utm_campaign, as hardcoded in advanced-cache.php, line 44).

Alternative analytics solutions also use GET variables for campaign tracking (for example Piwik/Matomo: pk_campaign, pk_kwd, pk_source, pk_medium, pk_content). Currently, using these tags inevitably bypasses the cache, as would for instance using the remaining two GA parameters utm_term or utm_content, neither currently included in the exclusion rule. Other analytics software may use additional ones, also some social sharing services or newsletter platforms attach such tags by default.

For advanced users of (alternative) analytics solutions, it would be very useful to be able to freely define rules for "ignored GET variables" on the Cache Enabler settings page, similar to the existing RegExp fields for "excluded pages" and "matching cookies".

When any post type is published and a static home page is defined the posts page should also be able to be cleared (if defined). The post ID for the posts page can be obtained with get_option( 'page_for_posts' ) (the value returned will be 0 if undefined).

When updating a post there should be more control over what should be cleared, like the home page, posts page (if applicable), etc. This was considered in PR #88 when changing the default publishing action and it turns out it would be a good enhancement. This same functionality should be added to Gutenberg as it currently is in the Classic Editor.

WordPress topics:

• https://wordpress.org/support/topic/updating-a-post-does-not-clear-homepage-cache/
• https://wordpress.org/support/topic/updating-through-the-api-will-not-clear-page-cache/

Update how the wp-config.php file is found. Use same method that WordPress uses in wp-load.php. This will avoid not finding the wp-config.php file if it's been moved when hardening WordPress and is not part of another installation (e.g. nested installation). Depending on the environment, file permissions may interfere even if the wp-config.php file is found one directory level above the WordPress installation.

WordPress topic: https://wordpress.org/support/topic/set-wp_cache-does-not-find-wp-config-php-in-some-cases/

/^utm_(source|medium|campaign|term|content)$/

Default if unset: /^utm_(source|medium|campaign|term|content)$/

On my local test Wordpress install I installed Cache Enabler and updated to 1.4.6 but I see from #94 the cache filed is now scheme based. However, if I setup a non-https wordpress site i.e. http://cache-enabler.domain.com the Cache Enabler still generates a https-index.html instead of http-index.html file ?

ls -lah /home/nginx/domains/cache-enabler.domain.com/public/wp-content/cache/cache-enabler/cache-enabler.domain.com/
total 40K
drwxrws--- 2 nginx nginx 4.0K Aug 27 03:02 .
drwxrws--- 3 nginx nginx 4.0K Aug 27 03:02 ..
-rw-rw---- 1 nginx nginx  24K Aug 27 03:02 https-index.html
-rw-rw---- 1 nginx nginx 6.6K Aug 27 03:02 https-index.html.gz

curl -s "http://cache-enabler.domain.com" | tail -2                                                                 

<!-- Cache Enabler by KeyCDN @ 27.08.2020 03:02:03 (https html) -->

from wp-cli

WP-CLI 2.4.0
WP-Home    http://cache-enabler.domain.com
WP-SiteURL http://cache-enabler.domain.com
WordPress  version:   5.5
Database   revision:  48748

+--------------------+----------+--------+---------+
| name               | status   | update | version |
+--------------------+----------+--------+---------+
| akismet            | inactive | none   | 4.1.6   |
| autoptimize        | active   | none   | 2.7.7   |
| autoptimize-gzip   | active   | none   | 0.1     |
| cache-enabler      | active   | none   | 1.4.6   |
| cdn-enabler        | inactive | none   | 1.0.9   |
| classic-editor     | active   | none   | 1.6     |
| disable-xml-rpc    | active   | none   | 1.0.1   |
| pretty-search-url  | active   | none   | 0.1     |
| sucuri-scanner     | active   | none   | 1.8.24  |
| webp-express       | active   | none   | 0.17.5  |
| advanced-cache.php | dropin   | none   |         |
+--------------------+----------+--------+---------+

I setup my Nginx advanced cache rules to use $scheme nginx variable to prefix index.html with either https- or http- but this wouldn't work if Cache Enabler is generating https- prefix even for non-https setup Wordpress site !

    # default html file
    set $cache_enabler_uri '${custom_subdir}/wp-content/cache/cache-enabler/${http_host}${cache_uri}${scheme}-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}${scheme}-index-webp.html';
    }

PHP 7.3.21

php -v
PHP 7.3.21 (cli) (built: Aug 12 2020 22:45:53) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.21, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.21, Copyright (c) 1999-2018, by Zend Technologies

phpinfo variables report

$_SERVER['SERVER_NAME'] | cache-enabler.domain.com
$_SERVER['SERVER_PORT'] | 80
$_SERVER['REQUEST_SCHEME'] | http
$_SERVER['HTTPS'] | off

Maybe instead of using port 443/80 to determine if https or https prefix is set, use $_SERVER['REQUEST_SCHEME'] and/or $_SERVER['HTTPS'] ? This would also allow non-standard ports to map correctly i.e. HTTP site on port 8080 or HTTPS site on port 8443 would be properly detected too. edit: looks like you did that in beac15d

and verified my copy has that

grep -n 'HTTPS' /home/nginx/domains/cache-enabler.domain.com/public/wp-content/plugins/cache-enabler/inc/cache_enabler_disk.class.php

470:        return ( ( isset( $_SERVER['HTTPS'] ) && ! empty( $_SERVER['HTTPS'] ) ) || $_SERVER['SERVER_PORT'] === '443' ) ? 'https' : 'http';

however, my phpinfo reports $_SERVER['HTTPS'] | off so for non-https site the variable isn't empty but = off so maybe that falsely matches your check ?

so maybe

        return ( ( isset( $_SERVER['HTTPS'] ) &&  $_SERVER['HTTPS'] !== 'off' ) || $_SERVER['SERVER_PORT'] === '443' ) ? 'https' : 'http';

which seems to work

curl -s "http://cache-enabler.domain.com" | tail -2                             
<!-- Cache Enabler by KeyCDN @ 27.08.2020 04:41:34 (http html) -->

ls -lah /home/nginx/domains/cache-enabler.domain.com/public/wp-content/cache/cache-enabler/cache-enabler.domain.com/
total 40K
drwxrws--- 2 nginx nginx 4.0K Aug 27 04:41 .
drwxrws--- 3 nginx nginx 4.0K Aug 27 04:41 ..
-rw-rw---- 1 nginx nginx  24K Aug 27 04:41 http-index.html
-rw-rw---- 1 nginx nginx 6.6K Aug 27 04:41 http-index.html.gz

I checked on Apache PHP server $_SERVER['HTTPS'] is empty none existent on non-https requests but on Nginx with PHP-FPM $_SERVER['HTTPS'] is set to off for non-https requests

On Nginx/PHP-FPM https request shows $_SERVER['HTTPS'] | on

the browser request that generated the cached file

Currently, after a stock change in woocommerce, the full cache is cleared. For a busy online shop, this basically disables caching, since the cache is already cleared again before it could be (fully) rebuild.

The obvious solution is to only clear the product that actually changed. RedCastor/cache-enabler has working code that does this.

see also:
https://wordpress.org/support/topic/cache-gets-cleared-every-time-a-stock-change-happens-at-woocommerce/

$ cat wp-content/cache/cache-enabler/x.com/index.html | grep .png

<div class="site-logo faux-heading">
	<a href="https://x.com/" class="custom-logo-link" rel="home">
		<img width="1198" height="214" src="https://x.com/wp-content/uploads/2020/04/cropped-x-1.png.webp" class="custom-logo" alt="X" srcset="https://x.com/wp-content/uploads/2020/04/cropped-x-1.png.webp 1198w, https://x.com/wp-content/uploads/2020/04/cropped-x-1-300x54.png.webp 300w, https://x.com/wp-content/uploads/2020/04/cropped-x-1-1024x183.png.webp 1024w, https://x.com/wp-content/uploads/2020/04/cropped-x-1-768x137.png.webp 768w" sizes="(max-width: 1198px) 100vw, 1198px" />
	</a>
	<span class="screen-reader-text">X</span>
</div>

$ cat wp-content/cache/cache-enabler/x.com/index-webp.html | grep .png

<div class="site-logo faux-heading">
	<a href="https://x.com/" class="custom-logo-link" rel="home">
		<img width="1198" height="214" src="https://x.com/wp-content/uploads/2020/04/cropped-x-1.png.webp" class="custom-logo" alt="X" srcset="https://x.com/wp-content/uploads/2020/04/cropped-x-1.png.webp 1198w, https://x.com/wp-content/uploads/2020/04/cropped-x-1-300x54.png.webp 300w, https://x.com/wp-content/uploads/2020/04/cropped-x-1-1024x183.png.webp 1024w, https://x.com/wp-content/uploads/2020/04/cropped-x-1-768x137.png.webp 768w" sizes="(max-width: 1198px) 100vw, 1198px" />
	</a>
	<span class="screen-reader-text">X</span>
</div>

They're both the same. Doesn't always happen, but most of the time it does.

WP Rocket has caching for logged in users as a feature. Was wondering if it's a planned feature in Cache Enabler's road map ?

The issue has been for the first time observed about 7 months ago. At that time our development team created a ticket on the WordPress support for the plugin Cache Enabler.

The support ticket was marked as resolved by Corey with the following message:

Since 1.3.0 the Cache Enabler cache is completely cleared on stock updates.

Since our store manages thousands of products with constant changes in stock, there is a high probability that behind the concept of clearing the whole cache on every stock change, the cache becomes practically non-existent or volatile, making thus the plugin cache enabler in such cases useless.

In order to work around this problem, we have developed a fix which makes cache enabler clear only the cache of the product the stock of which has been changed. Please see attached image of the changes.

This fix has nevertheless been compromised since the latest version (3.0.0.2) of the WP plugin WooCommerce AJAX Products Filter has been released. This produces somehow an incompatibility with cache enabler (Version 1.3.5) which prevents it from generating cached pages.

In order to prove that, we have downgraded WooCommerce AJAX Products Filter to a previous version (2.4.2.3). As a consequence, cache enabler has started to work again.

This seems to point out that the process of cache clearing is being interfered by this plugin or some of its addons.

Hey, I love the plugin, great job. The only issue I've found is that you can only set a cache time every hour instead of being able to set a cache time in minutes.

I think minutes are a better system or accepting fractional hours. We're looking for a caching system to help with load spikes, not necessarily to cache for long periods of time.

It would actually be awesome to have a cache system based on throughput. So start caching as throughput starts to get to > 1 s for example, else do not cache.

Maybe starting with accepting minutes is best tho? Or fractional hours?

Translation of Cache Enabler plugin is loaded only in admin area. In website area, Cache Enabler's menu items inside WordPress top bar are not translated.

https://i.imgur.com/VgDtxel.png