Not sure where this belongs... Boost or Core CSS. My cached pages references an aggregated css file, located here "sites/default/files/css/10dfa6f2a7c058099bd4854b60fc9047.css". Come back a little while later and my log is full of page not found errors pointing to that css file. It means my entire cache is bad because it's now pointing to a dead file. Why is the css file being killed and what can I do about it?

Never updated any css files/entries so not sure why it made a new one. I am using css injector, but like I said, I never changed anything, the site just sat there and all of a sudden the css file gets nuked. My temp fix is to copy the current css file back to the old name via ftp.

CommentFileSizeAuthor
#12 boost_admin_modules.patch1.63 KBalex s

Comments

andreiashu’s picture

andreiashu commented

Hi Mikey,
I don't think this is an issue with boost.
I know that you already said that you didn't change anything but something/someone probably modified the css and its hash is now different but your static cache does not reflect that. You might try to backup one css file when it gets generated and then when the log errors appear see what the new css file has different from the old one.
You said that you use css_injector. Well probably you have a rule defined that modifies your css content on specified periods.
I can not think to anything else now that could cause this behaviour.

Regards

mikeytown2’s picture

mikeytown2 commented

I'll put all the css injecting rules into the current theme's css file and disable css injector... will let you know the results hopefully in a couple of days (if sooner then its something else).

mikeytown2’s picture

mikeytown2 commented

I think I figured it out...

The site is brochure-ware with 200+ nodes; the content changes slowly, it's on cheap shared hosting, thus boost is a good option. Cron runs once a day and I have "Purge expired cache files on cron runs:" to Disabled. It seems that after a cron run the aggregated CSS file is rebuilt. And that is the problem. I keep the expired cache because it it hasn't changed. Old css link no longer works. Site gets around 300 page loads a day right now, and it can take well over 10 seconds to load a "live" page. After a change to the site, purge cache; run a sitemap generator on the site because it crawls the site, thus the cache is primed 1 hour and 700 pages later (yes the web server's php is that slow).

There are several options here:
1. Make it so css doesn't get regenerated on every cron run if purge expired is disabled.
2. Enable the purge and install a local sitemap generator (any crawler) that gets called via cron.
3. Have Path Redirect redirect the old CSS to the new.
4. Never run cron.

A side effect of option 2 is that the content is pushed instead of pulled. It's also a "ducktape" fix.

alex s’s picture

alex s commented

This issue also applies to JS aggregated files.
Cron should not rebuild aggregated files. Looks like aggregated files are rebuilt under the following conditions:
- submit in admin/build/themes
- submit in admin/build/modules
- submit in admin/settings/performance
- 'clear cached data' pressed on same page(it does not cause problems, because boost cache is also flushed)

The only solution I see is to press the 'clear cached data' button when this error occurs.
Also you can comment css/js cache clearing, so old files will not be removed and everything will work, but that would be a core hack. If you're interested, i can tell how.
By the way, mikeytown2, if you use nighttime color scheme or something like that, this functionality is easy to implement with jscript.

mikeytown2’s picture

mikeytown2 commented

I'm leaning towards option 2... every cron run it flushes the cache. then 5 min later I have another cron run to creates a sitemap (via some php sitemap generator). I'll share the details once I'm done.

Thanks for taking the time to look into this. I needed to push the content anyway so It's a fairly simple solution, and it should be easy to do.

mikeytown2’s picture

mikeytown2 commented

Upgraded a couple of modules and it triggered a new CSS file as well. It could have been the related database update for the module that did it.

mikeytown2’s picture

mikeytown2 commented

Confirmed that also happens on a database update. Not on module file updating.

alex s’s picture

alex s commented

Maybe we need to implement hook_flush_caches ?

mikeytown2’s picture

mikeytown2 commented

In regards to post #3 above http://drupal.org/node/365864#comment-1233463. I've made my own php site crawler. Get it via link below
http://drupal.org/node/363077#comment-1244467

It's set for Go Daddy. You need to change $system_php so it points to the your hosts php interpreter.

SteffenMaass’s picture

SteffenMaass commented

I had the same problem and solved it by implementing hook_flush_caches(), see #355529: boost_cache_clear_all does not delete files

Regards

mikeytown2’s picture

mikeytown2 commented

that patch doesn't work when doing a submit in admin/build/modules. Just tested it. The boost cache is still there, and the css file has changed... anyway to detect when a submit is done, or detect when a change happens with the css file?

alex s’s picture

alex s commented
StatusFileSize
new boost_admin_modules.patch1.63 KB

The patch should not work in this case. In admin/build/modules hook_flush_caches is not called. As in admin/build/themes. I added form alter functions to flush cache in this cases.

mikeytown2’s picture

mikeytown2 commented

alex s, thanks for that! but what about when update.php runs or a submit in admin/settings/performance?

alex s’s picture

alex s commented

update.php fires hook_flush_caches. In admin/settings/performance on submit the cache is cleared when boost was enabled and you disable it. I had similar problems when there were more than one copy of boost module in sites/all/modules folder. I removed the second copy of boost and reenabled the module.

mikeytown2’s picture

mikeytown2 commented
Status: Active » Needs review
Issue tags: +Release blocker

adding tag, #12 works

mikeytown2’s picture

mikeytown2 commented
Status: Needs review » Fixed

committed patch from comment #12

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

plan9’s picture

plan9 commented

This patch is really needed for 5.x branch also.
Anyone know how to backport it?

Thanks

G

mikeytown2’s picture

mikeytown2 commented

@plan9
See #454652: Looking for a co-maintainer - 5.x

AlexisWilke’s picture

AlexisWilke commented
Status: Closed (fixed) » Active

I just ran into that problem, so the fixes you talked about in this post probably did not do what they were supposed to do...

My pages are cached for 7 days since they do not change very often, I do that to completely offset the load on the server. It is very impressive! 8-) With a site of nearly 10,000 pages and another about 20 sites, I have a server load of 0.10 or less most of the time.

But the CSS files get knocked off once in a while... and the site looks bad.

I just turned on the "Cache .css" in the Boost interface to see if that resolves the problem. I'm afraid that it won't because multiple pages may be created with the same CSS and the "old" CSS will be removed when the system CSS was replaced a while back.

I think that the only sure answer would be to fix the Core as mentioned in a post earlier.

There is a scenario which I think is what's happening:

Day 1 -- visitor sees home page -> cached with CSS

Day 3 -- visitor comes on page /other -> cached, makes use of old CSS

Day 4 -- website CSS changed, somehow

Day 7 -- home page & CSS deleted (Cache is old)

Day 8 -- another visitor comes on /other -> the CSS is missing...

Why the CSS was regenerated, not too sure. I may have changed it directly. I know I have done an update of a module... but I'm not too sure what really did it.

Does that scenario match what you'd think would happen with the current system?

Thank you.
Alexis

mikeytown2’s picture

mikeytown2 commented

Boost is only supposed to delete the contents of the perm dir, only if the admin cleared the cache. It should never auto delete anything inside the perm dir, if it does then thats a bug. There is the off chance that boost didn't pickup the css files & thus it never got cached. I can confirm this is a real bug because about once every 2 months or so one of my sites doesn't have any CSS. Hard bug to repo IMHO. Open to ideas.

AlexisWilke’s picture

AlexisWilke commented
Status: Fixed » Active

Two things in that regard...

1) In my case, I did not have the CSS Boost cache turned on. So it was not under perm/... which is what I think was the main problem in that regard. The CSS aggregation is a pain in the butt in that case.

I have two solutions for this special case:

a) Put a huge red warning (a Drupal error) whenever the CSS aggregation is turned ON and the boost CSS cache is turned OFF;

b) Simply use BOTH flags to know whether to cache the website CSS.

I would opt for option (b) since it makes it simpler.

2) I have a setup which is certainly different from most other websites. I use two sub-domains:

http://www.m2osw.com

and

https://secure.m2osw.com

Both are being boosted and each go in a different folder (you have to because otherwise many links end up totally broken. Especially, I had many non-secure links that would appear on the secure site.)

In that case, the concatenated CSS file ends up under m2osw.com/files/css/MD5.css and is used by both sub-domains... That complicates things even more since it could break on one site and not the other (i.e. the file would be saved in www but not secure, and one day someone comes on a secure page and does not get the CSS, or vice versa. I'm not totally sure that can really happen, but that's a thought.)

Anyway... At this point, I think that implementing option (b) would resolve most of the problems with CSS.

Thank you.
Alexis Wilke

mikeytown2’s picture

mikeytown2 commented

going to mark this as fixed again; might want to look at this patch for core.
http://drupal.org/node/721400#comment-2703462

mikeytown2’s picture

mikeytown2 commented
Status: Active » Fixed
AlexisWilke’s picture

AlexisWilke commented
Status: Active » Fixed

Mikey,

Interesting patch... I like it. I wonder whether it will be applied. It looks like they are fighting quite a bit over that one...

So far, I did not get any errors again, but what I mentioned in #22(1)b should still be considered. It was my mistake to turn ON the CSS aggregation and not the Boost CSS cache, but it should not be possible to do such a mistake!

Thanks for the help!
Alexis

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

sigent’s picture

sigent commented

try this
1. boost options : check the options - Cache CSS and Cache JS
2. boost htaccess code : get the code
3. insert it in htaccess file

you should insert the code generated after checking these options!

i made the mistake that stole my day :(. maybe it's the same in your case.

bryancasler’s picture

bryancasler commented

#23 does not work for me

mattcasey’s picture

mattcasey commented

It is not obvious that both Core and Boost CSS need to be on. I was worried they might interfere somehow, for instance. There should be some warning or explanation, as none of the Boost settings tutorials mentioned this. I think this is why I'm getting css 'page not found' errors in my log and hope it fixes the issue for me!

AlexisWilke’s picture

AlexisWilke commented
Status: Closed (fixed) » Active

@mattwad,

I did for me. Did not have a problem since then. I'll mark this as active again.

See point #22(1)b

Thank you.
Alexis

AlexisWilke’s picture

AlexisWilke commented
Issue tags: -Release blocker

Removing the tag.