Jonathan Dart

Hi Horst, I reviewed most of your changes and integrated them: ->optimize now accepts an array options so you can customize behavior per call ->optimize won't overwrite original files, a variation would be created ->optimize will overwrite a variation I had a look at passing the options to size() with the purpose of them getting passed on to this module, but it seems that if the options aren't the usual ones used by ImageSizer they get discarded, so I can't read them - which is a bummer. Do you know of a way around that? Or maybe that's changed in the dev branch? Also regarding setting the quality to 100 before imagesizer runs if the optimizer would be used later - that would be awesome but I don't see a hook for that - do you have any thoughts on that?

This is pretty similar to how Spex works (shameless plug). It doesn't use a separate file for controllers however, the template file is used as a dual purpose: controller and initial generation.

I added a toolbar to profile the performance of partials/layouts. Check out the attached screenshot to see what it looks like when the toolbar is open, by default it collapses to just display the totals.

Do you have any thoughts on which png tool is the best? I found the below resources but I'm not sure what to make of it all, I guess it depends if we want lossy or lossless png compression. http://pointlessramblings.com/posts/pngquant_vs_pngcrush_vs_optipng_vs_pngnq/ http://css-ig.net/png-tools-overview.html

Wow horst indeed! I will need some time to digest your feedback, stay tuned. Adrian optimizing png's would be useful as well - I'll see what that would entail.

I was surprised to see that 600ms figure so I tested out some pw sites I've worked on. My PW 2.4 sites seem quite a bit slower than the sites using 2.3. I'm using a pretty beefy server and the 2.3 sites have processing times below 300ms where as the 2.4 sites are 600ms+. For the most part that is acceptable but it would be nice if it was faster. Some options to speed up pw: Open an issue on github, make ryan aware of the performance issue Find the bottlenecks in the code yourself, fix them and create a pull request Use ProCache Put Varnish in front of your web server Put Cloudflare in front of your web server Edit: I was a bit hasty, an empty pw 2.4 project executes in around 200ms, those other 400ms+ are my doing.

Hi Guys, I created a new module to optimize jpegs using the command line tool jpegoptim which yields amazing results, it's comparable to jpegmini.com when using 75 quality. Instructions and usage are available in the readme on github. https://github.com/jdart/JpegOptimImage Let me know what you think! Thanks

Hi Horst, I added a function to the Spex class that hopefully solves that use case: renderPage So in the template for the page at the url "/download/" you might do something like... echo $spex->renderPage($the_real_page); That changes the page that Spex treats as the request page, i.e. it's as if the request was for $the_real_page rather than wire('page'). It's a bit ugly but seems to be a edge case, so maybe it's ok. What do you think?

I was overriding the $page variable naively, I've pushed a change that should address the issue. Let me know if it addresses your issue.

Can you give me a bit more detail of an example when you'd want that?

@geniestreiche I've updated the master branch of the github repo with a change that might solve the problem for you, let me know what you find.

This is tricky, maybe I should only enable the layout stuff if the page being rendered is the current $page and bail otherwise... I'll try some stuff out.