I have a production site, that's living behind a http auth password. Earlier today I notice *some* css files were not loading some pages were entirely or partially unstyled. For instance the home page was entirely unstyled, whilst on admin pages, the main page content was styled fine, however the sidebar menu provided by the admin module was unstyled.
Trying to load the CSS files gave a 404.
I was wondering whether this is because the site is at some point trying to access itself using the domain name provided (I have not entered a value in the "IP ADDRESS TO SEND ALL ASYNCHRONOUS REQUESTS TO:" field) but is not taking into account the http auth password? Or is that not how this module functions, and I should be looking elsewhere for the cure to my not-generating CSS files?
Thanks!
Comment | File | Size | Author |
---|---|---|---|
#15 | advagg-1668954-14-basic-auth.patch | 3.77 KB | mikeytown2 |
#12 | advagg-1668954-12-basic-auth.patch | 2.22 KB | mikeytown2 |
#3 | advagg-1668954-2-pass-basic-auth-in-status-report-test.patch | 820 bytes | mikeytown2 |
Comments
Comment #1
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedit gives the following status on the status page:
Adv CSS/JS Agg - gzip Gzip is failing for css files.
The web servers configuration will need to be adjusted. In most cases make sure that the webroots .htaccess file still contains this section "Rules to correctly serve gzip compressed CSS and JS files". Certain default web server configurations (nginx) do not gzip HTTP/1.0 requests. Raw request info:
is there anyway to allow for http auth and the use of advagg?
Comment #3
mikeytown2 CreditAttribution: mikeytown2 commentedBasic auth will get set for testing on the status report page now.
Comment #5
Ollie222 CreditAttribution: Ollie222 commentedI think I've come across this issue on a site I'm working on. It's behind a http auth and it looks like advagg is running correctly for css and js however the status page gives the following message.
I'm running Drupal 7.35 and AdvAgg 7.x-2.7+147-dev which I think includes the patch you posted in #3.
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedIf everything is working correctly just add
$conf['advagg_skip_404_check'] = TRUE;
to your settings.php file and the error msg will go away.Comment #7
Ollie222 CreditAttribution: Ollie222 commentedThanks for the quick reply.
I believe advagg is working, when activated it serves the specified number of aggregated css and jss files.
Adding your config setting does suppress the errors in the status report.
There is also a warning that appears in the status report reagrding gzip compression not working. The error again only appears if the site is password protected and I think the served files are being compressed (pagespeed doesn't moan about them not being) but any advice on how I can check this would be appreciated.
The warning that appears is
Comment #8
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedis there a way to pass the http auth user/password to advagg?
Comment #9
Ollie222 CreditAttribution: Ollie222 commentedI think if you have the latest dev version or the patch in #3 then the code in that patch allows for that by setting the variables shield_user and shield_pass or if those are not set then it uses $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] .
While the status page looks to have a few issues the main code looks to work, in my case at least.
Comment #10
mikeytown2 CreditAttribution: mikeytown2 commentedLooks like I need to provide better feedback on a 401 on the status report page; with the option of a settings.php override.
Comment #11
Ollie222 CreditAttribution: Ollie222 commentedIt would be useful if possible.
We often use password protection for beta sites to stop people and search engines seeing them before they're ready and I imagine we're not alone.
Thanks for the quick support and the great module.
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commentedCan you test this and see if by following the directions things work?
Comment #14
Ollie222 CreditAttribution: Ollie222 commentedFor some reason your patch in #12 fails to apply to the dev version of Advagg that I have here but I've applied it manually.
I believe prior to PHP 5.5 (I'm testing this on 5.3) the function empty can't have a function as a value, only a variable. Using a function it returns the error 'Can't use function return value in write context'.
Changing
elseif(!empty(variable_get('shield_user', ADVAGG_AUTH_BASIC_USER))){
to
elseif (variable_get('advagg_auth_basic_user', ADVAGG_AUTH_BASIC_USER) != '') {
stops this error.
After this the normal error messages still appear in status report.
Changing
elseif ($request->code != 401) {
to
elseif ($request->code == 401) {
makes the new message appear in the status report.
If I set $conf['advagg_auth_basic_user'] and $conf['advagg_auth_basic_pass'] correctly nothing changes and the new message to set the user and password still appear in the status report.
I've not looked at the next bit of code in great detail but if I understand it correctly then the status report calls a css and js url such as
/sites/default/files/advagg_css/css__1427795896.css
/sites/default/files/advagg_js/js__1427795896.js
in the function advagg_install_url_mod.
The part that sets the username and password looks to be bypassed completely because $mod_url is false when this function is called.
As mentioned I've not looked any further yet but if you want me to test anything else then please let me know.
Comment #15
mikeytown2 CreditAttribution: mikeytown2 commentedThanks for the feedback! New patch for you to test.
Comment #17
mikeytown2 CreditAttribution: mikeytown2 commentedComment #20
Ollie222 CreditAttribution: Ollie222 commentedI've just pulled down a fresh copy of the latest dev version and the patch in #15 applied to it cleanly.
Both of the css and js error and also the css compression warning on the status report page have now gone and when I look at the files being served when visiting a webpage they are aggregated.
It works for me without me having to set the username and password in the settings file, presumably it's now using the values supplied by the browser.
So all in all it's looking good to me.
The only issue I have now is that I'm using an Omega 3 based theme and sometimes the desktop css is not rendering correctly on all pages (works fine 90% of the time) but I don't believe this is related to this issue and I'll raise it as a separate post if I can't fix it.
Thanks for your quick updates on this issue they're much appreciated.
Comment #21
mikeytown2 CreditAttribution: mikeytown2 commentedPatch has been committed.
Comment #24
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedWhere is the fieldset to add the http user/password or is it just a config variable?
Comment #25
mikeytown2 CreditAttribution: mikeytown2 commentedJust a conf variable. You can also manually call variable_set.