levitation / minify Goto Github PK

What version of Minify are you using?
2.0.1

PHP version?
5.2.5

What steps will reproduce the problem?
1. pcre.backtrack_limit set in the php.ini to the default (100,000 I think).
2. A single line in the HTML needs to be too long (148426 characters in my
case).
3. Minify the HTML.


What is the expected output?
Some HTML.

What do you see instead?
Empty string.

Please provide any additional information below.
I think this is very similar to Issue 41 (too many backtracks). The Regular
Expression in this case is:
$html = preg_replace('/>(\\S[\\s\\S]*?)?\\s+</', ">$1 <", $html);

Although my original html did not have any long lines, the long line was
created by minify.

This time though I think I have 2 solutions, the first is to fix the
expression. Here is my new expression:
$html = preg_replace('/>(\\S[\\s\\S]*?)?\\s+</U', ">$1 <", $html);
Note that the only change is the /U modifier. I tested this new expression
and it looks like it works to me with a 128.9 kB file.

My second solution is as fall-back for failing regular expressions. As
preg_replace returns an empty string ("") when it fails, this should be
caught. Each regular expression should be checked like the following:

$newhtml = preg_replace('/>(\\S[\\s\\S]*?)?\\s+</U', ">$1 <", $html);
if ($newhtml != ""){
    $html = $newhtml;
}

What steps will reproduce the problem?
1. Use XAMPP as your server on a windows machine


What is the expected output? What do you see instead?
Paths are created for CSS urls with the rewriteCSSUrls function... but on a
windows machine using XAMPP, the forward slashes are created as
backslashes, this not correctly rendering paths readable via CSS.

What version of the product are you using? On what operating system?
Windows Vista running XAMPP

Please provide any additional information below.
That's it :)

Would it be possible for minify to optionally cache gzipped CSS and
Javascript files?

First, most shared hosts do not allow the use of on-the-fly compression
like mod_deflated and mod_gzip.

Second, isn't it more efficient for minify to gzip each file once, store on
disk, and serve from disk rather than have Apache compress files
on-the-fly, once per request?

Thanks.

I read the FAQ on gzip, but frequently mod_gzip/deflate is not an option 
to users, and those modules can cause problems with older versions of IE 
(as recent as 6) and other PHP scripts that deal with headers. It would be 
great to have documentation on a real, working implementation where Minify 
output is compressed.

I rather think this can be done simply and effeciently in PHP via the 
common Zlib extension. See this script (not mine) for a working (though 
spaghetti code) implementation:
http://rakaz.nl/projects/combine/combine.phps

Another problem with leaving this to mod_gzip is that the server would 
have to recompress for every user. For sites with high concurrent users 
this could add up. PHP can cache the compressed version and stream it just 
like the uncompressed.

Steve

What version of Minify are you using? PHP version?
2.0.1

What steps will reproduce the problem?
1. pcre.backtrack_limit set in the php.ini to the default (100,000 I think).
2. A single line in the HTML needs to be longer than 50773 characters.
3. Minify the HTML.

What is the expected output?
Some HTML.

What do you see instead?
Empty string.

Please provide any additional information below.

The problem is caused by a long line (> 50773 characters) having too many
backtracks in a Regular Expression.

In Minify/HTML.php the problem line is:

$html = preg_replace('/^\\s*(.*?)\\s*$/m','$1', $html);

I think the .* is causing too many bracktracks. To solve this, I changed
this line to:

$html = preg_replace('/^\\s*([^\s]*?)\\s*$/m','$1', $html);

I am not to sure on what this line is trying to achieve, but this solved my
problem.

What version of the product are you using? On what operating system?
1.0.2

Please provide any additional information below.
i can not add some link params like media="print" ;(
$minifyCSS->addFile(array(
  'css/example.css',
  'css/monkeys.css',
  'http://example.com/foo/bar/baz.css'
));

I have the latest version of Minify (2.0), and am getting this run-time notice 
in my logs:

"Declaration of Cache_Lite_File::get() should be compatible with that of 
Cache_Lite::get() in 
Minify.php on line 291"

It's not a critical issue to fix, but fixing it would at least ensure the best 
interoperability and forward 
compatibility of the PHP 5 code.  Thanks!

When using the script on an ISS server, images are not displayed because
the path name is not reproduced properly ("\" instead of "/").

Inclusion of javascript files doesn't seem to work properly either. Files
are minified and included in the page but script won't be executed.

What steps will reproduce the problem?

1. Take 1.01 minify
2. there is function __construct AND minify for class minify

PHP claims following problem: "Redefining already defined constructor for
class Minify" (E_STRICT)

Solution: rename static function minify , for example minifyIt

What steps will reproduce the problem?
1. Delete the server cache and request a Minify URL
2. Change and SFTP upload one of the source files from a Windows PC in a 
earlier timezone
3. Re-request the Minify URL

Minify should notice that the new file has a later timestamp and overwrite 
it. Instead, the file is transfered to the server with mtime of 1 or more 
hours ago, so the cache file mtime appears later and so is considered 
stale. This should only occur if the server is 1 or more hours ahead, and 
the user tries to make changes more frequently than the time gap.

The quick workaround is to touch files after uploading them, but the 
eventual fix will probably be a Minify static var $uploaderHoursBehind = 0 
(default), and this will be added to the mtime of source files when 
checking lastModifiedTime for the sources. 

If multiple Windows users from different TZs must upload frequent changes, 
I don't know a solution other than to have them touch the files after 
upload.

Currently only the CSS minifier has a mechanism for leaving copyright
comments untouched. I'd prefer to remove this option from the CSS min and
create an easy way to leave arbitrary content (usually comments) unmodified.

Option 1: Give unrecognized file extensions an empty minifier by default.
The user would then move license/copyright comments to .txt files and add
them to the file lists. I like this because it actually simplifies/removes
 Minify code while making the task straightforward for the user.

Option 2: Have Minify_Javascript / Minify_Html sniff & strip out license
comments and add them back after using minification. Creates tons of
options and worries about how to determine which comments to keep, etc.

This also raises the issue: are licenses even necessary if the source files
(w/ license) are on the server (but not linked)? Would it be
better/acceptable to merge all client code licenses into a file and point
to it in a comment?

ecroyd pointed out the need for sanity checks on the output of 
preg_replace calls, which output empty strings on error.

ecroyd's suggestion in Issue 46 is simple enough for single operations.

In some cases later operations depend on this work having being done, so 
it might be better just to return the original content or skip a whole 
section of processing.

Worst case should be the user gets back the original content with an error 
in her PHP logs.

It would be great to see CSS Tidy used in place of regex to help compress
CSS further. It would also help safe guard against possible CSS errors.

http://csstidy.sourceforge.net/

A way to see the original js without minifying it, mainly for debugging/
developing purposes:

In the .htaccess, we need the QSA flag:

RewriteRule ^(.*\.(css|js))$ /minify.php?files=$1 [L,NC,QSA]

And in the minify.php, simply:

if (isset($_GET['debug'])) {
    echo $minify->combine(!($_GET['debug']));
} else {
    echo $minify->combine();
}

So http://www.example.com/js/blabla.js?debug=1 should return the original 
js, without minifying it.

Congrats for the software! It helps me a lot!
Victor

On at least one server tested, Minify 2.0.2b writes only zero-length 
files. Removing the LOCK_EX option from file_put_contents() fixed the 
issue, but I don't know why.

Both my test/prod are similar Apache/mod_php setups on Red Hat 5, but only 
the production had the issue.

What steps will reproduce the problem?
1. I use minmax.js (http://www.doxdesk.com/software/js/minmax.html) on my
site and minify.php to minify the js. But it does not seem to work with
this file. All my other css works fine.

What steps will reproduce the problem?
1. set alias to a directory
2. it does not work

What is the expected output? What do you see instead?
File not found

What version of the product are you using? On what operating system?
1.0.0

Please provide any additional information below.
I think a good thing is to define a array with some alias and there real
directorys so the code will work see minify.php line 445

Before a v2 release it'd be Really Nice to have a v2-based minify.php
script that behaved identically to v1. This would given current users a
simple upgrade path and (more importantly) give us a way to directly
compare speed between v1 and v2.

My hunch is, with more files involved, initial minification may be slightly
slower in v2, but 304 and serve-from-cache requests will be very close, if
not faster with all the lazy loading.

With the hot (again) topic of CSS variables, some simple text substitution 
would be trivial to implement in the CSS Minifier (or as a pre/post 
processor). This is something that should've been built into CSS tools a 
long time ago, but Minify can also do this work.

With V.1, I was able to hack my usage of minify a bit such that I could
pass it a list of files and it would echo the minified result out to the
command line. This no longer seems feasible (or at least is much harder) in V.2

All I want minify to do is accept a list of files, minify them, and return
the result. We have our own static server which takes care of all the fancy
encoding and header issues. Minify does not seem to work at all from the
command line however. Can this issue be addressed?

What version of Minify are you using?
2.0.1

PHP version?
5.2.5

What steps will reproduce the problem?
1. Minify HTML containing a TEXT AREA that has multiple empty lines.

What is the expected output?
The text inside the text area to be untouched by Minify. This text will
have a different meaning if Minified (just like the pre tag).

<textarea name="comment" id="comment" rows="6" class="maxwidth" cols="80">66666




1234567890</textarea>

What do you see instead?
Minify changes the contents of the text area tag and the empty lines are
incorrectly removed.

<textarea name="comment" id="comment" rows="6" class="maxwidth" cols="80">66666
1234567890</textarea>

Please provide any additional information below.
The TEXTAREA tag should be handled the same way as the PRE tag. You can
reuse the code in Minify/HTML.php, just make it handle PRE tags AND
TEXTAREA tags.

Now that Minify is useful as a library, it should ship with an 
implementation, like V1.x's minify.php, that can be dropped inside 
DOC_ROOT and quickly configured to get to work.

Goals
 * easy to configure cache folder / groups
 * easily limit source directories (any within DOC_ROOT by default)
 * disable base dir in V1 style urls by default
 * easy to disable V1 style urls altogether

File layout
 * front end: min/index.php
 * min/?f=js/file1.js,js/file2.js (like Version1)
 * min/?g=js (use Groups, if defined)
 * min/?b=js&f=file1.js,file2.js (allow a base dir)
 * main config: min/config.php
 * groups config: min/groupsConfig.php

Currently each string of whitespace is collapsed to a single space. 

This breaks strings (as content values or in attribute selectors) that may 
contain two or more consecutive spaces, and strings continued on the next 
line. E.g.:

foo[attr="two  spaces"] { content: "\"Really\" Anno\
ying"; }

becomes:

foo[attr="two spaces"]{content:"\"Really\" Anno\ ying"}

Parsing strings by the spec (then preserving them while the rest is 
minified) would be possible if you could reliably identify the starting 
position. I suppose =" and content: would be good places to look.

It might be easier to not rely on the initial whitespace collapse. There 
is a lot of ws stripping going on and the collapse may be redundant. It 
might be worth losing a few bytes of minification to never run into this 
issue.

As the URI-rewriting code in Version1 and Minify_CSS appears to be 
reliable (and setting it up manually is a pain), this should be the 
default behavior in Minify::serve().

Minifying CSS should "just work" out-of-the-box.

In Minify 2.0.1 when you use the server cache, which at the moment only has
Cache_Lite, you run into conflicts if you currently use Cache_Lite on your
site because you are trying to redefine Cache_Lite.

Solution:
I changed the class name from Cache_Lite to Cache_Lite_Minify to keep this
from happening.  Since the library provides a "custom" version of
Cache_Lite this is about the only way to get around this error if you use
Cache_Lite already.

Another solution could be only load up the minify Cache_Lite if an existing
Cache_Lite has not been defined.  I have not checked the minify Cache_Lite
against the latest Pear install of Cache_Lite so I am unsure if there are
any changes that would cause using a pear installed Cache_Lite to not work
properly.

With 

http://minify.googlecode.com/files/minify-2.0.1.tar.gz

on gentoo / gnome system!

Minify could use an abstract controller class that maps URLs to an array 
of file paths to be combined. 

This way the user could chose other ways to specify sets of files, like 
pre-defined groups, or by specifying particular directories that can be 
used, particular patterns that the file names must match, custom formats 
for the URLs (avoiding the need for mod_rewrite), etc. In this way, all 
the path resolution code could be moved to only controllers that need it.

URLs could be like:
/minify.php/js/jQuery,plugin.jQuery,myScript
or just
/minify.php/homePageJs

A problem with the current system is that the visitor has the ability to 
specify long sets of files in different orders that are of no use to the 
site, yet PHP still has to act on these requests, resolve paths, check 
file existence, combine, minimize, cache and serve these bogus files. Not 
exactly a DoS issue, I know.

With that in mind, I'd suggest that the default controller should force 
the user to define keys to groups of files that need combining. Or at 
least force the user to define allowable directories for certain types. In 
any case being able to eliminate relative path resolution would be great 
for security.

hash function exists(or disabled) error. mb. function_exists?

I have strange issues with minify and FCKEditor. FCK says it cant find some
objects and it doesnt load toolbars for textareas. 
Solution is use/copy file  fckeditor/editor/fckeditor.original.html instead
of fckeditor/editor/fckeditor.html. You also might have to remove 3 byte
utf BOM from beggining of that file 

It would be great if I could optionally hav minify just combine the files, 
but not perform and compression so that while the site is being developed, 
we dont need to change the link and script tags, but could still do 
debugging.

What steps will reproduce the problem?
1. Create a js file with this line: var i = 0, string = 'foo' + ++i;
2. Minify the file
3. The file is minified as: var i=0,string='foo'+++i;

This causes an "invalid increment operand" error

Thanks for a great tool!

What steps will reproduce the problem?
all methods of implementing it does not seem to work.

What is the expected output? What do you see instead?
while the first 2 just don't laod the css, the php implementation seems to
show detail as to why it does not work. Instead I get the following error,
it seems to not be able to find the file, i've tried everything, relative
path, absolute path(local and http) nothing seems to work.

Fatal error: Uncaught exception 'MinifyFileNotFoundException' with message
'File not found: css/style.css' in
/hsphere/local/home/clife/clublifeinto.com/v1/minify.php:452 Stack trace:
#0 [internal function]: Minify->resolveFilePath('css/style.css') #1

What version of the product are you using? On what operating system?
Linux web1.nozonenet.com 2.6.9-42.0.10.ELsmp #1 SMP Tue Feb 27 10:11:19 EST
2007 i686 i686 i386 GNU/Linux

Patch for css star hacks against rev 49

@see
http://groups.google.com/group/minify/browse_thread/thread/615dba5717e05910

What steps will reproduce the problem?
1. enable strict standards in PHP5
2. load up minify

The following warning message will be shown:
Strict Standards: Redefining already defined constructor for class Minify
in .../minify.php on line 212

What is the expected output? What do you see instead?
No output


What version of the product are you using? On what operating system?
1.0.1

Please provide any additional information below.
This can be simply avoided by not having a method name like the class, e.g.
simply renaming the method.

Extreme line lengths can cause problems in some systems and, if we 
converted all html/css/js files to Unix newlines, we could not only save 
bytes in some cases, but also substite "\n" for " " in some replacements 
without gaining bytes.

Oddly-formatted CSS comments are sometimes used as hacks, since certain
browsers don't parse them correctly. Such comments should be identified and
left in if possible.

http://www.quirksmode.org/css/csshacks.html

It's not weird to see PHP used inside js files, for global vars (defined 
in PHP), translations strings, and so on. 

Right now minify only reads the file as lines, append them, minify them 
and output them. For the PHP embedded in JS files we need to preprocess 
the JS file as a PHP file, before we minify and all the stuff.

For this, in the function "combine($minify = true)":

    foreach($this->files as $file) {
      if ($this->type === self::TYPE_CSS && MINIFY_REWRITE_CSS_URLS) {
        // Rewrite relative CSS URLs.
        $combined[] = self::rewriteCSSUrls(file_get_contents($file),
            dirname($file));
      } else if ($this->type === self::TYPE_JS) {
        ob_start();                    // Start output buffering
        include($file);                // Include the file
        $contents = ob_get_contents(); // Get the contents of the buffer
        ob_end_clean();                // End buffering and discard
        $combined[] = $contents;
      } else {
        $combined[] = file_get_contents($file);
      }
    }

Cheers,
Victor
http://beer2beer.com

Minify::serve() should still support conditional GETs when 'setExpires' is 
used. (requested by vadibart)

Some pages naturally elicit user refreshes (e.g. eBay bidding) and at 
least one major browser (IE7) will send a conditional GET when a standard 
refresh is used (F5 or the refresh button). In this case a 304 response, 
when appropriate, would definitely be desired. 

Considering some sites send Last-Modifieds with short max-ages, this would 
also support that. In fact, serve() should probably just have a 'maxAge' 
option and set Expires and Cache-Control: max-age based on that (instead 
of 'setExpires').

So we'll modify ConditionalGet.php and use it for every request. On the 
plus side the serve() code will end up cleaner.

Minify is a great tool, and it severed all of my needs, until I found out it 
didn't work with symlinks.
For the moment I have gone around the problem by extending the Minify class 
with my own, 
overridding the methods that causes issues, because I don't want to modify the 
Minify code if that 
is a feature that will be left out on a new update.

Afaik, there isn't any reason to why symlinks shouldn't be allowed, as they can 
be used directly from 
the webserver. If you need help fixing it, just let meg know, I'd be happy to 
help out on the issue.

The HTTP_* classes have test scripts in their directories. I'll move these
to /web/test/ so the entire "lib" tree is safe to place in DOCUMENT_ROOT
(in case someone does).

Minify should be able to parse @import directives in CSS files (and maybe 
JS?), dynamically add the necessary source files, and strip the @imports 
on output.

This is tricky because currently only the minifier functions see file 
contents and at that point the source list has already been build and 
checked for mtimes.

One solution is to extend Minify_Source to make it take a CSS file and 
internally maintain a "linearized" CSS file containing all the referenced 
style content (without imports), and Minify would see this as one file. It 
would also need to cache a list of the referenced filenames and use the 
max of their mtimes to determine if the linearized file needs to be 
rebuilt. That mtime max would be reported as the source's mtime.

Another problem will be relative URIs within @imported files that live in 
other directories. It would be simplest (for code reuse) to have the CSS 
linearizer rewrite the URIs, so the minifier won't have to.

What version of Minify are you using? PHP version? 2.0.1

What steps will reproduce the problem?
1. Clear browser cache
2. request JS or CSS files generated by Minify
3. note that there is no Last-Modified header on the file

What is the expected output? What do you see instead?
I'm expecting to see a "304 Not Modified" response when requesting the same
CSS or JS file in subsequent requests.  As background, in FF and IE at
least future requests will not include an If-Modified-Since header unless
there was a Last-Modified header included in a previous response.  As a
result my browser is requesting and downloading the JS/CSS files on every
page request.

Please provide any additional information below.
If this is not the intended behavior, I noticed that the constructor for
HTTP/ConditionalGet.php is returning before checking for the
'lastModifiedTime' array element in the $spec variable passed to it.  It's
the presence of this variable that will trigger the Last-Modified header. 
From what I can see this code simply never executes.  See snippet below.

        if (isset($spec['setExpires'])) {
            if (is_numeric($spec['setExpires'])) {
                $spec['setExpires'] = self::gmtDate($spec['setExpires']);
            }
            $this->_headers = array(
                'Cache-Control' => $scope
                ,'Expires' => $spec['setExpires']
            );
            $this->cacheIsValid = false;
            return;
        }
        if (isset($spec['lastModifiedTime'])) {
            // base both headers on time
            $this->_setLastModified($spec['lastModifiedTime']);
            $this->_setEtag($spec['lastModifiedTime'], $scope);

Memcache is an order of magnitude faster than file access.

Most systems using memcache use a singleton, and memecache doesn't like
having multiple simultaneous connections from a single process.  It may be
a good idea to turn the option on by setting a global var to a memcache object.

Minify should be capable of minifying (but not combining) HTML pages.

The JSMin library is hideously slow. It probably needs quite a bit of
optimization before Minify will be usable for JavaScript minification on a
high-traffic website.

Hi, I've encountered problems with jsmin when using extremely large files, (ie 
prototype, 
scriptaculous et al) in one compression. I've previously been using a simple 
sequence of 
preg_replaces to flatten the js into one line. It might not through exceptions 
for errors in the 
javascript and if the javascript was not written 100% correctly, ie ; after 
nearly everything then 
the compressed javascript will not work. however there is a significant speed 
improvement and it 
might be worth implementing. as an options instead of using jsmin.

to implement the hack modify the function 'minifyJS' to below

  protected static function minifyJS($js) {
     return self::compressCode($js);
  }

then add the following function

  protected static function compressCode($code)
  {
    // Remove multiline comment
    $code = preg_replace('/\/\*(?!-)[\x00-\xff]*?\*\//', '', $code);
    // Remove single line comment
    $code = preg_replace('/[^:]\/\/.*/', '', $code);
    // Remove extra spaces
    $code = preg_replace('/\s+/', ' ', $code);
    // Remove spaces that can be removed
    $code = preg_replace('/\s?([\{\};\=\(\)\/\+\*-])\s?/', '\\1', $code);
    return trim($code);
  }

This would be the opposite of the current must-revalidate model, and where 
usable, would eliminate a ton of needless HTTP requests.

In the HTML you append a build number to your minify URLs.

1. Minify responds with content, but also far-off Expires/max-age headers 
and headers to let all proxies know they can cache the URL for practically 
"forever".
2. Due to this, the browser uses cache and doesn't even request the file 
on later page requests.
3. When you change any of the combined files, you (or some automated 
mechanism) updates the build # in the minify URLs on the site.
4. The browser sees these as new files and requests them.
5. Go to 1.

If a browser requests an older build (say from a search engine cache 
page), you can send the current output, or a 404.

when loading a framework like scriptaculous.js its often used like this

<script type="text/javascript" src="/scriptaculous.js?load=effects"></script>

Upon doing this, with multiple JS files comma delimited, it seems to screw
up minify

What steps will reproduce the problem?
1. Simpify a css file with for instance url (chrome://myproject/skin/image.gif)

What is the expected output? What do you see instead?
The chrome protocol (and protocols other than http(s)) are handled as
relative paths and the output is something like:
/myproject/skin/chrome://myproject/skin/image.gif
instead of unchanged (since it is an absolute path):
chrome://myproject/skin/image.gif

What version of the product are you using? On what operating system?
minify 1.0.1 on Fedora.

Please provide any additional information below.
The resolveFilePath method should not only check for http and https schemes
but should check there is a protocol scheme at the beginning: ^.*://

In the Google Code description, the second paragraph, second to last
sentence would be more clear if it started "Unlike Yahoo Combo Builder,"
instead of "However,"

Also the warning has a typo: "Minify is designed for efficiency, but, for
very high traffic sites, Minify will serve files slower *than* your HTTPd
due to the CGI overhead of PHP. See the FAQ for more info."