If this page doesn't help, please post a question on our Google group.
See UriRewriting.
This is usually due to an unusual server setup. You can see the cause of 400 responses using FirePHP (See Debugging).
Some server setups will refuse to populate very long $_GET params. Use groups to shorten the URLs.
PCRE (which provides regular expressions) commonly crashes PHP and this is nearly impossible to solve in PHP code. Things to try:
- Raise Apache's ThreadStackSize
- In php.ini raise
pcre.backtrack_limitandpcre.recursion_limitto 1000000. These will allow processing longer strings, but also require a larger stack size. - Use YUICompressor instead of PHP-based CSS compressors
Short answer: use Minify 2.1.4+, use a pre-compressed version of your file, and rename it *.min.js or *-min.js. By default Minify won't try to minify these files (but will still gzip them). The Compressor Rater is handy for compressing files individually.
If the error is in your code, enable debug mode while debugging your code in Firebug or your favorite browser's Javascript debugger. This will insert comments to allow you to keep track of the individual source locations in the combined file.
If you have Java on your web host, you can use the wrapper for YUI Compressor instead of JSMin. This thread shows how a user has done this.
If the filename ends with -min.js or .min.js, Minify will assume the file is already compressed and just combine it with any other files.
Scriptaculous 1.8.2 (and probably all 1.x) has an autoloader script that requires files to be in a particular place on disk. To serve Scriptaculous modules with Minify, just serve prototype.js and the individual support files (e.g. dragdrop.js, effects.js) and the library should work fine. E.g.:
<script src="/min/f=scriptaculous/lib/prototype.js" type="text/javascript"></script>
<script src="/min/b=scriptaculous/src&f=effects.js,dragdrop.js" type="text/javascript"></script>
<script type="text/javascript">
/* DragDrop and Effects modules can be used here. */
</script>If you upload files using Coda or Transmit or from a Windows PC to a non-Windows server, your new files may end up with the wrong mtime (timestamp) on the server, confusing the cache system.
Setting the $min_uploaderHoursBehind option in config.php can compensate for this.
WinSCP has a Daylight Saving Time option that can prevent this issue.
This can also occur if your files are changed, and the mtime is set in the past (e.g. via a git checkout operation). If so you'll have to touch the changed files or use some other method to make the mtime current.
Generally changes aren't seen because a) the browser is refusing to send a new request, or b) the server doesn't recognize that your source files have been modified after the server cache was created.
First, place the Minify URL directly in the address bar and refresh.
If a change is not seen, verify that the server cache file is being updated.
If you'd like to temporarily disable the cache without using debug mode, place these settings at the end of config.php:
// disable server caching
$min_cachePath = null;
// prevent client caching
$min_serveOptions['maxAge'] = 0;
$min_serveOptions['lastModifiedTime'] = $_SERVER['REQUEST_TIME'];Don't do this on a production server! Minify will have to combine, minify, and gzencode on every request.
Please use UTF-8. The string processing may work on encodings like Windows-1251 but will certainly fail on radically different ones like UTF-16.
If you consistently use a different encoding, in config.php set $min_serveOptions['contentTypeCharset'] to this encoding to send it in the Content-Type header.
Otherwise, set it to false to remove it altogether. You can still, in CSS, use the @charset directive to tell the browser the encoding, but (a) it must appear first and (b) shouldn't appear later in the output (and Minify won't enforce this).
Moral? To minimize problems, use UTF-8 and remove any @charset directives from your CSS.
If you combine CSS files, @import declarations can appear after CSS rules, invalidating the stylesheet. As of version 2.1.2, if Minify detects this, it will prepend a warning to the output CSS file. To resolve this, you can either move your @import statements within your files, or enable the option 'bubbleCssImports'.
This issue was resolved in version 2.1.2.
Debug mode adds line numbers in comments. Unfortunately, in versions <= 2.1.1, if the source file had a string or regex containing (what looks like) a C-style comment token, the algorithm was confused and the injected comments caused a syntax error.
This issue was resolved in version 2.1.2.
In rare instances the JSMin algorithm in versions <= 2.1.1 could be confused by regexes in certain contexts and throw an exception. The workaround was to simply wrap the expression in parenthesis. E.g.
// in 2.1.1 and previous
return /'/; // JSMin throws error
return (/'/); // no errorWhat you're seeing is a mismatch between the content encoding the browser expects and what it receives.
The usual problem is that a global PHP or web server configuration is causing the output of PHP scripts to be automatically gzipped. Since Minify already outputs gzipped content, the browser receives "double encoded" content which it interprets as noise. The Builder app in 2.1.4 sometimes can tell you which component is causing the auto-encoding.
Use Minify 2.1.4+. Before there was a setting to adjust the maximum allowed.
This may also appear as "Virtual Directory does not allow contents to be listed". Minify requires that the URI /min/ (a request for a directory listing) result in the execution of /min/index.php. On Apache, you would make sure index.php is listed in the DirectoryIndex directive. IIS calls this the Default Document.
The test_environment.php unit test makes a few local HTTP requests to sniff for zlib.output_compression and other auto-encoding behavior, which may break Minify's output. This warning will appear if allow_url_fopen is disabled in php.ini, but does not necessarily mean there is a problem.
If Minify seems to work fine, ignore the warning. If Minify produces garbled output, enable allow_url_fopen in php.ini and re-run the tests. The tests may be able to tell you if PHP or your server is automatically encoding output.
Unless you need it in other scripts, disable allow_url_fopen once the issue is resolved. Minify does not need it.