I hope I am posting this in the correct queue.
I have tried every method to disable caches that I could find, most importantly using the dev subdomain

the views .tpl.php files are caching for a bout an hour...somewhere...on the server level is my guess. Rebooting server will clear this file from whatever cache it is hiding in. Other changes are observed immediately, even changes to the views themselves, but changes to the views tpl.php files are not seen for about an hour.

This is a vague post, but I have done so much to disable the tpl.php caching that I cannot possibly list all of it here.
Unless I am missing something (simple), it is being overlooked in the dev subdomain method of disabling the caching

Comments

omega8cc’s picture

omega8cc commented
Component: Code » Documentation
Category: bug » support

1. You need to know that Views are using its own cache system, independent of Drupal main caching.
2. There is a button to clear Views cache under the Tools tab in Views admin.
3. Redis and Memcached are caching also Views cache tables.
4. The dev. subdomain only stops enforcing main Drupal cache (not Views cache) as enabled - it doesn't disable it automatically!

If you are experiencing the issue while logged in as an admin in the /admin area (so it is not a result of Speed Booster cache) and *after* you cleared both main Drupal cache and Views cache, then try to purge Redis and Memcached - however it is done automatically every 30 minutes anyway: bash /var/xdrago/clear.sh

Lowell’s picture

Lowell commented

Thank you so much, yes I have views cache disabled and was purging both Drupal and Views cache. Even so...

bash /var/xdrago/clear.sh is the only way for me to access my updates immediately...AND IT WORKS !!! YAY !!!

Is there a better way?
Can I disable REdis and Memcached...temporarily as needed?
Seems silly to restart redis-server repeatedtly, esp. during development.
Even better would be to disable them per site, or even set really short cache settings...tempoorarily.

omega8cc’s picture

omega8cc commented

Yes. Please read: http://omega8.cc/speed-booster-cache-boost-and-advagg-108#cache-off

Lowell’s picture

Lowell commented

my understanding so far is that I have implemented everything referred to at http://omega8.cc/speed-booster-cache-boost-and-advagg-108#cache-off and yet the only way to see views .tpl.php changes immediately is with the use of the clear.sh script

So. As a result I am confused why I am being directed back to the speed-booster info page.

Note*
I am using a dev subdomain, all Drupal caches are disabled, ubercart is installed, logged in as admin, using the modules/cache/NO.txt file, using the /data/conf/overide.global.inc file...ummm, what else...hmmm

only clear.sh works! gratefully...

please let me know if I am missing something, otherwise I am asking the following (or maybe this really is a bug):

Is there a better way?
Can I disable REdis or Memcached...temporarily as needed? (obviously something is still caching)
Seems silly to restart redis-server repeatedtly
Even better would be to disable them per site, or even set really short cache settings...temporarily.

omega8cc’s picture

omega8cc commented

The cache/NO.txt does just that - disables Redis/Memcached per site or per platform - on the fly, immediatelly. It is unrelated to Speed Booster. If cache/NO.txt doesn't disable Redis/Memcached for you, then you must doing something wrong there, sorry. With this control file present there is no point to run the script.

omega8cc’s picture

omega8cc commented

Also, please don't repeat the same comments and questions twice ;) I already answered them.

omega8cc’s picture

omega8cc commented

By the way, what is your BOA version installed? Please follow bug submission guidelines in the future.

omega8cc’s picture

omega8cc commented
Status: Active » Postponed
omega8cc’s picture

omega8cc commented
Status: Postponed » Postponed (maintainer needs more info)
Lowell’s picture

Lowell commented

ok, sorry, I really don't post questions often, I am trying to help

_AEGIR_VERSION=1.0-boa-T-8.10

using both:

/data/disk/.../.../sites/all/modules/cache/NO.txt
and
/data/disk/.../.../sites/www.mydomain.com/modules/cache/NO.txt

I looked in the clear.sh file, and saw the "/etc/init.d/php-fpm reload" command, so I tried just that and it works
so it looks like the php-fpm is doing some kind of caching which isn't being automatically disabled by the previous techniques

this leaves me with the same set of questions, "is there a better way than to have to execute the php-fpm reload command?" and "can I do this per site?" also, "is this a bug?" (sorry, I repeated myself, didn't I)

omega8cc’s picture

omega8cc commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Standard Barracuda php.ini has an option apc.stat = 1 for APC, so it is designed to check if the files have been modified and update the APC cache immediately. If this doesn't work for you, then it is either your system date/time setting issue or unknown bug in the APC itself. In any case, it is not directly BOA related issue. You need to check how APC works on your server and report the issue in the APC project issue queue. Anyway, it is the first time anyone reports the issue and we use the same APC version for months, so I'm not sure if this is a wider problem or rather your server specific. Note that APC cache is also purged every 30 minutes, as php-fpm is reloaded every 30 minutes, automatically. There is no other workaround - you need to reload php-fpm until you will find why APC doesn't update its cache on the fly. Feel free to re-open the issue if you will find anything new.

Lowell’s picture

Lowell commented
Status: Closed (cannot reproduce) » Closed (works as designed)

nice...apc.stat = 1

now I know what the drupal reports, apc comment means when it says:

"But web-server restart or call to apc_cache_clear() will be required to update."

thanks again for the insight and support