WordPress caches way to much

I don’t know the answer, but I can say this– I’m fairly new to WordPress and have not experienced any of what you’re speaking of, so I suspect the problem is specific to your installed version of WP or the way it’s interacting with your chosen host server.

I know that’s not terribly helpful, but I thought it was at least a useful piece of info to have.

It would also help to know which caching plugin or utility you’re using.

Soory, stupid me.
Im on Firefox 1.0.3, have no caching plugins nor any plugins to generate static pages, The WP is running onto a PHP 5 Server

I’ve noticed bizarre caching behavior in WordPress 1.5 also (running on Apache, PHP on an XServer under MacOS 10.3.9). If I log in as administrator and change the theme, I do not see a different theme until I load a story which I have not loaded before. This happens across browser even after flushing my caches. I am not running any caching plugins except for del.icio.us and flickr data.

We saw this issue yesterday when we rolled the database back to nightly backup. We still saw posts that were made after the database backup (e.g. we were seeing content that didn’t exist in the database). These posts would show up in browsers on machines that had never been to the site.

There is something strange going on with WP caching.

– Jim

Jim – what plugins / caching utilities do you have ?

Plugins that are Active in WordPress except those marked deactivated:
— cat2tag
— delicious
— deliciousTagging
— flickrrss
— hello (deactivated)
— include_page (deactivated)
— markdown
— technotag
— textile1 (deactivated)
— tw-touched
— weighted_categories

Caching utilites – none that I know of. My sys admin restarted Apache and mysql and we still saw the same issues. He isn’t running any other caching (pear etc) schemes.

– Jim

I posted this to the hackers list and one reply so far:
“I’ve dug into the core a bit and not seen anything that would cause this kind of cross-session caching. My guess is that Apache or PHP is configured to serve the headers incorrectly or there is a caching proxy that’s misinterpreting the headers. I wonder if the problem exists for people browsing from other locations. ”

My first suspect would be ISPs with transparent caching proxy servers. A lot seem to use these without customers necessarily knowing about it. These can usually be persuaded to behave by hard refreshing (in IE/Win Shift+F5 does the job). It’s not unknown for them to fail to resepct headers (which is why Blueyonder eventually agreed to drop theirs, as I recall…)

I’m at a remote site (Arlington VA) and my sys admin is on location with the server. I have set up another instance of WordPress for a friend on the same server. His site doesn’t have the problem. His site is running on the same server as mine.

– Jim

Let me clarify slightly – the Site is in Madison WI

-Jim

I did take some look into the code. I don’t think WordPress is caching by default. The problem could be with your browsers setting, transperant caching as some mentioned or a remote possibility is cookies. I have seen strange things with WP & cookies. Try removing the WordPress cookies and see if that helps. Also try accessing your server through an anonymizing service (use tor if you must) and see if the problem persists. If you are connecting through a proxy then see if the proxy supports socks. If so uncheck the http proxy and use only the socks proxy.

I traced my IP, my ISP ist not routing my adress, and i have never experienced such behavior at forums or other login masks.

Only here

If you are able to see posts that don’t physically exist in the database, that’s NOT wordpress’ doing — not without WP-Cache or Staticize or other caching plugin. It’d have to be either MySQL caching (which should be flushed on a reboot), Apache or some kind of HTML caching ‘box’, or something on your local machine.

WP doesn’t cache the dynamic post data forward of the database — only with the addition of Staticize or WP-Cache is there a static-file representation of a post, which would possibly be able to be pulled up even when it isn’t in the database. Again, otherwise something ‘further forward’ in the chain has to be providing the ‘false caching’ that is occurring.

-d

Well, but WP can influence the caching behavior, i found that on bug tracker
https://mosquito.www.ads-software.com/view.php?id=721
But my account is not on a ‘dreamhost’ server

Looking further for the wp-header.php