Disable all caching during development

v3
#1

We primarily use EE for our development server. I want to disable all cache across the server.

I followed 2 of the methods here: Disable Cache while developing

  1. set $skip_cache 1;
  2. ; zend_extension=opcache.so

The WP instances are created with no cache enabled. However, when making a single CSS edit, we have to run ee clean from the command line in order to view changes. The purge cache function in the admin bar doesn’t work.

Any thoughts?

#2

Am I the only one experiencing this?

#3

This seemed to do the trick:

server_tokens off;
    reset_timedout_connection on;
    add_header X-Powered-By "EasyEngine 3.3.1";
    # add_header rt-Fastcgi-Cache $upstream_cache_status;

    # Limit Request
    limit_req_status 403;
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

    # Proxy Settings
    # set_real_ip_from      proxy-server-ip;
    # real_ip_header        X-Forwarded-For;

    #fastcgi_read_timeout 300;
    client_max_body_size 100m;
#4

Incorrect, this still has not solved it.

still have to run ee clean every. single. time.

#5

aaaanyone?!

#6

Single CSS changes being cached has been a long standing issue during DEV that hasn’t gotten an answer. I use a work around.

Same topic

#7

What work around do you have, we are going nuts with stylesheet caching issues

#8

I think I finally figured it out. I removed the pagespeed and fastcache .conf files from the conf.d inside nginx folder.

So far, no caching.

#9

I’m having this issue too. It has something to do with the ?ver= added to the end of CSS files in Wordpress.

ee clean is the only way I can do a purge.

If I use the autoptimize plugin it circumvents the problem but this isn’t ideal during dev stage.

#10

@davidedwards I use the following. and increase the version numbers. It’s a real pain and others complained stating this wouldn’t work for them, but previously no one had a good answer on how to fix this.

#11

@Paul_Yates,

We typically strip query string after style sheet so it’s not that in our scenario. Just an FYI.

1 Like
#12

@karlhaworth

Arggh, we really need a solution for this because it makes the development, to staging to production workflow a major, major pain.

And forget ver / query string stuff; for us that’s a no win at all because when we move sites to production our CDN management will become a burden (either larger due to tons of version of stepping on each other without ver).

#13

Well I don’t quite have the skills required to code this all up and create a pull request.

@davidedwards if you don’t like the workaround I have, you can go ahead and create a fix as this project is open source!

#14

@karlhaworth to be clear that was no dig / complaint to you; just for those of us doing active dev of sites on EE would be nice to have more of a simple and dev friendly way of doing so without cache.

I wish I had time to fork it and build it in; but alas building and deving sites is the prime activity; hence using and loving EasyEngine (esp for the Easy part). We’d rather spend time and resources creating site vs. admin servers.

#15

@davidedwards I hear ya, but just ensuring you know that’s an option. A few have complained about how big of a hassle this is, fail to do anything about it, and then complain that my workaround won’t do.

I agree the workaround sucks, but it sucks more that this caching is happening during development and there’s no real fix. I’m just trying to get by with what’s there. If you find anything else to ease this frustration, please let me know.

#16

For our specific use scenario versions fail because we try to keep our CDN usage high. It would mean when promoting dev to staging or production we’d have to deal with special version “refactoring” or whatnot and CDN stuff by hand.

For others versioning probably isn’t a big deal, but as we strip all query strings to maximize the CDN usage it’s a non starter.

Widespread SPDY / HTTP2.0 can’t come soon enough.

#17

+1 for HTTP2.0

#18