Replies: 0
Our site http://www.drivemag.it has an issue when the plugin W3TC ( version 0.9.5.2 ) tries to get the cached page using memcached.
The website is:
http://www.drivemag.it
and its Amazon hostname is:
motors-main-bxkh6he-1784382071.eu-west-1.elb.amazonaws.com
The DNS of http://www.drivemag.it is a CNAME Record configured as follow:
http://www.drivemag.it CNAME motors-main-bxkh6he-1784382071.eu-west-1.elb.amazonaws.com
W3Total Cache is configured to use the Memcached node:
sca-ca-1hxmrl8x06qkb.5nbtmd.cfg.euw1.cache.amazonaws.com:11211
and in the “Page Cache” the Aliases are set to:
http://motors-main-bxkh6he-1784382071.eu-west-1.elb.amazonaws.com
http://www.drivemag.it
We experiencing a problem when W3TC try to get the cached page from the memcached server.
Viewing the comment at the bottom of the source page (home or internal page) seems that the page was correctly cached in memcached:
<!– Performance optimized by W3 Total Cache. Learn more: https://www.w3-edge.com/products/
Page Caching using memcache
Content Delivery Network via d2uo6qposukubl.cloudfront.net
Database Caching 52/479 queries in 0.280 seconds using memcache
Served from: http://www.drivemag.it @ 2017-03-10 12:02:02 by W3 Total Cache –>
Analysing the Graph of the memcached in Amazon Dashboard we saw that the items are growing up, there are new connection to the server so we assuming that the writing into the memcached server is ok.
The issue appears when we reload the page just cached because the W3 Total Cache cannot find the cache version on memcached so it create again the cache and reload all the generation of the php with a slow time than the cached content.
We verify that all the other features of W3TC are correctly working (CDN, Browser Cache, etc) and only the Page Cache feature is not working.
We have tried to debug adding some logging to the code and we see the following warning:
Warning: preg_match(): Compilation failed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 11 in /var/www/html/wp-content/plugins/w3-total-cache/PgCache_ContentGrabber.php on line 759
This function is supposed to verify if the url of the requested page is among those to be excluded from caching (as set by the admin in the WP backend).
This is the code snippet which is generating the error preventing page caching from working on the given url:
$reject_uri = $this->_config->get_array( ‘pgcache.reject.uri’ );
$reject_uri = array_map( array( ‘\W3TC\Util_Environment’, ‘parse_path’ ), $reject_uri );
foreach ( $reject_uri as $expr ) {
$expr = trim( $expr );
if ( $expr != ” && preg_match( ‘~’ . $expr . ‘~i’, $this->_request_uri ) ) {
return false;
}
The line with the call to preg_match was generating an errore and page caching was not used. We tried to bypass this error and then page caching works!
With further debug we discovered that the problem is caused by the “$this->_request_uri” format which in some cases is not a normal string, but is appears as ASCII compressed code.
What can we do?
We cannot keep in production a “hacked” version of W3TC, but without our hack page caching does not work in a good % of cases (let’s say around 20% of page calls does not hit the cache if we do not modify the W3TC code)…
