Hey Stephen,
I was having the exact same problems with HTTP 400 Bad Request for both CSS and Javascript; tried your PHP script and there indeed is something squiffy going on with DOCUMENT_ROOT on my live server (was working great on the testing server).
For some reason DOCUMENT_ROOT on my server is ‘/var/www’; any ideas how to get SL Combinator working in this instance? I’m willing to hack the code, but would appreciate any pointers about what general areas will need attention.
Thanks!
Hi Ian,
For some reason DOCUMENT_ROOT on my server is ‘/var/www’; any ideas how to get SL Combinator working in this instance? I’m willing to hack the code, but would appreciate any pointers about what general areas will need attention.
Minify, which is used for all the donkey work, contains a config file to help with DOCUMENT_ROOT related woes.
I removed a lot of the extraneous stuff, pending the (someday) implementation of an extension settings screen, so you’ll need to add the following code (taken from the default config file) yourself.
/**
* Leave an empty string to use PHP's $_SERVER['DOCUMENT_ROOT'].
*
* On some servers, this value may be misconfigured or missing. If so, set this
* to your full document root path with no trailing slash.
* E.g. '/home/accountname/public_html' or 'c:\\xampp\\htdocs'
*
* If /min/ is directly inside your document root, just uncomment the
* second line. The third line might work on some Apache servers.
*/
$min_documentRoot = '';
//$min_documentRoot = substr(__FILE__, 0, strlen(__FILE__) - 15);
//$min_documentRoot = $_SERVER['SUBDOMAIN_DOCUMENT_ROOT'];
Just add the above code to /min/config.php, anywhere before the ini_set line, at the end of the file, and edit as required (hopefully the inline comments provide sufficient instruction).
Let me know how you get on.
Cheers, Stephen
Unfortunately, setting the document root via the Minify config option didn’t change a thing; I’m getting an “HTTP Bad Request” no matter what I try. Here’s what I added to the config file:
$min_documentRoot = '/mnt/target02/361016/388905/www.domain.com/web/content/utils/min';
This is the correct full server path to the min folder, and just in case I tested ‘/utils/min’, which of course didn’t work.
I’m attempting to access this URL (which was generated without a problem by the SL Combinator plugin):
http://www.domain.com/utils/min/?f=css/screen.css
I also tried ?f=/css/screen.css
just in case, but no love either way. I’m not sure where the problem might be; any ideas where to look?
Everything seems to be working fine except 1 error that shows up in my error console (in Firefox):
Error: syntax error
Source file: http://www.domain.com/scripts/utils/?f=http://www.domain.com/scripts/javascript/jwplayer/swfobject.js,http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js,http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.1/jquery-ui.min.js&debug=1 Line: 1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
When I remove the sl-combinator code around the javascript files, I don’t get this error. Is this a SL Combinator issue or minify issue?
Hello all,
Apologies for the delay in responding, I seemed to have missed notification of a few messages here.
@Beckism: are you using some .htaccess rules to remove index.php perchance? I ran into a problem with this the other day, and updated the extension accordingly (latest version here).
In short, if you can access:
http://www.domain.com/utils/min/index.php?f=css/screen.css
…but cannot access:
http://www.domain.com/utils/min/?f=css/screen.css
…the latest version should solve your problem.
@D. Shun-Luoi Fong: you can only combine and compress local files, using absolute or relative paths.
The example you gave won’t work because you’re attempting to include remote files (the Google-hosted jQuery libraries). The local files should also be specified using absolute or relative paths, as opposed to the full URL.
There are some examples on the documentation page.
@Brian M: glad you like it 😊
Cheers, Stephen
Fortunately, the server was updated to properly support DOCUMENT_ROOT, and for some reason that solved my problems.
Thinking about it, the server that had problems with this plugin and removing index.php doesn’t properly support DOCUMENT_ROOT either… well, as long as it’s working properly for you now, that’s the main thing.
If you have any more problems, just let me know.
Cheers, Stephen
David,
I tried this on a site that I am working on and it just disabled the JS. One page using jquery//jquery.innerfade and styleswitch.
If you’re running into problems when combining and compressing the minified version of jQuery (or any other JS library), it might be worth trying it out with the non-minified version, to see if it makes any difference.
That said, the most likely cause is a bug in the JavaScript, as all the plugin does is remove whitespace, and combine the files. Have you tried using the plugin with some simpler JS files, to see if that works?
As a first step in identifying the cause of the problem, I’d suggest loading up the page and checking for JS errors using Firebug.
Let me know how you get on.
Cheers, Stephen
Hi Stephen,
I’ve used SL Combinator on a recent site and all appeared to be well. However, I’ve noticed that in Safari quite a few styles are not being processed (or are otherwise being mangled). Just wondered if you, or anyone else, had had a similar problem?
I can post screenshots of before and after but I guess it won’t make much difference? Certainly some styles are being parsed properly, but others from the same stylesheet aren’t.
Not a problem - I can leave these stylesheets uncompressed - but interested if others have had similar issues? It does only seem to affect Safari in this case - all other browsers I’ve tested are fine.
Dave
Hi Dave,
I’ve never encountered this problem, or been contacted by somebody who has.
The plugin uses minify for all the heavy lifting, and I’m wondering if you problem relates to this minify bug.
It might be worth removing the @charset declaration from the start of the CSS file(s), and seeing if that makes a difference.
Hope that helps, Stephen
P.S. If you can point me to the exact styles that are being mangled, I’ll see if I can work out the root cause.
Stephen - removing the @charset “utf-8”; declaration from the CSS files did indeed solve the problem. I’m a very happy bunny, thank you.
It’s testament to how great this extension is that I can turn it on and off with one parameter change 😊
Hope this post helps someone else with a similar issue in future.
Cheers, Dave
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.