Add an automatic resizing for images to the target size. That way you can upload your 3 megapixel photos to the site and they are still displayed in a resonable resolution.
The nessecity to resize images beforehand stands against the concept of simplicity that makes gp|easy uinique.
It would be nice if gpEasy sized the embedded pictures to the dimensions of the element holding the picture. That way we can get rid of the thumbnail directory and cache all the pictures in a temporary folder. When editing you just choose to embed the source picture. Don't know if this is possible and how much work that would be...
A flat file CMS can benefit from caching as much as a database systems. You only want to resize an image once, instead of every time it's called.
Most of the necessary code appears to already be in tool/Images.php which is used to generate the 100px square pixel. So it's essentially a matter of feeding that script the sizes you want, the destination folder, and naming scheme.
The hard part is to design a system that works for most people. Many systems resize to a max width, which makes vertical images larger than horizontal image (if you have 4x3 images and a max width of 400 pixels, a horizontal image would be 400x300 ad a vertical image would be 400x533). An interface that lets the user enter the size would be nice for some, but adds an extra step. A system that resizes based on image area would be great for me ($new_x = √($old_x / $old_y) * $new_area and $new_y = √($old_y / $old_x) * $new_area).
So the issue is more with user interface design than a technical issue.
So I may have thought this idea was more complicated than I thought...
A system that resizes based on image area would be great for me
gpEasy actually already does this! Take a look at the configuration setting labeled "Maximum Image Area" (under the "Performance" heading). Any images uploaded with areas larger than the value defined in this field will be resized.
So those "3 megapixel photos" uploaded to your gpEasy installation will automatically be resized.
It would be nice if gpEasy sized the embedded pictures to the dimensions of the element holding the picture.
This is actually how I've been approaching the idea the whole time.
I saw the image area code in the Images.php file. I didn't see where gpEasy was using it. This is great.
This would be awesome, but harder to implement. The thumbnails are currently created when the file is uploaded. The resizing you want would happen after upload and within the CKeditor framework.
Since you may be trying different sizes before deciding on the perfect, it would be better to keep the original image in place while you're designing. Then click a button named "optimize image" that would read your sizes, call the image processor, create a new file named P1150562_160x127.jpg, and replace the image on the page with the new one (keeping the original intact in case you need it somewhere else).
I'm dreaming but it should be possible.
It looks hard to implement right, but would be awesome!
Creating the 160x127 image isn't too bad, the challenge is managing all the resized images.
Consider this: If someone starts with 160x127, and later decides to change it to 150x117, and later again changes it to 170x137. gpEasy could fairly easily create those three images each time a user saves the page, but how does gpEasy know when to delete a resized image? If there are two pages using the 160x127 image, we can't delete it when one of the pages stops using it.
I agree. The hard part is to get an intuitive user interface and image management. And once you get it right, people will want more advanced image manipulation tools (cropping, etc.). You can't win! ;-)
If you use my suggestion of having the image resized only when triggered manually, you should not have a tremendous amount of images. The user can figure out the layout with a browser-resized image, and only optimize the image when he is satisfied with the layout. My inclination would be to add an "optimize" button to the Image Properties window.
I would not auto delete any images. The user can do some housecleaning when necessary. At some point, the user has to take ownership of the site. If a site is slow because 1 megapixel images are browser-resized, that's the user's problem as well. All i'd like is for gpEasy to offer the tool to optimize the images. Whether the user takes advantage this tool or not is less of an issue. Some may disagree on that and prefer an automated approach. I prefer the added control of doing it manually.
I don't know if gpEasy tracks which images are used. If it does, it would be nice to have a view in the file browser that identifies that. If not, no big deal.
As for file management, I'd start with appending the size to the file name of any resized file and storing them in an "optimized" folder next to the original. It would be nice to be able to select which image variation to use from the sizes already available, but once again, no big deal (most users will resize once and forget it). Plus they could navigate to the "optimized" folder and select the size they want.
There could be an issue If someone replaces an image with another one with the same name (expecting it to be replaced throughout the site). gpEasy could check for file names on upload and offer to recreate the resized images based on the new ones. A file name check or an "optimization log" file could be used to identify the files that need to be redone.
An advanced system would analyze the entire site and compare the <img> size values, compare them to the file's size and offer to resize and relink the images that don't match. That would be really nice, but is overkill and is way down on my wish list.
I've been talking about this with a partner, and he suggested using a simple cache:
The image is called via a php wrapper that checks if the needed size is available and generates it automaticaly if not. For that you might only need an array with the available image sizes and maybe a timestamp. If you log access-times, you can wipe unused images after a certain time.
Edit: Well, we just had a look at the code and see you have the code for exactly that already in 3.01. So, just tell us when it's finished ;)
I like it!
One concern. This would open up the possibility for a malicious user to create any number of images on the server by changing the parameters:
My inclination would be to add an "optimize" button to the Image Properties window.
When this suggestion from Eric is used you could prevent non-authorized users to generate resized images.
An other method is to set a maximum cache size for all the resized images. When this limit is crossed the oldest generated images can be thrown away. There is still a possibility to generate a bunch of images (taking much cpu-resources) but the server disk or the hosting quota isn't reachtd if that setting is correct.
Another way is only allowing localhost to do this operation. When the page is parsed the images will be generated on the server (accessing timthumb via localhost). That way no one can generate an image, only the right images are generated for certain img tags. I think this would have my preference.
And finally you could parse the new content when its posted, and only then call timthumb, but this requires some extra checks in other plugins like contact form because posting is possible there too.
I think the CMS is the image size ImpressPages statement released super easy
Over + / - you can adjust the image with the mouse you can move the clipping of the image.
Here is a nice component for image manipulation in PHP: http://www.verot.net/php_class_upload.htm
I dont know what the status is but I saw in the svn log that you ditched the jCrop approach.
Here are 2 another alternatives to Ben Gillbank's timthumb. - PHP THUMB, guckst du hier: http://phpthumb.gxdlabs.com/
And the basic Usage of PHP THUMB on github: https://github.com/masterexploder/PHPThumb/wiki/Basic-Usage
The second alternative is maybe the most effectful image manipulating class in the Net with more than 45 effects, - Easy Php Thumbnail: http://www.mywebmymail.com/?q=content/easyphpthumbnail-class
You must be logged in to comment on an idea.
Find out more about our Provider Spotlight
Less.php: less.js ported to PHP