• revert NewRelic support
• https://github.com/wimg/PHPCompatibility

It’s super nice to have contributions from someone else but it’s hard to see if those changes break existing features. We all do mistakes from time to time and it’s easier to recover if you have good test coverage. Automated integration tests can help you out in these situations.

Is someone available in writing unit tests and integration with Trevis?

I'm coming here from an issue posted to GitHub Updater, afragen/git-updater#460

If this fork would simply use GitHub Updater for updates and not delete or rename any repositories when installing I think your issues with updates, #115 #131 would go away. Updates would come from this plugin and not the main file.

@nigrosimone All of the todos are one-liners (OK, not 1 but maybe 5) except the OPcache compatibility which needs some research.

Have you met these problems?

You are free to send PR-s!

After having 0.9.5 crash my site, the new update is chock full of bugs, I decided to upload this GitHub fix version instead.

Everything seems fine, except I keep getting the alert to fix:

Edit file /usr/home/trailera/public_html/nginx.conf and replace all lines between and including # BEGIN W3TC Minify cache and # END W3TC Minify cache markers with:

I did the code exactly as it wanted, restarted nginx, and it still has the error. So not sure if the error just doesn't know to go away on this GitHub version (it doesn't exist on the 0.9.4 base), but want to make sure Minify is cacheing properly.

I can't just keep deleting and adding the same code, so hoping this is a common issue.

Cheers
Ryan

Version 0.9.4.5.4 throughs server error 500 when Page Cache is enabled. I'm using PHP7.

My server error log shows:

• PHP Parse error: syntax error, unexpected ‘<‘, expecting end of file in /home/mydomain.com/fghgh/public_html/wp-content/plugins/w3-total-cachelib/W3/PgCache.php(1511) : eval()'d code on line 1
• PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0

I also have the same error when using the latest official v0.9.5, the error log is then:

• PHP Parse error: syntax error, unexpected ‘<‘, expecting end of file in /home/mydomain.com/fghgh/public_html/wp-content/plugins/w3-total-cache/PgCache_ContentGrabber.php(1460) : eval()’d code on line 1
• PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0

Any idea what goes wrong?

Via https://secupress.me/4-new-security-flaws-w3-total-cache-0-9-4-1/

This is somehow related to #31

The symptoms are the same, and the culprit is in how flush() increments the key_version.

I found the following threads describing the same issue:

• https://wordpress.org/support/topic/self-diagnosed-and-fixed-w3-total-cache-bug-in-faulty-object-caching
• https://wordpress.org/support/topic/suggested-changes-to-object-caching-and-transients
• https://wordpress.org/support/topic/bug-in-apc-object-cache-wp_cache_set-making-it-fail

I see two possible ways for fixing this behavior:

1. pass the right $group value from ObjectCache.php, and then figure out a way to increment the key_version for each $group when the flush() function is called
2. Change the default $group value in the Cache folder from $group = '0' to $group = '' . Then all cache groups will be checking the key_version against the same key (i.e.: all $groups will be flushed at the same time and there would be no way for flushing just a single group, a functionality that doesn't seem to be implemented anyway)

The 2nd option seems the easiest way to go, as it appears that object cache groups are currently poorly implemented in W3TC. This was also the fix that Frederick Townes suggested in one of the above threads.

Thoughts?

Just released: https://wptavern.com/high-risk-xss-vulnerability-discovered-in-w3-total-cache-plugin

mysqli_num_fields() expects parameter 1 to be mysqli_result, boolean given in /wp-includes/wp-db.php on line 3013

it seems to have occurred right after upgrading to WordPress 4.5.

If you turn W3TC db caching off, the problem disappears, but no more caching.

This issue is to related to something that came up in #41 (comment)

What I think is happening is the following:

• When an HTTPS page is cached, the cache's $key contains "_ssl" in the end.
• When a flush is issued from the backend for a single page, the _flush_url() function in PgCacheFlush.php does not execute a flush for keys ending with "_ssl".

The culprit is in:

    function _get_encryptions() {
        $encryptions = array(false);
        if ($this->_config->get_boolean('pgcache.cache.ssl')) {
            $encryptions[] = 'ssl';
        }
        return $encryptions;
    }

So, the SSL cache is always created, but never flushed unless "pgcache.cache.ssl" key is set to true (i.e.: "Cache SSL (https) requests" in Performance => Page Cache)

This seems a bit redundant, so we should either enforce the above option and not create a cache entry for SSL pages if this is disabled, OR deprecate this option and always have SSL pages follow the default caching behavior.

from README.md:

Fix

• Halfdone CloudFlare support in trunk

@szepeviktor, it's a last issue to fix, but what does mean?

Hello. I noticed that there is something wrong with page cache exception rules. My website uses ssl. By default the option to cache https requests is disabled, so nothing gets cached. When I enable that option - almost everything gets cached, regardless of exceptions. For example, wp-login.php cached, pages with query strings - cached, even though the option to cache them is disabled. Only logged in users don't get cached. Defining DONOTPAGECACHE constant works, which is what I'm going to use, it is more flexible than regex matching rules anyway. Just wanted to report this issue.

Issue with 0.9.5

From admin bar Performance > Page Modules > Page cache: current page don't work for me, not flush the current page cache.

I have a multisite installation path based with different site on some path, eg.:

http://yoursite.com/
http://yoursite.com/it/
http://yoursite.com/fr/

If i try to flush a page (not post) from admin bar Performance > Page Modules > Page cache: current page, eg.:

http://yoursite.com/fr/mypage/

delete() on Cache_File_Generic.php try to delete:

/wp-content/cache/page_enhanced/yoursite.com/_index.html
/wp-content/cache/page_enhanced/yoursite.com/_index.html_gzip
/wp-content/cache/page_enhanced/yoursite.com/wp-admin/network/admin.php/_index.htm
/wp-content/cache/page_enhanced/yoursite.com/wp-admin/network/admin.php/_index.html_gzip
/wp-content/cache/page_enhanced/yoursite.com/feed/_index.html
/wp-content/cache/page_enhanced/yoursite.com/feed/_index.html_gzip

the right file to delete:

/wp-content/cache/page_enhanced/yoursite.com/fr/mypage/_index.html
/wp-content/cache/page_enhanced/yoursite.com/fr/mypage/_index.html_gzip

are not in the list and the list has some mistakes:

/wp-content/cache/page_enhanced/yoursite.com/wp-admin/network/admin.php/_index.htm
/wp-content/cache/page_enhanced/yoursite.com/wp-admin/network/admin.php/_index.html_gzip

this make me crazy, w3tc seems to not have implemented the code for flush "page", i don't found it!

Howdy,

When upgrading sites that from 0.9.4.1 to today's pull, I encountered an error when compatibility mode was enabled. Our environment works fine with it off, so I have a work around.

I can replicate this on multiple sites and servers. The error looks like this:

[Tue Aug 30 18:15:28 2016] [crit] [client 24.56.43.116] configuration error: couldn't perform authentication. AuthType not set!: /wp-content/cache/page_enhanced/www.clientsite.com//category/faith//_index.html_gzip, referer: http://www.clientsite.com/

The pair of //'s in the path seem to be the culprit.

Sorry that I suck at coding or I'd be more useful and contribute fixes. I'm happy to test the latest code on some busy sites I manage & write up interesting things I find.

-J

Hi,

Search in my site doesn't work when I use fix-w3tc.

Either with no cache plugin or the original W3TC, it works.

Can someone look into it?

Hey all,

Thanks for cleaning up and fixing W3TC. I appreciate all your work on this!

I'm seeing this warning:

PHP message: PHP Warning: Invalid argument supplied for foreach() in /home/www/sitename.com/htdocs/wp-content/plugins/w3-total-cache/lib/W3/ConfigCompatibility.php on line 207, referer: http://www.sitename.com/wp-admin/

This is on a fresh pull ( e2ae84e).

Thanks!

Edited to add: PHP 7.0.6

User bhamrick from the W3TC support forum on wordpress.org reported the following bug:

I’m trying to use the plugin Woocommerce CSV importer which enforces permissions by relying on the roles array on the $current_user object, as many other plugins do. W3 Total Cache is removing my ‘administrator’ role so $current_user->roles becomes an empty array. There are no actual DB changes, it just changes the value at runtime.

This looks to be an old bug, there’s a thread about the same issue from a year ago:
https://wordpress.org/support/topic/bug-w3tc-breaks-plugins-that-need-the-current-users-role/

I looked into it, and seems the bug has been there for more than a year.

The problem is with accessing the global variable $current_user and changing its fields when using array_shift.

A simple fix would be to replace array_shift() with reset() as mentioned in the linked thread above.

Taking it a step further, perhaps we should stop using the global variables altogether and get the $current_user by using:

$current_user = wp_get_current_user();

Is there any argument for using the global variable instead of calling the function? Maybe an overhead cost in execution time?

I got this always. I tried to remove the plugin, remove that file and re-install again. But till got the same issue.

FIX-W3TC Guys! I have read this post about "Wordpress Adoption Program for Abandoned Plugins" that i found interesting.

We could try to adopt W3TC?

It seems this fixed version wants to get updates from the old (Townes) version, when that one is updated. Instead, getting new versions from Github would be great. At least disable the updates from the Townes (non-fixed) version.

Followed the install instructions several times.

Tried restarting both nginx and php7 as well.

Each time the plug-in fails to register - If I reload the plugins list, it's not listed. If I just try to reactivate, I get the plugin file not found error.

W3TC merges all css in one file, but IE 9 handle only 4095 CSS rules per file.

IE 11 console show this error:

There are 4940 CSS rules in the stylesheet e0264.css - IE will ignore the last 844 rules!

Referring the following from Microsoft:

• Stylesheet Limits in Internet Explorer
• KB - A webpage that uses CSS styles does not render correctly in Internet Explorer

The rules for IE9 is: A sheet may contain up to 4095 selectors!

If you are using the CSS/JS minification its injected onto AMP pages there is a fix here:

https://wordpress.org/support/topic/disable-on-amp-pages?replies=23

We can do this or exclude the entire page automatically by default under the
Never minify the following pages and set the default to /amp/ either or looking at both solutions.

And look at that change log ...Lots of fixes

Just curious...

I noticed the Dashboard's Buy Now Premium Service Widget (see 1st attached image) and the General Setting's Licensing widget (see 2nd attached image) are still showing.

Is there any reason for that?

Is it ok for me to remove them?

For reference, there respective code locations are here and here.

Because w3tc seems to have abandoned this plugin i fear if someone were using our fork that these two visible widgets would make user's mistakenly think a paid premium service is still offered by them only to find out in a very ugly way (after paying) that no such service exists and the protracted hassle of getting a credit card transaction reversal would have to begin.

Note: Their removals are part of PR #61

Dashboard: Premium Services Buy Now

General Settings: Licensing

Hello,

I've been working with w3tc-fix on my local development environment and was having issues getting the cache to purge properly on when I would edit a post.

After a bit of debugging in /lib/W3/PgCache.php it appears that there was a mismatch between the $key and where the actual cache file was being saved due to my setup having a port number:

$key: localhost:8888/contact/_index.html
Actual location: localhost/contact/_index.html

So I made a few little edits to remove the port number and was able to get it working:

if ($request_uri){
     $is_ssl_request = ( strtolower(substr($request_uri, 0, 8)) == 'https://' );
     // $key = substr( $request_uri, $is_ssl_request ? 8 : 7 );

     // my additions begin
     $test_host = parse_url($request_uri, PHP_URL_HOST); 
     $test_path = parse_url($request_uri, PHP_URL_PATH);
     $test_key = $test_host . $test_path;
     $key = $test_key;
     // my additions end

} else {
     $key = $this->_request_host . $this->_request_uri;
}

Not sure if this would qualify as something worth submitting as it could somewhat of an edge case solution to my specific setup, but it seemed like it might be worth pointing out. Perhaps there is a more general purpose way to ensure the $key actually matches where the cache files are being saved.

Edit: and I know my code is not the best way of fixing this, but more of a little hacky thing to show the concept :)

Thank you,

Hello guys. I didn't entirely review your code changes but I'm just wondering if you have integrated useful hooks like the ones by w3tc-auto-pilot, or do I still need that other plugin to help yours to be in autopilot?

Thanks in advance!

This is related to something we've previously fixed in #32

In PgCache.php, there's the following lines:

        $group = '';
        if (!isset($this->_sitemap_matched)) {
            $sitemap_regex = $this->_config->get_string('pgcache.purge.sitemap_regex');
            if ($sitemap_regex && preg_match('/' . $sitemap_regex . '/', basename($this->_request_uri))) {
                $group = 'sitemaps';
                $this->_sitemap_matched = true;
            }
        } elseif ($this->_sitemap_matched)
            $group = 'sitemaps';

When using a caching method like Memcached or Redis, there's a case where $group may be equal to 'sitemaps', as per the above.

When this happens, a key is created in the caching engine, with the group sitemaps. However, when flush() is called in PgCacheFlush.php, no $group parameter is passed, which defaults to incrementing the key_version for only the default group (empty string), and the key with the 'sitemaps' group is not incremented.

This leads to problems with flushing a website's sitemap.

Wordpress enqueues wp-emoji-release.min.js via inline feature detection.

So suppose my website is on the subdomain www.example.com and the CDN cname is cloud.example.com

The file path in browser should be http://cloud.example.com/wp-includes/js/wp-emoji-release.min.js?ver=4.6.1

But that is not the case.

It's probably because the URLs are JSONencoded in the inline JS in the HTML.

Please list our implemented features not in v0.9.5

And maybe 0.9.5 bugs.

Was: #57

@szepeviktor, this is a good start, but this is an hard work for two person. W3 Total Cache is a jungle. Please, try to contact each person seem interested in W3 total cache keep alive. On github more people have fork w3tc (try to contact):

https://github.com/search?q=w3+total+cache

on W3tc support forum more developers seem work on patch, eg.:

https://wordpress.org/support/topic/w3tc-with-php-7-and-apcu-512

Is anyone notice that the page enchanced is not working properly (or maybe just me)

set $w3tc_ext "";
if (-f "$document_root/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_ua$w3tc_rewrite.html") {
    set $w3tc_ext .html;
}
if (-f "$document_root/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_ua$w3tc_rewrite.xml") {
    set $w3tc_ext .xml;
}
if ($w3tc_ext = "") {
  set $w3tc_rewrite 0;
}
if ($w3tc_rewrite = 1) {
    rewrite .* "/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_ua$w3tc_rewrite$w3tc_ext" last;
}

the $w3tc_rewrite will have a value of 1 if rewrite should be performed (page exist in cache)
so by having $w3tc_rewrite in try files and rewrite section, the script will always fail.. because the file name don't have 1 on it .. .

for example for index page it is writen as _index.html where the nginx script try to find _index1.html

Hi guys,
I noticed APCu support.
Can anyone give any background to this, and what the consequences of using it are?

Is it a safe drop-in to use everywhere I would have used APC in w3tc? (I know enough to know it's different in that it doesn't have an opcode cache itself, but I don't know enought to know the consequences.)

Thanks.

I noticed the changelog.txt was both out of date and didn't may not appear to be updated with the Fix W3TC information. In fact, the changelog was talking about 0.9.3.

Just something minor.

for peoples which don't want to switch to the original version.

Hi guys! Just a quesiton...

I was roaming master's ConfigKeys.php and noticed that mfunc is no longer listed. In 0.9.4.4-ConfigKeys.php mfunc was listed under the minify.html.comments.ignore array. There doesn't seem to be an explanation for its removal. Just wondering if that is a mistake or if it was done intentionally.

Thanks for the info
Kimberly

Hello, I have a problem with #50.

( ! ) Fatal error: Uncaught Error: Call to undefined function apply_filters() in C:\myproject\wp-content\plugins\w3-total-cache\lib\W3\PgCache.php on line 152
( ! ) Error: Call to undefined function apply_filters() in C:\myproject\wp-content\plugins\w3-total-cache\lib\W3\PgCache.php on line 152
Call Stack
#   Time    Memory  Function    Location
1   0.2007  386864  {main}( )   ...\index.php:0
2   0.2017  434288  require_once( 'C:\myproject\wp-admin\admin.php' )   ...\index.php:10
3   0.2025  448320  require_once( 'C:\myproject\wp-load.php' )  ...\admin.php:31
4   0.2029  477064  require_once( 'C:\myproject\wp-config.php' )    ...\wp-load.php:37
5   0.2036  551784  require_once( 'C:\myproject\wp-settings.php' )  ...\wp-config.php:176
6   0.2080  719672  include( 'C:\myproject\wp-content\advanced-cache.php' ) ...\wp-settings.php:74
7   0.2270  1542184 w3_instance( )  ...\advanced-cache.php:33
8   0.2287  1805152 W3_PgCache->__construct( )  ...\define.php:1471

apply_filters is defined in plugin.php, but no plugin.php in this context.

Hello,

I have noticed that the database cache was not being properly flushed if the cache method is anything other than disk (I tested it with memcached and redis).

The problem is with how flush_cache() is defined in DbCache.php
flush_cache() calls the flush() command defined in the cache engine.
For a disk-based cache, this results in the following line being executed:

        $flush_dir = $group ? $this->_cache_dir . DIRECTORY_SEPARATOR . $group . DIRECTORY_SEPARATOR : $this->_flush_dir;

since the flush() command was executed with no argument (ie: $group = ''), the $flush_dir defaults to the entire DB cache directory, which is properly deleted.

In memcached or redis, the flush() function actually increments the key_version for the different groups, but since the $group defaults to 0, the wrong key_version is being selected and incremented.

As a possible fix, we can change the flush_cache() function in DbCache.php to:

    function flush_cache() {
        $this->_flush_cache_group('all');
        return true;
    }

This will then loop through the different groups and clear each one of them.
This change can be found in here: charlesLF@b9e38ee

What are your thoughts on this one?

Did anyone saw this

• https://wpvulndb.com/vulnerabilities/8625

It was just published,

After deletion a plugin/theme, w3tc going in error:

Recently an error occurred while creating the CSS / JS minify cache: File "XXX" doesn't exist.

where XXX is the path of an assets of old plugin/theme.

the error persists after flushing all cache (object, db, minify, page).

I've seen a few old thread about this but no solution. In on thread Frederick said it would be fixed in a future version. That was a year ago, and obviously it's not fixed.

Code suggestion if you want to prevent updating to W3 Total Cache plugin.

//* Disable plugin updates
add_filter('site_transient_update_plugins', 'disable_w3tc_plugin_updates');
function disable_w3tc_plugin_updates( $value ) {
    if( $value ) {
        unset( $value->response['w3-total-cache/w3-total-cache.php'] );
    }
    return $value;
}

I am seeing an issue with priming cache. But it's both in the original W3TC and fix-w3tc.

Earlier, with say, the default setting of priming 10 pages every 900 seconds, I used to see two primining jobs in cron. I use the plugin Crontrol to see cron events. One of these had "arguments" like [10], [20], [30] and so on after each interval of 900 seconds. But now the priming is not happening in both the W3TC and fix-w3tc.

Anyone has an idea on how to solve this?

Hello. I think I've found another bug with caching exceptions. When the option to cache url with query strings is disabled, everything is ok. URLs without query strings are cached, ones with query strings are not:

Page without query:
Caching:            enabled
Status:             cached

Page with query:
Caching:            disabled
Reject reason:      Requested URI contains query
Status:             not cached

However, with the option to cache urls with query strings enabled, the results are:

Page without query:
Caching:            enabled
Status:             not cached

Page with query:
Caching:            enabled
Status:             cached

Note that caching is enabled, but status is not cached, which is strange. I don't know if it is just a debug error - pages are loading fast even when status is not cached and they seem to get cached. But I'm not sure if everything is ok.

By the way, in the second case, "page with query" is not just any page with a query. The query must have an effect on rendered content. But in the first case, any query will do to be treated as a page with query and be rejected from caching.

Hello @ftownes !

I hope you don't mind if I publicly fix & customize your plugin.
https://github.com/szepeviktor/fix-w3tc/blob/master/README.md

Please comment.

All the best!

As per this article: https://make.wordpress.org/core/2016/09/08/wp_hook-next-generation-actions-and-filters/ , the next WP version (4.7) will introduce changes to the $wp_filter global variable.

W3TC accesses this variable in 2 places in inc/functions/plugin.php:

$wp_filter[$hook] = array();

These seem to be (by default) only used in Genesis.php, but could be used by other developers.

I have never made use of this feature in W3TC, so I am not quite familiar with it, but we could either replace the above line with something like:

if(is_object( $wp_filter[$hook])) 
 $wp_filter[$hook]->callbacks = array();
else 
$wp_filter[$hook] = array();

or stick to WP standard functions and use remove_all_filters

I would prefer sticking to standard WP functions, even if there's a small execution overhead in doing so, but at least there's less chance of breaking things.

Hi !
Is there any guide to set the redis config parameter ? for example server ip, port, auth, etc ?

Since I am not sure if the developers get notifications to closed issues, I am reopening #11 here.

I am still getting AMP errors.

A demo is here

When you hover Performance in the Admin menu bar, there's a link to Support. That support page is a dead page that only says "Sorry, you are not allowed to access this page."

I believe that menu item should either be removed, or replaced with information leading to this repository and other useful information.

If you are using the premium version of the plugin users will have the mfunc minified when using the HTML compressor this needs to be added by default in order to prevent user's fragment caching from not working.

Needs to be added to the Ignored comment stems

Looking for a solution now.