Leaderboard

I think this is correct, that it really just depends the way you are used to working with images. For the sites I build, if I ask for an image of a specific size, it's because that's the size I need. I don't care what it has to do to get there, because the needs of my layout are more important than the image itself. An image of any size other than what I asked for would be inconsistent at best or a layout breaker at worst. I'm usually dealing with lots of images that I depend on being consistent with each other in size. I hate upscaling, but I hate inconsistency even more. If something has to be upscaled then I'm going to notice that and try to find a better image, but at least the damage is limited to the image rather than the layout or consistency. Here's another way to accomplish it. Put this somewhere in one of your first template includes: function sizeDown(HookEvent $event) { $width = (int) $event->arguments[0]; $height = (int) $event->arguments[1]; $image = $event->object; if($image->width < $width) $width = $image->width; if($image->height < $height) $height = $image->height; $event->return = $image->size($width, $height); } $wire->addHook('Pageimage::sizeDown', null, 'sizeDown'); Now you can substitute any $image->size() call with $image->sizeDown(): $image = $page->image->sizeDown(300, 200);

Apeisa - I actually agree with most of those points and even using PW as-is, without any extra flourish, it's still much easier and more flexible than 90% of other CMS I have used in 10+ years of web development, and would do fine "out of the box" for 90%+ of typical web agency situations. Regarding the use of Silex with PW, it's really very simple. Silex is a microframework that provides a very simple mechanism for mapping regex-based URLs to a methods (actually closures, so PHP 5.3+ only), where you can stick some code. Because it is based on Symfony2, it is built to a very robust standard with best practise in mind and can make easy use of many great Symfony2 components such as Request/Response objects (HTTP handling), Twig templates, DB access with Doctrine, Session handling and many other useful bits. In a nutshell - you map a URL to a method and in that method you use the PW API to grab data and inject into a Twig template. That's it. Your URL structures can be as simple or complex as you like with placeholders for dynamic parts e.g. canonical URL segment of blog post or the DB record ID etc (just the variable bits) and you can enforce regex rules on those parts to ensure they match a certan format. It might seem like a lot of fuss, but it isn't really and the Twig templates are a joy. They're clean, secure, you can extend with new tags, perform all sorts of processing and iterating of data, and templates can extend each other so you can have more generic templates that get extended with specific functionality as you need it. It measn that building a slight modification of an existing template can be done very easily and in a way that doesn't have to tamper with the original at all, just like a class hierarchy in OO code. http://silex.sensiolabs.org/ http://twig.sensiolabs.org/ I'm a bit of a Sensiolabs fanboy to be honest, and I think Fabien Potencier and the Sensiolabs team come across as being the cutting edge of PHP development. Symfony2 is a great framework, Twig is brilliant, Silex is very easy but powerful and everything they do seems to have a real sense of quality craftmanship. In combination with the excellent data modelling power (and excellent back-end interface) of Processwire, it's a good combo!

Hey Ya'll, Just for fun, I'm going to do a Security Analysis on Processwire by following the principles in Hacking Exposed 3 - Web Applications. I think It'll be nice to show my clients a final summary to help reassure them how secure things are, while giving me some credibility for being security conscious~ Anyways, I'm kind of busy these days, so it won't be updated too often, and of course I'll let The PW team fix any issues prior to releasing any security holes. BUT, if your interested, the feel free to subscribe to the RSS feed for this topic.. otherwise you can find it here: http://neilpahl.com/logs/security-projects-public/processwire-cms-security-analysis/ if there is any interest, I'll make an email subscription available for this topic feed~ Let me know if there is any specific area you feel the security should be looked at more closely... Cheers,

OK, False alarm. The error was because the next/prev pages don't contain the images — it's the children of the next/prev pages that have the images field. I forgot I moved the image to the child pages (been on this project too long.) Apeisa, forced me at gunpoint to come here and confess my sins. As you were...

It should be quite easy to add these methods to Pageimage by a module. ImageSizer already has everything we need. I just did a quick hack and put the Pageimage->size method into my template.php, just to see whats possible with a few modifications, and it seems to work great. function resizeImage($image, $width, $height, $cropping=true, $upscaling=true) { $width = (int) $width; $height = (int) $height; $basename = basename($image->basename(), "." . $image->ext()); // i.e. myfile $basename .= '.' . $width . 'x' . $height . "." . $image->ext(); // i.e. myfile.100x100.jpg $filename = $image->pagefiles->path() . $basename; if(!is_file($filename)) { if(@copy($image->filename(), $filename)) { $sizer = new ImageSizer($filename); $sizer->setCropping($cropping); $sizer->setUpscaling($upscaling); $sizer->resize($width, $height); if($image->config->chmodFile) chmod($filename, octdec($image->config->chmodFile)); } } $pageimage = clone $image; $pageimage->setFilename($filename); $pageimage->setOriginal($image); return $pageimage; } usage like this: $neverUpdscaledImage = resizeImage ($page->image, 100,100,true,false); $uncroppedImage = resizeImage ($page->image, 100,100,false,true); echo "<img src={$neverUpdscaledImage->url} />"; Btw, I dont't recommend to do it like this. I just wanted to test whats possible.

Hi Lance, Steve is correct. One of the first things I built in order to learn PW, was a front-end profile editor. What I have is fairly specific to a University environment, but I think I can strip it back to a more simplistic form and get a walk-through posted. I'll report back soon.

This depends quite a bit on which way you've used to working with images / thumbs. I myself find it very hard to think of any possible situation where I'd like to upscale an image -- and if I really wanted to do that, I'd be happy to do it with CSS, though usually I prefer to have too small images centered etc. so that they look at least somewhat ok. This is why I've so far ended up adding if's before every single size-call, which gets kinda annoying in the long run. On the other hand, I really, really appreciate what Ryan is saying here. Any and all extra params / features / whatever should go through very serious consideration before being implemented, unless you wan't to end up with bloated code no-one really understands anymore. Seen this happen way too many times..

I understand what Ryan says here, but I will like everyone that suggests these I even think that something along maxSize should be the default behavior, because no one wants to see giant pixels on any picture.

Nobody likes upscaling. But if I call a function asking for it to create something at a certain size, it's because that's the size required. If there are other conditions surrounding that, shouldn't it be left to the caller to decide? i.e. if($image->width > 300) $image = $image->width(300); If not wild about extra arguments (especially booleans) in API functions because they aren't self explanatory in the resulting code. So I'll only use them when absolutely necessary. Whereas, a bit of code like above is self explanatory to us now, and years from now when things like "what does the 3rd argument mean" are no longer fresh on our minds. On the other hand, I've got no problem with self explanatory function names, like widthNoUpscale(), but sometimes adding more makes the API less simple.

I totally agree with this. I even think we should take this as concept for PW. I really like the way things are happening here. Most modules are discussed in the forum, and each module gets lots of input from the community before it's finished. I know that it isn't easy to keep it like this, as the number of users and developers grow, but would be great if it would be possible to keep a truly useful official modules repository (not too big, and without repeated functionality). This could be done via the forum, and via a small number of administrators who would filter, and propose the merging of modules with the same functionality.