Minify

[Pete]

ProcessWire2.+ Minify 1.0.3

This module helps you combine Javascript and CSS files into one, minified file to save on unnecessary HTTP requests and to compress files anywhere up to 80% (including already minified .js files).

To use it, extract the attached zip file into your /site/modules/ directory and check for new modules in the ProcessWire Admin area, then install the module.

Once installed, go to configure the module and, instead of this configuring anything for you, you can use the drop-down lists to build stylesheet and script code to place in your templates, grabbing a list of any stylesheets and scripts it finds in the /site/template/styles/ and /site/templates/scripts/ directories respectively.

It's more of a helper than anything else, but it should take the guesswork out of configuring Minify for your site.



Notes:

• This module contains a third-party library - Minify - which is subject to its own license (a copy is included in the attached zip file). I've left the module in-tact including its unit test files so there are more files than are necessary, but this will make it easier for me to upgrade the module if/when they release updates to that code.
• This module doesn't insert any code into your templates automatically - I think copying and pasting the code it currently outputs to the screen is more useful/configurable for more situations.
• It's worth using even if you only have one CSS or JS file as it will compress CSS files by about 80% and JS files by quite a lot too, plus since it handles caching on the server-side and does its own checks of the files it is serving (plus it's a dynamic URL), you can always be sure that it will serve the latest version of a CSS file (no more CTRL+F5 to show the new styles if your browser decides to cache it.
• You can change the /site/modules/Minify/min/config.php as you could if you were using Minify as a standalone script - tweak cache paths (default is your server's cache path) and other advanced settings here.

Updates:

• v0.0.2 - now produces code that includes paths derived by ProcessWire at run-time so paths will be fine on localhost and live servers, removing potential issues when pushing a site live.
• v1.0.0 - bumped this up to a major version number since there appear to be no issues with the initial versions to speak of. Also implemented yellowled's input field suggestion (looks much better and easier to select for copy and paste purposes) and turned off autoload at ryan's suggestion.
• v1.0.1 - now recusrively searches for files inside subfolders under the scripts and styles directories using PHP 5's built-in iterator classes
• v1.0.2 - pull request from teppo - https://github.com/Notanotherdotcom/Minify/pull/1
• v1.0.3 - updated Minify code to v2.1.7 which fixes a significant security flaw: https://groups.google.com/forum/#!msg/minify/cpN-ncKPFZE/kwYVpLMkfDwJ

You can download the module here.

[Marty Walker]

Can't wait to give this a try. I've been using Minify a lot recently.

Regards

Marty

[Michael Fillier]

It's dead simple to use, nice job. How difficult would it be to have the options saved to the db and made available as a variable? Then perhaps an "auto" checkbox that could be used in the theme like:

<?php if($minify->auto) {
echo $minify->files;
else {
?>
<!--Normal css and js references -->
<?php } ?>

Also, for the snippet, would it make more sense to include the path variables in the snippet, you must be using them while generating the snippet, but there will be path issues when working locally and then moving to production.

<script type="text/javascript" src="<?php echo $config->urls->siteModules; ?>Minify/min/b=<?php echo $config->urls->templates?>scripts&f=jquery-1.4.2.min.js,main.js"></script>

(I think this is a good idea, but $config->urls->templates includes a preceding slash, and is not loading the resource properly

[Pete]

Cheers

I was getting a headache last night trying to get the variables escaped well enough since they're inside a PHP variable inside a JS variable in the module code so didn't bother in my first version since they kept on messing each other up.

This is now fixed in version 0.0.2 (download from the original post above) where you can even view the horrible code that solved it

It would be a lot of extra code to implement your first idea though and, unless you actually have a pre-configured head.inc file that you drop into each project, this doesn't actually save you any time. Even then it only saves about 10 seconds per project (or however quickly you can copy and paste) which probably doesn't add up to how long it takes a kettle to boil over the course of a year

I think I prefer the idea of people pasting the code for the following reason. If you upload a lightbox like Shadowbox, or other scripts where they have their own folder structure that you need to preserve you might find that you need to manually tweak the URLs.

Here's an example from one of my sites (before I built the module):

<link href="/site/libs/min/b=site/templates&f=styles/reset.css,styles/general.css,dark/css/dark.css,light/css/light.css,scripts/fancybox/jquery.fancybox.css,styles/forums.ipb.css" rel="stylesheet" type="text/css" />

Lots of scripts in different folders means that the way this module works - scanning two of PWs default directories for files - simply wouldn't work. I'd wager that if someone did something similar without understanding how it worked that they would either:

1. use Minify for the scripts in /site/templates/scripts/ and a normal <script> tag for the rest (which sort of defeats the purpose of it), or:
   
2. abandon using the module entirely when they perceive that it can't do what they need it to do.
   

My thinking is that by looking at the code they can do what I did and simply tweak the paths to suit. I think overall there are too many possible configurations to take all of the work away from the user.

[yellowled]

I just gave this a quick spin on my local Apache, works like a charm. (Can't really test it anywhere "live" since I don't have any "unoptimized" PW installations flying around since I usually use the H5BP build script to concat/minify.)

Two small thoughts, both of them are completely a matter of taste:

• It might be a nice idea to emit the generated URL which you paste into your template in an input field instead of as plain text since that's usually a bit easier to get for copy & paste.
  
• As far as I know, Minify also has an option to emit a "clean" URL for the combined files, i.e. "style1.css" instead of "styles&f=reset.css,main.css" — which I'd prefer. I know it's silly and not an issue technically, but to me, it just looks wrong.
  

Other than that: Great module to have, Pete. I'm not sure non-expert users will love this as much since they's still have to modify template files, but it sure adds a nice way to make Minify integration a lot easier.

[Pete]

Thanks!

I'll look into the form field.

Not sure about the clean URL as that may require altering the config file for min, and I'm trying to keep it as simple as possible to upgrade. That said, it's not like the Minify library gets updated that often so I may look into that.

I still think that non-expert users will have to modify the default template anyway if only to change the theme, so I'm not too worried about that. If they can't at least copy and paste then managing a CMS is going to be a shock

[yellowled]

I still think that non-expert users will have to modify the default template anyway if only to change the theme, so I'm not too worried about that. If they can't at least copy and paste then managing a CMS is going to be a shock

Well, once and if PW attracts a greater user base, chances are someone™ will implement some kind of module or other mechanism to make building templates easier, maybe some kind of system like TemplaVoila or what's-it's-name for TYPO3. There might even grow a market for custom-made or at least pre-built templates, who knows?

I absolutely agree that anyone can be bothered to fire up a text editor and follow instructions to copy & paste some lines into a file. It's not that hard. Then again, I have some years of experience in user support in a similar forum for a blog system … trust me, people will complain that this is too hard or something "only you nerds understand" …

But there's also the question whether non-expert users do actually care for something like performance optimization. My opinion would be if they don't, their loss. If they do, they're gonna have to roll up their sleeves and get their hands dirty, just like we used to do. Of course we'll advocate them and give pointers and instructions, but no one can expect to be pampered in a support forum where people help out in their free time.

[ryan]

Great and useful module Pete! One recommendation I have is that this module probably shouldn't be autoload. That's something reserved for modules that need to attach hooks and execute on every request. In this case (if I understand it correctly), the Minify module only needs to execute when you are configuring it. So this module will be more efficient if it is not loaded on every request. This 'autoload' is defined in your getModuleInfo() function and you can either remove the line or set it to false, to make this adjustment.

[Pete]

I've updated this to include yellowled's suggestion of making the code appear in a form field - easier to copy and paste plus it looks neater. Also turned off autoload at ryan's suggestion. Thanks guys!

Well, once and if PW attracts a greater user base, chances are someone™ will implement some kind of module or other mechanism to make building templates easier, maybe some kind of system like TemplaVoila or what's-it's-name for TYPO3. There might even grow a market for custom-made or at least pre-built templates, who knows?

I would love to see this, though I think it would only happen for something like the blog profile ryan is working on, since the basic layout is pretty much standardised (so the user has no need to move the layout around if they don't want to). In that case and in the case of other standardised site profiles, I'd be happy to modify the module to automatically insert code. I guess in that instance, what you would want it to do is scan the installed theme for any links and scripts and try to replace them automatically with a couple of minified strings, something that would have me tearing my hair out trying to work out the regexp for

I think I'll cross that bridge when ryan builds it

[yellowled]

One thing I just stumbled upon:

grabbing a list of any stylesheets and scripts it finds in the /site/template/styles/ and /site/templates/scripts/ directories

I actually prefer to have CSS in /site/templates/css/ and JS in /site/templates/js/, some users might even put both in /site/templates/. Would it be possible for the module to just scan /site/templates/ and directories below for CSS/JS files?

[Pete]

Could do - I'd have to put in some recursive folder scanning and it would make the actual URL longer in the default cases (it would then have to add js/ and styles/ before each respective filename, not that that really adds any overhead of note.

[Adam Kiss]

Actually Pete, I think that in long run, it would be for the best if you made this configurable.

I, for one, often use either /assets/[js|css] or /site/assets/[js|css] as my directories

[Pete]

I could well make it so that you can set the path as an option and tick a box to check all subfolders, but you would have to click Save before the ASM select lists were updated unless anyone knows of a way to have those fields refresh via AJAX?

I guess I could just make the page save automatically somehow once either of the configurable path and checkbox fields lose focus and that would achieve the same, but it should probably at least pop up some sort of confirmation dialogue box so the user has some clue what's happening.

[Adam Kiss]

I think that simple notice 'save before you set your files' should suffice here: after all, you do this only once, right?

[Pete]

Yeah, good point

[Pete]

Okay, I updated this to 1.0.1 to search recursively for files under the /site/templates/js and /styles folders - this is available from the modules directory as v1.0.1.

I thought I'd work on v1.0.2 which lets you specify starting folders further up the tree whilst I'm at it but have hit a snag. It works fine, but when you change the path and hit save the drop-downs don't update their path unless you save the module a second time.

Anyone have any ideas why you'd need to save the module twice for the config page to be able to use an updated value?

[ryan]

Anyone have any ideas why you'd need to save the module twice for the config page to be able to use an updated value?

Would probably need to see the specific code block in question--feel free to send along to me and I'll take a look.

[OllieMackJames]

Hi Pete,

Thanks for a great module. I have installed the blog profile (thanks ryan) on a testsite and am playing around.

The blog profile uses skeleton css and js and the whole skeleton directory is one up from styles and scripts

Any idea how to get those in?

thanks

Olllie

[Fourjays]

Anyone got any ideas on what would cause this to return a "400 Bad Request" error? I gave it a go earlier and all I got was this error on the link that should have given the combined CSS. I checked the link provided in the error (to the Minify docs) and installed FirePHP as suggested, but it doesn't give any more information in the console. Running on a localhost setup if that could be related.

[Macrura]

can you post the code you are pasting in the template? if you are getting a 400 bad request, it's probably because you have a trailing slash on the base path, or the path is no good; you can edit the paths within the module;

I am using this on a new 2.3 site and i can confirm it works as expected, and i just needed to edit all of the paths in the module itself and the path in the code that you paste into the template, with the actual paths to where my assets are located;

@olliemackjames - same thing, you just need to edit the paths.

[Fourjays]

can you post the code you are pasting in the template? if you are getting a 400 bad request, it's probably because you have a trailing slash on the base path, or the path is no good; you can edit the paths within the module;

I am using this on a new 2.3 site and i can confirm it works as expected, and i just needed to edit all of the paths in the module itself and the path in the code that you paste into the template, with the actual paths to where my assets are located;

This is what it gives me and what I copied to the header. All the paths look fine though. The CSS files are in projectname/site/templates/styles and that is what it puts in the "b" argument.

<link href="<?php echo $config->urls->siteModules; ?>Minify/min/b=<?php echo trim($config->urls->templates, '/'); ?>/styles&f=reset.css,base.css,main.css,anim.css" rel="stylesheet" type="text/css" />

[Macrura]

@Fourjays,  can't see anything wrong with your code;

maybe it is a server issue - there are some settings in the minify config file that might help.

[Macrura]

Just wanted to post a problem i had with Minify and the fix, in case anyone else runs into this:

Problem:

If you have an already minified css file (like for example a boostrap.min.css) as one of the files you are including in your minify concatenation string, the files with the string 'min' somewhere in the filename won't get processed, and consequently the URLs within the CSS files will not be correct;

If this happens you'll see a recursive loop in your console, as the network requests for something like an image start to initiate a new minify process and this will create about 20-30 additional network requests that keep getting longer and longer.. sort of like this:

builder/

builder/builder/

builder/builder/builder

builder/builder/builder/builder/

builder/builder/builder/builder/builder/

and so on and so on...

the fix is to set the behavior to minify all files, (or to use an unminified version of the css which is easier and would survive updates to the module);
In case you don't want to or can't change the css files you are using, you can change this setting in the Minify/min/config.php file as follows:

/**
 * By default, Minify will not minify files with names containing .min or -min
 * before the extension. E.g. myFile.min.js will not be processed by JSMin
 * 
 * To minify all files, set this option to null. You could also specify your
 * own pattern that is matched against the filename.
 */
//$min_serveOptions['minApp']['noMinPattern'] = '@[-\\.]min\\.(?:js|css)$@i';
$min_serveOptions['minApp']['noMinPattern'] = ''; 

[totoff]

To use it, extract the attached zip file into your /site/modules/ directory and check for new modules in the ProcessWire Admin area, then install the module.

ahem, please don't blame me for a stupid question, but which one of the directories in the zip are really relevant and must be transferred to the server? /min_extras/ contains a warning, not to use it on a production site ...

[totoff]

nothing?