Closed (fixed)
Project:
Advanced CSS/JS Aggregation
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
20 Apr 2011 at 05:36 UTC
Updated:
16 May 2011 at 20:51 UTC
Jump to comment: Most recent file
Comments
Comment #1
guruslot commentedThe same effect with pressflow. Everything is set up according documentation.
Comment #2
rjbrown99 commentedI'm not quite clear on async mode. My status page (Pressflow+CDN) says "Asynchronous mode: Set to FALSE." But then it continues "Check your CDN settings; request is not coming back when routed through the CDN."
What exactly does that mean?
Comment #3
mikeytown2 commented@rjbrown99
Means origin pull is not hitting the missing handler. Code used to check CDN route
http://drupalcode.org/project/advagg.git/blob/refs/heads/6.x-1.x:/advagg...
I should set an html comment in the fast404 output as well; the CDN might be stripping some of the headers when forwarded.
Comment #4
rjbrown99 commentedWell, in my case I have two levels of upstream caching. It goes like this:
CDN -> Varnish -> Apache/Drupal
Could it be that the check is failing because it hits varnish on the way back in?
Comment #5
mikeytown2 commentedThats why I have the mt_rand() call in there. It should be unique enough; I could add in a call to time() as well. My guess is stripped headers; I need to have a html comment in the advagg_fast404() function and check for that html comment OR the header.
Comment #6
rjbrown99 commentedYea perhaps the CDN and/or Varnish is removing headers - I haven't looked into it. But it's certainly possible. FWIW my CDN is Amazon CloudFront.
Comment #7
mikeytown2 commentedmind testing this patch?
Comment #8
spacereactor commented#7 patch doesn't work for me, running openatrium and nginx.
Comment #9
mikeytown2 commentedcommitted this patch.
Flush your menu cache after applying it
Comment #10
mikeytown2 commentedComment #11
spacereactor commentedtest with the #9 patch, it work. sweet. THANK!! The 6.x-1.x-dev 2011-Apr-29 doesn't include this patch, you have to manually patch this.
Comment #12
_-. commentedafter applying the patch, my status report:
Adv CSS/JS Agg - Asynchronous Mode Set to FALSE.
Check to see if you have fast 404s, if so create an exception for this module. The readme file explains what needs to be changed. You can try flushing the menu cache as well.
AdvAgg JS Compress - Callback The callback for testing if a JS file is compressible is not working.
As a result if jsmin+ encounters a file that it cannot compress, it will kill that PHP process.
I've not installed fast 404s
I've flushed all caches
The async option is still not selectable
The JS Compress-Callback error is new ...
Comment #13
mikeytown2 commented@dev001
what happens when you go to
sites/default/files/advagg_css/missing.csswhen logged out?Comment #14
_-. commentedignore this. see cmt#16
Comment #15
mikeytown2 commentedWhat's this doing in here?
YOU need to fix the fatal error ASAP
Comment #16
_-. commentedComment #17
_-. commentedComment #18
mikeytown2 commentedThis patch will fix the notices; but it won't fix the issue your having. If you have more advagg notices/warnings send then along :)
Mind running this code and reporting the output of it between code tags?
Comment #19
_-. commented(@ a better provisioned site ...)
sites/all/modules/advagg
patch -p1 < ../advagg-1132878-18.patch
patching file advagg.install
patching file advagg_js_cdn/advagg_js_cdn.module
drush pm-list | grep -i advagg
...
Advanced CSS/JS Aggregation AdvAgg Bundler (advagg_bundler) Module Enabled 6.x-1.x-dev
Advanced CSS/JS Aggregation AdvAgg CDN Javascript (advagg_js_cdn) Module Enabled 6.x-1.x-dev
Advanced CSS/JS Aggregation AdvAgg Compress CSS (advagg_css_compress) Module Enabled 6.x-1.x-dev
Advanced CSS/JS Aggregation AdvAgg Compress Javascript (advagg_js_compress) Module Enabled 6.x-1.x-dev
Advanced CSS/JS Aggregation Advanced CSS/JS Aggregation (advagg) Module Enabled 6.x-1.x-dev
Command dispatch complete [notice]
...
drush cc all
service apache2-custom restart
nav to .../test.php. output:
Comment #20
_-. commentedfyi, after patching, still @, e.g., http://test.loc/user/1,
Notice: Use of undefined constant JQUERY_UI_PATH - assumed 'JQUERY_UI_PATH' in advagg_get_jquery_ui_filename() (line 61 of /srv/www/pf6/sites/all/modules/advagg/advagg_js_cdn/advagg_js_cdn.module).
Notice: Use of undefined constant JQUERY_UI_PATH - assumed 'JQUERY_UI_PATH' in advagg_get_jquery_ui_filename() (line 61 of /srv/www/pf6/sites/all/modules/advagg/advagg_js_cdn/advagg_js_cdn.module).
Comment #21
mikeytown2 commentedTrying a different way to get rid of the notice; patch is against dev.
try this code as well; forgot the global base_path
Comment #22
_-. commenteddrush dl advagg-6.x-1.x-dev
cd advagg
patch -p1 < ../advagg-1132878-21.patch
no more 'notices' seen. that worked, thx.
test code -->
Comment #23
mikeytown2 commentedI've committed the above patch... now to figure out why PHP isn't connecting to it's self. Let's try it without the IP address
Comment #24
_-. commentedComment #25
mikeytown2 commentedhmmm interesting problem... more core for you to run. If your wondering fsockopen is throwing the -111 error when trying to connect to 127.0.0.1
Comment #26
_-. commentedatm,
Fatal error: Cannot use object of type stdClass as array in /srv/www/pf6/sites/test.loc/themes/test_fusion/page.tpl.php on line 85
where, your snippet pasted into 'page.tpl.php' @,
Comment #27
mikeytown2 commentedI edited the post a couple of minutes after initially posting; get the code again :)
Comment #28
rjbrown99 commentedYou guys need to get on irc at this point - it would make things easier :)
Comment #29
_-. commentedthx; re-got the code.
Comment #30
mikeytown2 commentedapply this patch; set "IP Address to send all asynchronous requests to" on the admin/settings/advagg/config page to -1 and make sure you have an Nginx rule in place like this http://drupal.org/node/1116618#comment-4321724
Comment #31
_-. commentedre: the nginx 'location ~* advagg_(?:css|js)/ { ...' stanza, iiuc, that makes sense if nginx is actually doing the serving.
in my case, nginx front-ends, passes through varnish, and apache/drupal serves up. e.g., my nginx conf includes,
i'm hardly clear here, but wouldn't the referenced stanza, or equivalent, need to go -- in this scenario -- "in" the apache config?
Comment #32
mikeytown2 commentedunless you have some very aggressive htaccess settings that are not the default, apache doesn't need anything to be done to it, in order to make it work. Most Nginx setups are fairly aggressive on the other hand and have an exception for imagecache; thus you then need to create an exception for advagg as well.
Comment #33
mikeytown2 commentedgoing to commit this patch as it will allow for a work around with a similar issue #1142990: Why SERVER_ADDR is used instead of HTTP_HOST to build $url in function advagg_css_js_file_builder() ?
Comment #34
mikeytown2 commentedgoing to mark this as fixed as this is most likely a server configuration issue now
Comment #35
mikeytown2 commented