laurionb

Perhaps Object Cache could take in account the absolute path of the WP install?

I had the same problem and ended up doing that. It took a small change to W3TC 9.2.4 to make it work for me.

https://technology.bernews.com/w3tc-caching-and-multiple-wordpress-installations/

Are you using “disk enhanced” as a page cache? If so then cached pages are served without talking to wordpress. If you switch to disk, APC or memcached then your stats should work, but your site will be slightly slower. Alternatively you could just use Google analytics.

It looks like you have just one WordPress installation, but with multiple blogs. The way that W3TC works it can’t differentiate between the different cached pages for those blogs. The hack that I linked to won’t work because it relies on having different wordpress installations.

That isn’t the right place to make the change.

First I want to make sure this might help. A few questions:
– Do you have a wordpress multisite installation, or did you just install multiple wordpress blogs on the same machine?
– What type of caching are you using (memcached, APC, disk, disk enhanced)?

I had a similar issue when I put multiple WordPress installations on the same server (not multisite — just multiple installations on the same server). The problem was that the APC/memcached cache was shared between the installations so they would retrieve each other’s cached objects. I’m wondering if something like that could be affecting you.

I fixed the problem by modifying the code to make the cache key unique:

https://technology.bernews.com/w3tc-caching-and-multiple-wordpress-installations/

I guess my request not actually purge the cache unless a comment gets published, as opposed to just “received”.

I encountered this problem a while ago and hacked W3TC to work around that:

https://technology.bernews.com/w3tc-page-cache-and-spam-comments/

An easy way to change the directory is to create a link from the pgcache directory to where you want the pgcache to be.

For example, I moved the pgcache to be stored in-memory with these commands:

cd /var/www/html/wp-content/w3tc
sudo rm -rf pgcache
sudo ln -s /dev/shm/pgcache pgcache
sudo chown apache:apache pgcache

(paths with vary on your system)

The link looks like this:

$ ls -l /var/www/html/wp-content/w3tc/pgcache
lrwxrwxrwx 1 apache apache 16 Jul 29 21:13 /var/www/html/wp-content/w3tc/pgcache -> /dev/shm/pgcache

Was the W3TC “Purge Policy” set to purge the cached page on update? If it wasn’t then you are dependent on wp-cron to purge the cached page and wp-cron won’t run if all the pages you access are cached with ‘disk (enhanced)’. To solve that problem you would need to run wp-cron.

When a new comment is added W3TC always empties both the object and db caches. This has the effect of wiping out your cached comments. If you really want to keep the comments cached separately you will need to handle the caching yourself (e.g., by putting the comments in memcached, assuming W3TC isn’t using memcached).