teppo

@Ryan: that seems like a valid solution, thanks! I'll be implementing it in most of our projects from now on .. and for the record, I really hate inconsistency too. It's just that quite often inconsistent image sizes are something we have no control over; this happens when content is either fetched from a third party with varying level of consistency or added by not-exactly-web-savvy content authors.. Like I said, generally I prefer to control these situations with styling rather than scaling, so whenever an image really needs to be of proper size I place it inside a container -- horizontally and/or vertically centered, depending on situation. This has worked for most situations so far.

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

Ryan, there are actually certain rather important things that this changes. Don't know if I can explain this properly without a huge pile of screenshots, but I'll try anyway First of all, if only extension is checked at ImageSizer and image cannot be resized, currently it fails silently and Pageimage thinks it has a valid thumbnail. What it actually has is just a copy of the original image and when asked for thumb, it outputs that, resulting in rather awful situations layout-wise. By applying proper image type filtering, instead of failing silently ImageSizer throws an exception and thus Pageimage won't think it has a valid thumbnail. IMHO this is a much better solution -- and makes it very clear to the developer what's going on there. This is actually how this would've solved our problem; current behavior made us somewhat confused because there was absolutely no error, everything seemingly went smoothly and only when we started testing those oddly behaving images with file-command did we realize that they were actually bitmaps. Same thing, by the way, happens at the admin UI if the image field has "Display thumbnails in page editor?" checked. Without image type filtering it outputs full copy of the original image, but when image type is checked properly it fails ("bitmap.0x100.bmp is an unsupported image type.") I do realize that this is rather rare scenario really, but what I'm saying here is that current filtering isn't (in my opinion) valid. Extension is just something someone has decided to write there and we have no way to confirm if it's actually useful in any way. Also, currently ImageSizer can easily be fooled to send invalid data to GD -- I'm not sure if there's any real problem related to this, but I'd still be a bit careful, 'cause it might in some rare cases interpret that data in strange ways..

@neildaemond, that sounds like a very interesting topic! Please keep us posted here about your progress, would love to hear more about this

It would be nice to be able to turn upscaling off (set it to false on ImageSizer) via size() function of Pageimage. Currently size accepts two parameters (width, height) -- how 'bout adding upscaling (true/false, default to true.. or perhaps "disable upscaling" and default to false, whichever makes more sense) as third parameter?

We had a slight problem with ImageSizer recently; everything seemed to be fine but creating thumbnails still failed. The reason for this turned out to be that those images were of unsupported type (windows bitmaps) yet their extension was ".jpg" and thus ImageSizer considered them proper JPEG's and acted accordingly. Anyway, sorry for the spam but this is the solution I ended up implementing. I'd be grateful if Ryan (or someone else who knows the core well) would take a look and tell me if this is a valid solution -- and if it is, I'd like to suggest changing current extension-based "filtering" to something more like this I also took a look at the Upload class / InputfieldFile, but seems to me that implementing proper imagetype filtering there would require a lot of work.. and doesn't necessarily even make sense in that context. --- wire/core/ImageSizer.php (revision 1717) +++ wire/core/ImageSizer.php (working copy) @@ -46,6 +46,12 @@ ); + /** + * Type of image + * + */ + protected $imagetype; + /** * Allow images to be upscaled / enlarged? * */ @@ -67,11 +73,10 @@ * File extensions that are supported for resizing * */ - protected $supportedExtensions = array( - 'gif', - 'jpg', - 'jpeg', - 'png', + protected $supportedImagetypes = array( + IMAGETYPE_GIF, + IMAGETYPE_JPEG, + IMAGETYPE_PNG, ); /** @@ -83,9 +88,10 @@ $this->filename = $filename; $p = pathinfo($filename); $this->extension = strtolower($p['extension']); + $this->imagetype = exif_imagetype($filename); $basename = $p['basename']; - if(!in_array($this->extension, $this->supportedExtensions)) + if(!in_array($this->imagetype, $this->supportedImagetypes)) throw new WireException("$basename is an unsupported image type"); if(!$this->loadImageInfo()) @@ -130,12 +136,9 @@ $source = $this->filename; $dest = str_replace("." . $this->extension, "_tmp." . $this->extension, $source); - switch($this->extension) { - case 'gif': $image = @imagecreatefromgif($source); break; - case 'png': $image = @imagecreatefrompng($source); break; - case 'jpeg': - case 'jpg': $image = @imagecreatefromjpeg($source); break; - } + if($this->imagetype == IMAGETYPE_GIF) $image = @imagecreatefromgif($source); + if($this->imagetype == IMAGETYPE_PNG) $image = @imagecreatefrompng($source); + if($this->imagetype == IMAGETYPE_JPEG) $image = @imagecreatefromjpeg($source); if(!$image) return false; @@ -143,7 +146,7 @@ $thumb = imagecreatetruecolor($gdWidth, $gdHeight); - if($this->extension == 'png') { // Adam's PNG transparency fix + if($this->imagetype == IMAGETYPE_PNG) { // Adam's PNG transparency fix imagealphablending($thumb, false); imagesavealpha($thumb, true); } else { @@ -155,7 +158,7 @@ imagecopyresampled($thumb, $image, 0, 0, 0, 0, $gdWidth, $gdHeight, $this->image['width'], $this->image['height']); $thumb2 = imagecreatetruecolor($targetWidth, $targetHeight); - if($this->extension == 'png') { + if($this->imagetype == IMAGETYPE_PNG) { imagealphablending($thumb2, false); imagesavealpha($thumb2, true); } else { @@ -170,20 +173,13 @@ imagecopyresampled($thumb2, $thumb, 0, 0, $w1, $h1, $targetWidth, $targetHeight, $targetWidth, $targetHeight); // write to file - switch($this->extension) { - case 'gif': - imagegif($thumb2, $dest); - break; - case 'png': - // convert 1-100 (worst-best) scale to 0-9 (best-worst) scale for PNG - $quality = round(abs(($this->quality - 100) / 11.111111)); - imagepng($thumb2, $dest, $quality); - break; - case 'jpeg': - case 'jpg': - imagejpeg($thumb2, $dest, $this->quality); - break; + if($this->imagetype == IMAGETYPE_GIF) imagegif($thumb2, $dest); + if($this->imagetype == IMAGETYPE_PNG) { + // convert 1-100 (worst-best) scale to 0-9 (best-worst) scale for PNG + $quality = round(abs(($this->quality - 100) / 11.111111)); + imagepng($thumb2, $dest, $quality); } + if($this->imagetype == IMAGETYPE_JPEG) imagejpeg($thumb2, $dest, $this->quality); unlink($source); rename($dest, $source); ... and yes, that's output from SVN diff. I hope you guys can cope with that / understand what's going on in there. I'm not very familiar with Git and how it handles stuff like this. Sorry.

@Chad, if you want /main.domain.com/the_games/game1 to redirect to another folder somewhere else, you could try using symlinks for that. Though I don't know why you'd need to do this -- couldn't you just move contents of /games/game1/ to correct folder inside /site/? Naturally there could be many reasons that make this difficult, but it might still be worth considering.. this sounds a bit like a setup that might cause many more problems in the future About requests for files mentioned in your XML file failing, this could have something to do with either htaccess rules OR with the way you're requesting those files. What and how does these requests? Is it PHP, Flash or something else? Could it be that it's actually failing the request somehow? What do Apache logs tell about this problem?

I had the same repeater problem that Soma reported some time ago. Following changes to ProcessCropImage.module got it working: $this->setFuel('processHeadline', 'Crop images'); + $field = $this->input->get->field; + if (preg_match("/_repeater[0-9]+$/", $field)) { + $pages_id = (int) end(explode("_repeater", $field)); + $field = str_replace("_repeater$pages_id", "", $field); + } else { $pages_id = (int) $this->input->get->pages_id; + } $filename = $this->input->get->filename; - $field = $this->input->get->field; $height = $this->input->get->height; $width = $this->input->get->width; $prefix = $this->input->get->prefix; This is a bit of a hack and I haven't even tested it properly, so I'm definitely not saying that anyone should use the same method -- but it worked for me

Downloading now, will comment after testing

Happened to have a PW site open, so I did some grepping (is that a word? should be..) and seems to me that you're absolutely right. No short tags found from core files. @Natetronn, I'm trying to avoid getting all evangelical here, so I'm keeping this as short as possible: IMHO learning enough PHP to write templates effectively is much easier task than learning enough of most templating languages out there to do the same. PHP has very good documentation (php.net), wide user base (try googling pretty much any problem you're having and add "stackoverflow" to your query, it's rare to find a question someone hasn't already answered there) and there are many fantastic tutorials floating around. "It's easier than you think." That said, I don't have that much experience with templating languages -- mostly I've used Twig and several in-company solutions, so I'm not much of an expert on this subject. All I can say is that after years of learning, fighting and cursing various templating languages and their shortcomings, being able to write templates in pure PHP is a bliss for me

From PHP documentation: "Before 5.3.6, the only values recognized are TRUE or FALSE, which are the same as setting or not setting the DEBUG_BACKTRACE_PROVIDE_OBJECT option respectively." Perhaps that could explain the error you were getting? Edit: actually it seems that before PHP 5.2.5 debug_backtrace() didn't allow ANY parameters. Not exactly sure if that could mean "not even false", but if that's the case this might be the real reason for your problem. I'm sure there's a PHP guru somewhere around here who knows this for sure, though.. Ryan?