teppo

Ryan, I can remember a discussion about putting this thing up, but somehow I've completely missed the fact that it already exists. Will take a closer look and participate if there's anything I can help with. By the way, should there perhaps be some kind of "advertising" about this somewhere in case that there might be others like me who'd like to contribute but just didn't know that they could?

Paid corporate / enterprise service offered by core developer(s) isn't such a bad thing, really. IMHO it would actually add to the credibility of ProcessWire as a high-quality "enterprise level" CMF/CMS -- though I do agree that it requires some serious planning. Anyway, isn't that exactly what Acquia is doing with Drupal?

@geniestreiche, responsinator.com has quite an interesting idea. Obviously still doesn't match the feel of a real device (and is a bit lacking when it comes to Android devices) but definitely nice addition. Adobe Shadow is something I'll definitely have to give a try, seems helpful -- especially liked the ability to "live-edit" markup. Thanks for sharing these!

Thanks for sharing this @Pete, that seems really interesting! I think I've tried some earlier version of this, though it could've been web based application.. can't remember for sure anymore. Will have to try this one out anyway. Regarding mobile testing in general, I usually try to avoid emulators. First of all they're just emulating something they're not and thus there's no guarantee that they're doing it properly in all cases. There's also this (much bigger) problem that you won't get real "feel" of the device, which can sometimes be rather important. I'm sure you guys already knew that, I'm just stating the obvious here in case someone with less experience happened to read this @Martijn, responsivepx.com seems nice too and I believe that you're absolutely right about defining breakpoints based on content and not the device(s), though common mobile devices / settings should definitely still get some extra attention (so that everything works nicely at least in those situations.) I've used responsive.is and screenqueri.es for testing breakpoints. Out of these two screenqueri.es is more technical, while responsive.is is clean, simple and looks good -- thus it's fun to use even during meetings to demonstrate for clients how proper responsive design works

@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