hughforsyth

Just to add another voice, I also have this issue.

Searching by “containing words”, “log level”, and “message type” all seem to work okay but “Users” is ignored. It is also ignore if used with one of the other criteria.

It’s looking up the user okay and from looking in developer tools it is passing the user ID in a request but it seems that the server code is ignoring the “users” parameter.

Hi @nigrosimone,

As an FYI, I tried this with gclid and it’s definitely in the right ball park. One thing I have noticed is that for me a gclid URL will not populate the W3TC cache, only a “naked” URL will populate the cache.

This means that if most of the hits on a page have a gclid, e.g., you’ve created a landing page just for Adwords, then they will still likely not be cached unless you can prime it regularly with the “naked” URL.

e.g., if I have the following then the first “naked” URL will create a W3TC cache file that will be used by the 3 gclid URLs.
http://example.com/banana/
http://example.com/banana/?gclid=apple
http://example.com/banana/?gclid=plum
http://example.com/banana/?gclid=pear

If I just did the following then all 3 would miss as none will not populate the cache for the next requests.
http://example.com/banana/?gclid=apple
http://example.com/banana/?gclid=plum
http://example.com/banana/?gclid=pear

Unless I’ve missed something, I think for this to work reliably it needs to be built into core plugin code, i.e., as well as ignoring the gclid parameter when comparing requests to cache files, also ignore it when writing out cache file, e.g., if I request http://example.com/banana/?gclid=apple then cache that as “wp-content/cache/page_enhanced/example.com/banana/_index.html” in the file system.

FWIW,
– wp-rocket (paid) claims to ignore gclid when comparing requests with cached content so that’s perhaps an option (listed in V2.55 https://wp-rocket.me/changelog/)
– Comet Cache also has this on the road map (https://ww.wp.xz.cn/support/topic/ga-analytics-linkid-js/#post-8260363). I’m hoping that will be available in the free version when they get around to it.
– There might be a patch/hack for wp-supercache to do this too although the link is 4 years old so perhaps not. https://ww.wp.xz.cn/support/topic/plugin-wp-super-cache-google-adwords-gclid-parameter-conflicting-with-caching/

It may be that if you do a lot of adwords or tracking W3TC is not the best fit. I’m reluctantly coming to that conclusion. 8/10 of my (human) requests for pages come from Adwords so W3TC is likely only caching 2/10 pages. I assume it does much better with requests from search engines and so on but still. It may be more of an overhead than a benefit for me.

Thanks
Hugh

Hi Kimberly,

I’m not Tim but I’ve found that the “Expires header lifetime” value is [probably] honoured with “disk: enhanced” mode but is ignored with “disk: basic” mode.

I was using basic and noted that ‘public_html/wp-content/cache/page” rarely contained a file/directory more than and hour or 2 old and regularly cleaned itself out. I guess that would make sense if it was using a “stealth” setting of 3600s from pgcache.lifetime.

I switched to “disk enhanced” and “public_html/wp-content/cache/page_enhanced” had files 6 hours old before I switched back to basic (which I did to cache URLs with query strings). So that did seem to be honouring the 24 hour TTL.

Selected values from my config export:
“pgcache.enabled”: “1”,
“pgcache.comment_cookie_ttl”: “1800”,
“pgcache.engine”: “file”,
“pgcache.file.gc”: “3600”,
“pgcache.lifetime”: 3600,
“browsercache.html.lifetime”: “86400”,

I might try the “editing exported config file” workaround but it’s unfortunate that it seems to be inconsistent with cache TTLs dependent on method, and the on screen documentation is inaccurate.

For now I’ve just set GC to 24 hours.

Thanks.