FORUMS CLOSED DUE TO SPAM. YOU STILL CAN ADD POST!

New Plugin: Image Resize

Feed 47 posts, 13 voices

Avatar
29 posts

Thanks Mika, this looks great! I’ll have a look at this later this week and will certainly merge it back.

 
Avatar
29 posts

I merged in Mikas changes, so image_resize now allows you to crop images to any size. Thanks again!

 
Avatar
1 posts

The image resize breaks, if you have a custom page not found page setup. How can you fix this?

 
Avatar
29 posts

I’ll look into this next week, at the moment I’m enjoying the snow and the mountains :)

 
Avatar
8 posts

Hi Guys,

This appears to be broken with the current .htaccess that is bundled with Frog CMS 0.9.5 RC1, I’ve modified my local copy of the index.php in the plugin folder for Image Resize. I’ve added the following line:

$path = ltrim($path,‘QS=’);

to function image_resize_try_resizing() before image_resize_scale($path); so it now looks like:

function image_resize_try_resizing() {
    $path = $_SERVER['QUERY_STRING'];
    if (preg_match('#^.+\.(jpg|jpeg|gif|png)$#i', $path)) {
        // If requested file is an accepted format, resize and redirect 
        // to the newly created image.
	$path = ltrim($path,'QS=');
	image_resize_scale($path);
        header('Location: '. URL_PUBLIC . "/" . $path);
        // Exit here to prevent a page not found message
        exit();
    }
}

This stops a nasty infinite loop occuring in your browser, caused by this entry:

RewriteRule ^(.*)$ index.php?QS=$1 [L,QSA]

in the .htaccess file.

Basically, it removes the QS= which is prefixed to the returned QUERY_STRING.

 
Avatar
8 posts

Fixed: Custom “page not found” conflict with Image Resize

Replace the existing code for page_not_found (index.php):

function behavior_page_not_found()
{
    global $__FROG_CONN__;

	/*
	 *	added: test for valid image_resize request; code block copied and modified from image_resize
	 */
	$path = ltrim($_SERVER['QUERY_STRING'],'QS=');
	$params      = explode("/", $path);
	$namepart    = array_pop($params);
	$isValidResize = false;
    if (preg_match('#(.+)\.([0-9]+)x?(c?)\.([a-z]+)$#i', $namepart, $match)) {
		$isValidResize = true;
    } else if (preg_match('#(.+)\.x([0-9]+)(c?)\.([a-z]+)$#i', $namepart, $match)) {
		$isValidResize = true;
    } else if (preg_match('#(.+)\.([0-9]+)x([0-9]+)(c?)\.([a-z]+)$#i', $namepart, $match)) {
		$isValidResize = true;
    }

	/*
	 * if following condition not met, then allow the image_resize observer to kick-in
	 */
    if (!preg_match('#^.+\.(jpg|jpeg|gif|png)$#i', $path) || !$isValidResize) {
		/*
		 * No request for resizing image; resolve original request for page_not_found
		 */
		$sql = 'SELECT * FROM '.TABLE_PREFIX."page WHERE behavior_id='page_not_found'";
		$stmt = $__FROG_CONN__->prepare($sql);
		$stmt->execute();

		if ($page = $stmt->fetchObject())
		{
			$page = find_page_by_uri($page->slug);

			// if we fund it, display it!
			if (is_object($page))
			{
				header("HTTP/1.0 404 Not Found");
				header("Status: 404 Not Found");

				$page->_executeLayout();
				exit(); // need to exit here otherwise the true error page will be sended
			}
		}
	}
}

Basically, we test if we have a valid image_resize request, if we don’t then we pass control onto the custom page_not_found handler.

 
Avatar
29 posts

Thanks a lot sc00t3r, I included your patch for the new rewrite rules (but didn’t test it yet as I just don’t have the time right now). As for the “page not found” patch: that seems to be somewhat bigger and the Frog API seems to have changed (behavior_… function), so I should certainly test this first before committing it. I’ll see if I find some time, but if you want to you can also fork the project on GitHub and send me a pull request. If you’ve never been there: it’s quite easy and they have some good documentation.
Well, yeah, I see that I should upgrade my Frog system and keep up do date :)
Thanks again,
Peter

 
Avatar
7 posts

The above patch for image_resize plugin will not work in future versions of Frog. Currently on SVN there is a change of how FrogCMS deals with $_GET variables, and there isn’t a QS variable anymore in last SVN version of FrogCMS, it was changed to PAGE. In order to be sure that the plugin will work in future versions of Frog use a predefined constant CURRENT_URI instead of using a query string and stripping a QS= from it.

Change to:

$path = CURRENT_URI;
 
Avatar
8 posts

Thanks for the info, is there a definitive list of global variables and a brief description of what purpose they serve? This will undoubtedly help developers to avoid implementing “band-aid” solutions.

 
Avatar
291 posts

Fixed: Custom “page not found” conflict with Image Resize
Replace the existing code for page_not_found (index.php):

This code is for page_not_found plugin not image_resize plugin. IMO the conflict should be resolved in image_resize.

 
Avatar
291 posts

I made two quick patches. As suggested by shamil.si use CURRENT_URI to fix compability issues between 0.9.4, 0.9.5 and svn. Tested with 0.9.4 and svn.

Second one fixes infinite loop when trying to resize nonexistent image.

 
Avatar
8 posts

If the page_not_found plugin is the first one to intercept the 404 condition, then the image_resize request would never get triggered regardless of a (non-)existing image is resized or not.

Basically, do we need some rules to be defined to dictate the processing order of Observer events?

I’m not yet familiar with how the “Observer” works nor how it gives priority to plugins hooking into the Observer controller. But from what I understand, it looks like it’s stacking the requests.

Therefore the fix in image_resize is only one half of the overall problem …. or am I confusing things somewhat?

 
Avatar
291 posts

Changing code in plugin A to change behaviour in plugin B is a way to unmaintainable mess. Later there will be plugins C, D, E, F, G and H who also want to have plugin A to include code for their special cases.

 
Avatar
651 posts

@scoot3r – the observer system does not work with priorities. Basically you’re trying to override the page_not_found plugin when a page can’t be found… either don’t use the page_not_found plugin or add a little php code to the custom page_not_found page that activates the image_resize plugin?

prioritizing events will make the system prohibitively complex.

 
Avatar
29 posts

I incorporated the patches by tuupola (thanks a lot!) and tested the plugin with Frog 0.9.5 RC1. Everything should work now… I also updated the documentation with an explanation of how to use the plugin with page_not_found.

According to this discussion we’ve had here and the input by Martijn it is probably the best solution to include some image resize code in your page_not_found page if you need to use both plugins. The code is as simple as this:

<?php image_resize_try_resizing() ?>
 
Avatar
291 posts

In order to be sure that the plugin will work in future versions of Frog use a predefined constant CURRENT_URI instead of using a query string and stripping a QS= from it.

BTW. It should be noted that CURRENT_URI is the URL without URL_SUFFIX. This might lead to some confusions.

 
Avatar
6 posts

Hi Guys,

I am having the familiar ‘white-boxes-problem’ with the Asset Manager in combination with the Image_Resize plugin. It is really just a problem of the image_resize plugin not creating the thumbnails.

I am on a local webserver (MAMP on OS X). Frog (0.9.5) is installed in a subdirectory (/frog_095/) my ‘assets’ folder is in my webroot (/assets/): so at the same level as /frog_095/.

MyPHP Version is 5.2.6, I have GD installed and ready (the image_resize plugin says all should work well).

I have chmodded the /assets/ folder to 777 but still the thumbnails are not created. Images are uploaded correctly and I DO see the asset manager, but with empty thumbnails (white boxes)…

I believe I have the latest versions of all plugins..

Any ideas? Thanks

 
Avatar
18 posts

@davidhund
I have a similar problem with the Image Resize plugin alone. Maybe this could help you..

“imagecreatefromjpeg” function is not defined in my server (even if GD is installed) and so jpg files are not saved. “imagecreatefromgif” and “imagecreatefrompng” work fine.

Try to make a blank page with this code:

<?php imagecreatefromjpeg(); ?>

and see what happens.
Maybe you have to contact your sys admin to fix the problem!

 
Avatar
29 posts

So, I’m finally commenting as well, sorry for the delay – there are just too many interesting things to do out there!

Well, I can’t replicate the blank thumbs bug on my machine, but it seems that azote is on to something. I digged deeper and found a PHP function called gd_info(), which tells you what stuff is supported and what’s missing. I figured I’d build this into the status page of image_resize.

So anyone having trouble with blank thumbs, please update to the newest version and go to it’s documentation page to see whether all libraries are supported. Maybe this is the source of the problem…

 
Avatar
291 posts

Excellent. I was playing with similar idea but instead writing a warning to flash after installing.

 
Avatar
29 posts

Announcement: Kirok made some fine refreshments and clean-ups, as well as some new functionality: improved sanity checks and a security improvement. Because it was possible for an attacker to bring down a server by repeatedly calling Image Resize on an image, you must now be logged in to be able to resize an image.

To upgrade, simply replace your old copy, there should be no problems.

Many thanks to Kirok!

 
Avatar
291 posts

Excellent stuff again. Big thanks to Kirok!

 
Avatar
35 posts

@davidhund See my post on Assets plugin, maybe it helps.