For the first time, I've tried turning on CSS and JS caching. My immediate and DESPERATE problem is that everyone (even anonymous visitors) is now totally locked out of my site, so I can't get back in to turn it off again.
I can use phpmyadmin, what fields do I need to change, please? If no answers, I have backups, but they're several days old, so I'd prefer to reset the caching.
After I get going again, I'll be looking into the cause, advice welcome. The symptom is that I get "zero length reply" and the url has changed from www.example.com to www.example.com.alias. Turning on caching has created a sites/default/files/css directory, with owner 'web' (the webserver) and group 'me' and permissions 775. There are no files in this directory.
Theme is standard Garland.
This is hosted on nearlyfreespeech.net, if you're curious about the hosting provider (and I'm very happy with them).
If I can get an answer to this, would http://drupal.org/node/288488 be the right place to put the info for others with this problem, or is there a better place?
Comments
I've seen this happen with
I've seen this happen with downloads set to private instead of public, but this may not be your case.
Apart from that, you could reset css/javascript caching in the database.
The quick and dirty solution
AT YOUR OWN PERIL
so please recreate and test in test first
make a backup of your database, etc, etc.
change the following in the 'variable' table
NAME Value
preprocess_css s:1:"0";
preprocess_js s:1:"0";
If you don't know what I am talking about, Just do a restore.
Hope this helps. Good Luck
BobbyMods
Thanks Bobby. I'm pretty
Thanks Bobby. I'm pretty sure downloads are set to public, BICBW. That's how I want them, anyhow, though I've not got any downloads on the site yet.
I didn't know what you were talking about! :) But it was too interesting to pass up! That's great, I had no idea the variables were stored in... hey, what a good name for it... the 'variable' table. Lots of good stuff there. I've changed both of those, hasn't done me any good. Even tried changing the maintenance mode variable as well.
I'm now hacking the core files, commenting out chunks and adding 'print'. Will report if I make progress.
Then your problems may not be
Then your problems may not be related to that change, If you are the only one working on that site, revert your other changes one by one.
The problem may be a previous change that is seen with this change because to enable css/javascript cache, some caches had to be cleared and rebuilt.
A test environment is highly recommended, where you can change at will, without crashing your production site, this is a production site right?
Hacking core is a bad idea.
Good Luck none the less.
BobbyMods
I'm the only one, and there
I'm the only one, and there were no other changes today. I may try deleting the newly created css directory that I believe aggregation created, though for the moment I'm inclined to just dig into the causes rather than modify further.
Yes, it's a 'production' site, it's live, but it's a vanity site. Apart from crawlers (aka bots) and crawlers (aka my sycophantic friends!) the site probably gets 2 visitors a month, so it's not a big deal. :)
Sure, no hack core. But this is hacking it to debug -- afterwards I'll overwrite with the originals, no sweat.
But the warnings are a good idea, else somebody with more to lose might swing by here and pick up some bad habits!
:) Good Luck.
:) Good Luck.
BobbyMods
I tried deleting the newly
I tried deleting the newly created (and empty) /sites/default/files/css directory, but that gave no change. And I diff'd my .htaccess against the standard 6.9 in case I'd made a change I'd forgotten... just 2 lines:
RewriteRule ^(.*)/index\.htm$ /$1 [R=301,L]RewriteRule ^(.*)\.htm$ /$1 [R=301,L]
which I've had in there for weeks, so they're not it. The only other slightly unusual thing about my site is that I have a symbolic link from /files to /sites/default/files. OK, time to unholster the .45 and blow the site away.
Coding common.inc
in includes/common.inc find the following function "function drupal_get_css", comment the line .
// $preprocess_css = variable_get('preprocess_css', FALSE);
and add the following line right above it.
$preprocess_css = FALSE;
You are forcing the FALSE value for CSS Agreggator.
Save it.
Reolad the Site , it should be back to normal.
Go to Performance Settings and Turn CSS Aggregator OFF. Save it.
Go back to the code and bring common.inc back to the original state.
You are back.
Cms Adminstrator
Working at @viva_rio
www.leomangione.com.br
Twitter : @leomangione
Not so hard as that
Disable javascript and CSS styles in your browser. Fix problem. Re-enable.
Thanks Yelvington. I've
Thanks Yelvington. I've disabled JS and I'm in the middle of figuring out how to disable CSS. Though I'm not optimistic. My gut feeling is that the PHP on the server is generating a redirect to www.example.com.alias, so I don't see how changes in the browser will affect this. But I'll keep an open mind.
The url rewriting is what
The url rewriting is what made me look at the hard way, ...but this is IT, try it anyway. Rewrites can be done in javascript.
disable css in ff: View-->Page style select 'no style'.
in ie
Tools>>Internet Options
Then click on Accessibility
Finally, in Formatting check each option off to ignore font styles and colors.
(if it still works in that way)
BobbyMods
I've downloaded the Firefox
I've downloaded the Firefox web developer plug-in (thanks for stimulating me to find and try that). Turned off JS and CSS. No change though, but I don't think that's surprising.
The url rewriting might even
The url rewriting might even be comming from outside of drupal, changed .htaccess, changed domain/sub-domain settings. Or even changed contents in the sites folder / settings file.
Hope to hear how you solved this one soon.
BobbyMods
Thanks for your interest
Thanks for your interest Bobby. I've not been on it full-time this evening, but during what time I've had I've not got very far. Been doing various (f)printf's in index.php and in theme.inc and commenting out chunks, but still puzzled. It'll be several days before I can spend another chunk of time on it.
I may give up and just blat in a fresh 6.10 and start over. I'd been meaning to upgrade 6.9 some time anyhow! Though not this drastically!
Same problem with development site - but fixed!
When I enabled CSS and JS cache on my localhost devel site 6.13 with WAMP, it completely broke! I couldn't view any content pages or admin pages. The site simply did not work at all. Not surprising since I am designed a theme from scratch.
1) I did what bobby said above with changing the '1' to a '0' in the pre_process_css and pre_process_js by going into the variables table through phpmyadmin.
2) In phpmyadmin, I clicked on the little trash can icon labeled 'empty' and it asks if you want to truncate the table, click OK. I did that for these tables:
cache_block
cache_content
cache_filter
cache_form
cache_menu
cache_page
cache_update
I went to localhost in IE8 and everything is back to normal! You may need to refresh the page one or two times if it doesn't come up immediately, but that's what worked for me in this situation.
Good one!
That hint saved my day! Thanks a lot.
Edit: This was supposed to appear below comment #1962958.
Drupal 7 compression fix
I added this line to my settings.php file and it fixed my error!
I have only used it for Drupal 7
$conf = array(
'cache' => '0',
'preprocess_css' => '0',
'preprocess_js' => '0',
'block_cache' => '0',
'page_compression' => '0',
);