drewid I'm running lemming with the latest monobook template. There seems to be something odd with the cache behaviour and I'm not sure if it's the apache server , monobook or the wiki configuration. The caching seems to be a bit random. When you edit a page the edit doesn't always show up in the output. The new content is still there if you go to edit the page though. All the dokuwiki settings are default. cachetime is 60*60*24, permissions are 755 for folders 644 for files.
dominik in normal purpose the cache shouldn't do such things. I guess it is a proxy or the browser cache. try to reload the page if this error occurs
drewid Well it's not the browser cache. Are any of the files supposed to be _not_ 644 as default? I may have changed the permissions on a particular file while trying to fix something else.
drewid Here's what I've tried so far. touch conf/local.php and touch inc/parser/xhtml.php PHP safe mode both on and off. CHmod various directories to 777 php_flag session.use_cookies on” in .htaccess file Putting &purge onto the end of the URL works. (but is not ideal). Any other ideas? Could we stick a &purge into the save part of the process? I'm shooting in the dark here, this stuff isn't my field. I guess worst case I could disable caching.
drewid Just got this from Servage (my host) It seems that time was not is sync in our clusters. Our admins have corrected it and all time is on sync now. Well I guess that explains it then...
dominik usually dokuwiki does something like purge automatic after a page edit. a time difference between client and server doesn't affect dokuwiki because the caching stuff is only server side
bernardid 43 minutes in the future .i Last Modified Date I am investigating Drewid's setup right now, I am new to DokuWiki. Here are my findings: The .i (instruction cache) file is being created with a Last Modified date which is 43 minutes in the future! (as reported by FTP because we do not have shell access here unfortunately). Yes, exactly 43 minutes and zero seconds more recent than the .xhtml (which date seems perfectly normal compared to the system clock). When I edit a page "again", I see the .xhtml being "updated" (Last Modified date changed).. but it gets updated with the same "old" content since the .i was not updated because I suppose it was "more recent that the page content". If I wait more than 43 minutes, then all "works" like normal (for 1 edit) (the .i gets updated but again with a "future" timestamp). Now I am trying to see what could create this "43 minutes" weirdness? thanks
bernardid Ok, I located the piece of code that actually "writes" the cache files to disk. If I modify the logic to dump another copy of the same file at the same time, the file time is "correct". Actually, I did this for the .xhtml too and the .xhtml (which I thought was ok) was actually 45 seconds in the future! I am dumping this info now in case it rings a bell to somebody. The .i file's Last Modified date is 43 minutes and 45 seconds in the future. The .xhtml file Last Modified date is 45 seconds in the future. I saved the same files using the same methods at the same time but the Last Modified date of these was normal. In short I added the following: if(substr($file,-2) == ".i" || substr($file,-6) == ".xhtml") { $fh = @fopen($file.'-test2',$mode); fwrite($fh, $content); fclose($fh); } ..at the end of io_saveFile() in inc/io.php Something is probably modifying the Last Modified date -- like performing a touch() or something??
carmenmbr Hi, Somebody solved this problem like this: Example: {{:servers:backup-restore.txt?nocache|}} It's works! Carmen
irow I was having this problem on a new install running on a CentOS 7.2 minimal install. I fixed it by installing and configuring the NTP server. Here's what I did: yum install ntp chkconfig ntpd on ntpdate pool.ntp.org service ntpd start