There are autoptimize css files entered in the html code but there is none on the server. Is that correct?
No, you should see files appearing in wp-content/cache/autoptimize/css.
I tried a rollback to 2.4.4 or 2.4.3. That kills my backend (white screen) possibly due to changes to the database.
AO does not use it’s own tables, just the stock wordpress options, so rollbacks _should_ work.
Any idea, what I can try to resolve this?
I guess the first thing to do would be to check your php errorlogs for (relevant) errors. Also check if there are files in wp-content/cache/autoptimize/js to see if the problem is specific to CSS or not?
For the rollback I just installed an older release and did not undo any changes to the database(content) and did not install any backup. Since there have been changes to the setting options I thought that might be the problem.
There are no files either in css or in js and no entries in debuglog. When are these files created? When the page is first called (after activation or dump of cache)?
There are no files either in css or in js and no entries in debuglog. When are these files created? When the page is first called (after activation or dump of cache)?
Files are created when requests are coming into WordPress (so not served from a page cache). In fact that could be the problem; do you have a page cache which needs purging?
No, the cache is empty. I did that first.
and any errors in the php errorlog?
Like I wrote before there are no entries concerning this plugin in the debuglog. There are some errors from my trials with the rollback but nothing from 2.5.0. Debuglog shows anything down to notice.
Ah, I hadn’t seen the mention of no entries in debuglog, sorry.
I’m pretty much clueless here I’m afraid; AO25 has been out for 8 days and has been download approx. 298K times since, and this is the first mention of cache-files not being written any more, which makes this an unlikely candidate to be labeled a regression and hence this is likely to be a specific local issue somehow.
Some off the top of my hat ideas for next steps:
* check if the directories have the correct permissions set (the user under which PHP runs needs to have Read, Write & Execute permissions on wp-content/cache, wp-content/cache/autoptimize, wp-content/cache/autoptimize/js and wp-content/cache/autoptimize/css
* if you have a stagings/ testing site see if you can reproduce the problem there, if so we can do some debugging there
* check your webserver logs for requests with ?ao_cachebuster=1 in the URL as these indicate the AO cache being cleared. if AO’s cache is cleared a lot that might explain the issue as well and this could be caused you could have a plugin that is doing things wrong (e.g. an update of the “wp hide & security” plugin caused a huge amount of AO cache-purges for some users)
* you could add some debug-code to the cache method of the autoptimizeCache class (plugins/autoptimize/classes/autoptimizeCache.php) to check if the cache function is called and whether it tries to write and if that write is succesful?
* you could try below filter, which forces AO to check on cache-directory existence upon every cache write;
add_filter('autoptimize_filter_cache_checkdirs_on_write', '__return_true');
frank
Have you had time & energy to further look in this weird issue @bbuerger ? Any news?
Unfortunately not. I will reply to this as soon as I have any news.
