Leaderboard

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.

Hi all, Using code provided by Ryan here, I've created a module that coverts a PageArray into JSON format. It's been super useful to me, and I'm hoping it will be for others as well PagesToJSON.module

While it may be okay to do once in awhile, I would avoid structuring your site in a way that requires uploading the same image in multiple places. Instead, pull from the source page via the API and use the image. An example of this would be a site structure like this: /about/ /contact/ /press/ /history/ Lets say that you want all these pages to have the same header image. Rather than populating a header_image field on each page with the same image, populate it on just your /about/ page and let the others pull from it. Even if all the pages use the same template file, you can achieve it with this: $image = $page->header_image; if(!$image) $image = $page->rootParent->header_image; if($image) echo "<img src='{$image->url}'>"; The approach here is to give each page the ability to define it's header image, but make it optional. When it's not populated, it grabs the default from the root parent page (/about/). But lets say your structure is a little deeper than that: /about/ /contact/ /directions/ /press/ /history/ In that case, you may want to have it inherit the header image from the nearest parent that has it defined. So /about/contact/directions/ would show the header image from /about/contact/ (if it had one) rather than the one from /about/: $parent = $page; do { $image = $parent->header_image; $parent = $parent->parent; } while(!$image && $parent->id); if($image) echo "<img src='{$image->url}'>"; There may be other cases outside of the example above where you might have the need of using an image defined on another specific page. In that case, use a page reference field. You might call it header_image_page. It would essentially say "I want to display the header image from that page". This is a little better than a direct file reference because your image will still work even if the source page changes it. $image = $page->header_image_page->header_image; if($image) echo "<img src='{$image->url}'>";

The isue with the double links was because there was an old copy of the forum theme still in the database - removed that now. That indentation issue is very odd though. It might have been fixed in the latest version though so I'll check it locally when I get time.

Probably the 'easiest' and most effective way to deal with high traffic websites is using a caching HTTP reverse proxy, such as Varnish cache or squid cache. It sits in front of your web-stack and caches and serves cached versions to your visitors, greatly reducing server load. See for example http://highscalability.com/blog/2011/2/28/a-practical-guide-to-varnish-why-varnish-matters.html Of course, this doesn't apply to cheap shared hosting.

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: 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: 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.

This is great Ryan, thank you! My only comment is that Vimeo seems to default to https - for me at least. When I tried entering a url like the formatter didn't seem to catch it. To my surprise I could see how to fix it by duplicating the vimeo section and adding changing it to https. Scary!

In regards to your htaccess/rewrite for improving performance, Drupal has a module called boost (http://drupal.org/project/boost) that has been used on really large sites. It seems to be in line with what you are talking about and maybe you will find something in there that will help you with PW.

You're not alone, Nico.

A modules section is planned for the new website, so that should help

Linebreaks are now supported in the field descriptions (dev branch). It just runs the description text through PHP's nl2br() before outputting it. While I was there, I also made it so that you can use markdown style links in field descriptions as well. i.e. [ProcessWire](http://processwire.com)