31

Is there a simple way do prevent all caching when testing the appearance of changes to the site? I use WP Super Cache. I can delete its cache using the option provided, delete the cache for my browser, and still some changes to css or widgets do not refresh. I try other work-arounds like switching browsers or computers, but there must be a more stream-lined workflow where I can ensure I'm viewing the changes I made and not some cached earlier format? What's the best solution for this?

  • It seems there are also several plugins just to do this for CSS. Is it really necessary? Do those plugins do something that clearing browser cache does not? – cboettig Jan 30 '12 at 17:53
  • In my case it turned out I had to clear the cache created by the DNS provider (cloudflare). Thanks all for the suggestions below though. – cboettig Jan 30 '12 at 23:35
  • I use Chrome browser; Its incognito window comes handy, when I come across browser level cache issues during development. – Joseph Kulandai Nov 8 '13 at 6:47
  • Hope this plugin will help you: wordpress.org/plugins/prevent-browser-caching – Kostya Tereshchuk Jan 31 '18 at 15:41
32

Add the filemtime() of your stylesheet as version parameter. Lets say, your default stylesheet is in css/default.css and css/default.min.css (not style.css). When we register a stylesheet on wp_loaded (not init), we can pass a version as fourth parameter. That will be the last modified time and therefore change every time we change the file.

$min    = WP_DEBUG ? '': '.min';
$file   = "/css/default$min.css";
$url    = get_template_directory_uri() . $file;
$path   = get_template_directory() . $file;
$handle = get_stylesheet() . '-default';

// Overridden?
if ( is_child_theme() && is_readable( get_stylesheet_directory() . $file ) )
{
    $url  = get_stylesheet_directory_uri() . $file;
    $path = get_stylesheet_directory()     . $file;
}

$modified = filemtime( $path );

add_action( 'wp_loaded', function() use ( $handle, $url, $modified ) {
    wp_register_style( $handle, $url, [], $modified );
});

add_action( 'wp_enqueue_scripts', function() use ( $handle ) {
    wp_enqueue_style( $handle );
});

If you are using Node.js and Grunt, I strongly recommend Browsersync. It will watch your files and update them instantly whenever they change. It can also synchronize the scrolling position, form submissions and more across multiple open browsers. Very cool.

  • Many thanks. It appears this is also the approach of the above plugin. It did not solve the problem in my case because my DNS provider (CloudFlare) was caching the css file, so I had to clear the cache there -- guess there is no simple way around that. In general though, I think this is the best answer to this kind of issue so I'll mark accepted. Thanks again. – cboettig Jan 30 '12 at 23:33
  • Why don’t you use your local stylesheet during development? – fuxia Jan 31 '12 at 0:59
  • Some cloud caching services will hard cache your file for 8+hours, so you either have to request them to implement a better service for versioning (some do this), change services, or stop using them. – Wyck Jan 31 '12 at 16:38
  • @cboettig CloudFlare has a dev mode setting which will stop caching for a 3 hour window. It then automatically resumes caching after 3 hours. – Gilbert Aug 25 '14 at 20:13
7

After searching for a simple solution many times i decided to find something that works!

so... after thinking about it i found a great way to override caching while developing new websites... (and its easy).

What we need is to tell wp this is a new CSS version like this...

Before changes:

wp_enqueue_style( 'maincss', get_template_directory_uri() . '/css/style.css', array(), false, 'all' );

After changes:

wp_enqueue_style( 'maincss', get_template_directory_uri() . '/css/style.css?v='.time(), array(), false, 'all' );

This is what we added:

?v='.time()

Explanation:
We are basically adding a dynamic version number to the css file which forces the browser to load the new css every time we update it.

Don't forget to remove it after your done developing otherwise your caching won't work for this file and it would load for returning users again and again.

This technique works for css & js files - hope this helps ;)

  • Pretty nice, but better still, just use time() in the 4th parameter which is version. Which would give you: wp_enqueue_style( 'maincss', get_template_directory_uri() . '/css/style.css', array(), time(), 'all' ); – Dave Sep 13 '18 at 1:41
  • Using time as the 4th parameter might cuase chrome to hold on to that version. This is especially true if your caching everything else while you work on a live site. This way you are submiting a "new file" to chrome which he would use instead of trying to keeps that "old" version for an amount of time (as set for other resources). – Sagive SEO Sep 13 '18 at 9:24
  • Nope, works fine in chrome, I was using it yesterday. – Dave Sep 14 '18 at 3:34
  • that means you havent set cache / expiration time in your htaccess or via a plugin. But, whatever works for you ;) – Sagive SEO Sep 14 '18 at 12:26
6

This might seem overly simple, but how about just disabling caching until you're done with the development portion of your site? It's more than simple to turn on and off.

  • 2
    +1 - I use "Web Developer" toolbar for Firefox, allows you to very quickly disable cache (among other things) – Shane Jan 30 '12 at 17:44
  • Thanks - is it only necessary to disable the browser's cache? Will WP superCache still result in providing cached content? Even my DNS service caches, so I am uncertain if I need to disable every cache (WP, browser, DNS, etc) separately. – cboettig Jan 30 '12 at 17:48
  • Sorta depends, you'll have to play around with it and figure out what you need to do for your configuration. – mor7ifer Jan 30 '12 at 18:23
  • Im with him, just disable it, thats what I do. – matt Jan 30 '12 at 23:07
4

I know that this question has had an answer accepted, but I think that that answer is still too complicated for the problem at hand, and may actually be incorrect depending on the user (no offense though), so I thought I'd still share how I bypass caching when I do my dev (not just with Wordpress).

Most modern browsers have something called incognito mode. In this mode, nothing in your computer is cached, so every refresh is a fresh slate download off the server. In Internet Explorer you press Ctrl + Shift + P. In Firefox and Chrome, you press Ctrl + Shift + N.

If your browser doesn't have incognito mode, you can normally force a hard reload by pressing Ctrl + F5 for IE, or Ctrl + Shift + R on Firefox and Chrome.

As for your question regarding the CSS files (and essentially, all your asset files, like images and Javascript files), those aren't cached in any way by WP Super Cache. Your settings and/or use of this plugin does not affect how those files are served. What's caching those files are your browser, and that's the reason why you do a hard reload.

What the plugin does is it evaluates how Wordpress builds your HTML files (via PHP), and stores a copy, so that the next time someone requests the same post, page, or whatever, it serves the copy, and won't have to reevaluate the PHP-generated HTML again, and therefore save some computing time, loading your pages that much quicker. (I hope that's clear.)

The problem with that is, if you're slapping on a timestamp on your CSS files' URL via a PHP function, that is a PHP evaluation to HTML, and that will be cached by WP Super Cache. Every request to the same post will have the same timestamp because users are being served a copy of the original timestamp evaluation. (Correct me if I'm wrong.)

The correct way to bypass WP Super Cache's caching is to set the option Don't cache for known users to true in the plugin's setting page.

Finally (and this is a personal preference, as I'm a real stickler when it comes to coding), resorting to the use of incognito or forced hard reloads won't require you to add unnecessary markup on your HTML pages. Of course, adding a timestamp only adds about 13 bytes per static file per request, but hey, like I said, I'm a stickler for this kind of stuff. It's still 13 bytes unnecessary.

  • Thanks for the useful tips. Unfortunately none of the answers here are correct in my case, since my solution required clearing the cache of the Domain Network Service provider, cloudflare, but many were still good information. – cboettig Feb 1 '12 at 19:50
2

Gosh, many ways to answer this one! First and foremost, you asked about two different things: WP Super Cache and CSS files. These are cached differently, in different places, so it's important to recognize where your problem is.

If WP Super Cache, you can define the constant DONOTCACHEPAGE in your functions.php during development to prevent WP Super Cache from caching anything. Don't forget to remove this on launch though!

define('DONOTCACHEPAGE', true);

Each site also has a unique key to append to the URL to load a fresh version of the page, which you can find in the "Advanced" tab, I believe.

Breaking it down to an even better solution, you should consider setting up a development environment and a production environment, where your development environment doesn't have WP Super Cache enabled (again, assuming that's your problem).

If your issue is with CSS/JS files, then see the answer by toscho and subsequent comment by m0r7if3r above.

1

HyperCache disables caching when you're logged in as an admin. Not sure whether WP Super Cache has the same functionality.

  • There is an option for that, yes. – Matthew Boynes Jan 30 '12 at 21:53
1

If you're using Chrome (which I highly suggest), open Inspector, click the settings icon in the lower right corner, and under "Network" select "Disable Cache."

0

As said for wp super cache, but for general WP caching in wp-config.php Change to this:

define( 'WP_CACHE', false );

Reference: codex.wordpress.org

-1

You can use this snippet https://gist.github.com/jhayiwg/92bae4330aeb738a98022d7ab63ce9b1

It will generate new version of your active theme css and js every time you load the page

  • Please, post the answer here, including all the relevant code. Use external sites only for reference. Your post should provide a full answer without the need to go to other site; if the third party site goes down, your answer will be unuseful.. – cybmeta Oct 20 '17 at 8:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.