Fooled you. You think that cache is the problem, but it’s not.
Scenario 1… You installed Vagrant with VirtualBox on your local machine and have a sweet nginx setup going as your development environment. You made a few changes to a CSS file and the new style is not reflecting on the page. You try saving the file again in your text editor, no go. You look at the file on the server, it’s cool. You restart the nginx service, still no change. You restart the services for php5-fpm and memcached, maybe even mysql… no go.
Something has captured this file in cache and is not letting go!
Scenario 2… Same setup. You made a few changes to a JS file and the script doesn’t seem to be working. Must be a caching issue. You try saving the file again, look at the file on the server, restart nginx, restart everything. Finally look at the console in your browser and see some kind of random error.
Sooner or later, with one of these files, you open it up and see these:
What the what? It’s an encoding issue? Not a caching issue? Or it’s a… wait, what?
Hopefully you haven’t spent too much time trying to figure this out before stumbling on a site like this one that tells you the only change necessary is a simple line in your nginx config file.
Find the spot in your assorted nginx config files that says ‘sendfile on’ and change it to ‘sendfile off’.
Sendfile is used to ‘copy data between one file descriptor and another‘ and apparently has some real trouble when run in a virtual machine environment, or at least when run through Virtualbox. Turning this config off in nginx causes the static file to be served via a different method and your changes will be reflected immediately and without question – or black question mark diamond thing.
Hope that saves you a minute.
For further reading, consider those that have stumbled on the same problem before.
Or, even better – more detail about sendfile itself and other common nginx pitfalls:
When developing locally with APC enabled, you might be inclined to clear cache forcefully lest you go crazy.
Local development with APC is great if your production environment also takes advantage of object caching. Every once and a while you may even forget that you have it turned on and then you’re trying to figure out why your recent changes aren’t doing anything.
Rather than disable it entirely, only to forget to turn it back on – you can forcefully clear the cache whenever you want:
apc_clear_cache(); apc_clear_cache( 'user' ); apc_clear_cache( 'opcode' );
You’ve hooked into the appropriate core actions, loaded a template file and added a quick echo to test the beginnings of your feed. You bring up a browser, load the feed, and are satisfied when you see the output you were expecting.
Now, you code out the rest of the feed. Put in a query, loop over the results and mold your output. Sweet.
Refresh the feed in your browser and bam – same test output from before.
You hit Google and start searching. One place tells you to delete your transients, another tells you to define your own Magpie cache settings. All of them were written in 2007.
And then you run into this page, which dutifully informs you that WordPress is not caching your custom feed.
You are. In your browser. Clear the cache.