Member
I am beginning to use ZenPage as a graphics manager for my website. Since my intended users are not necessarily technically inclined (think, "oh, that size looks good"), I need to provide a few tweaks for them.
Bug #1703 was the first: give them a list of about 15 or so pre-defined sizes.
My next 2 are a little bit different in nature. The first that I would like to tackle is giving my users an easier way to get the image URL. I plan on creating a plugin that does this. Here's where the question comes in.
Rather than re-creating a bunch of code from i.php, I think it would be handy for i.php to have the option of creating the cache image (if it doesn't exist) and then spit out the relative URL of the image. It honestly doesn't look that hard, since the debug code can already do this.
There are also some added benefits to this for viewer_size_image. You would be able to use some ajax code like "$.ajax( url: i.php?a=blah&...&u=true; success: function (data) { $('#image').attr(src) = data; } );"
I just wanted to bounce this idea before I worked on my own code. If this functionality isn't desirable, I could probably include i.php in my plugin. I thought that others would find this useful, as well, so it might be worth a change.
Bug #1703 was the first: give them a list of about 15 or so pre-defined sizes.
My next 2 are a little bit different in nature. The first that I would like to tackle is giving my users an easier way to get the image URL. I plan on creating a plugin that does this. Here's where the question comes in.
Rather than re-creating a bunch of code from i.php, I think it would be handy for i.php to have the option of creating the cache image (if it doesn't exist) and then spit out the relative URL of the image. It honestly doesn't look that hard, since the debug code can already do this.
There are also some added benefits to this for viewer_size_image. You would be able to use some ajax code like "$.ajax( url: i.php?a=blah&...&u=true; success: function (data) { $('#image').attr(src) = data; } );"
I just wanted to bounce this idea before I worked on my own code. If this functionality isn't desirable, I could probably include i.php in my plugin. I thought that others would find this useful, as well, so it might be worth a change.
Member
Not sure I understand. First, URLs are already separated from i.php. The i.php script is simply the image processor. It is only used when there is no cached version of the image, and is used to create that cached version.
Depending on what you really mean by the image URL, there are several functions to investigate. First and probably best depending would be the image object methods. `$imobj->getCustomImage();` would be the most likely candidate.
There is also `getImageCacheFilename()` for just the cached version. If you just want to create the image, then look at the `cacheImage()` function. There certainly would never be a reason to include [i]i.php[/i] in your script as that is only intended as an asynchronous means of creating the cache image.
Not exactly sure where you are going with the [i]viewer_size_image[/i] bit. What is not happening correctly with the way it is done now?
Depending on what you really mean by the image URL, there are several functions to investigate. First and probably best depending would be the image object methods. `$imobj->getCustomImage();` would be the most likely candidate.
There is also `getImageCacheFilename()` for just the cached version. If you just want to create the image, then look at the `cacheImage()` function. There certainly would never be a reason to include [i]i.php[/i] in your script as that is only intended as an asynchronous means of creating the cache image.
Not exactly sure where you are going with the [i]viewer_size_image[/i] bit. What is not happening correctly with the way it is done now?
Member
Correct me if I'm wrong, but calling i.php eventually redirects you to the cached image - generating the cached image if necessary. In my mind, sending the browser a URL rather than redirecting and then returning the image is a better idea. This is for my purposes, but I can see other applications where it would be useful. My basic argument is that it makes i.php more AJAX friendly.
Trust me when I say, I realize that AJAX isn't the end-all and be-all of the website development world, but I think this use case makes quite a bit of sense when you consider the appropriate uses of it.
For my intentions - displaying an image url to the user - it would be easier if i.php returned an HTML message rather than an image object. Then, if I'm interested in the image object, I can use that in the browser DOM to have the browser go out and grab the image.
So, for example, viewer_size_image javascript could be changed into a jQuery AJAX call. The html message could, then, contain an error message or an image tag (eg, <p>This is why I didn't return an image</p> or <img src=/my/image/cache.jpg" />). Then I use the message to either display the image or the error. Then, if there's an error, I get an error message rather than an image that doesn't display (eg - when I select an image size that is out of bounds).
I could write a second plugin that does this exact thing, but I would just be duplicating i.php and, instead of redirecting, returning a URL or error message.
Trust me when I say, I realize that AJAX isn't the end-all and be-all of the website development world, but I think this use case makes quite a bit of sense when you consider the appropriate uses of it.
For my intentions - displaying an image url to the user - it would be easier if i.php returned an HTML message rather than an image object. Then, if I'm interested in the image object, I can use that in the browser DOM to have the browser go out and grab the image.
So, for example, viewer_size_image javascript could be changed into a jQuery AJAX call. The html message could, then, contain an error message or an image tag (eg, <p>This is why I didn't return an image</p> or <img src=/my/image/cache.jpg" />). Then I use the message to either display the image or the error. Then, if there's an error, I get an error message rather than an image that doesn't display (eg - when I select an image size that is out of bounds).
I could write a second plugin that does this exact thing, but I would just be duplicating i.php and, instead of redirecting, returning a URL or error message.
Administrator
1. The page is not redirected, the processor internally checks if the image is cached. If not it does this (Zenphoto only does this on request/discovery of new images). Otherwise the url of the cached image is given. It does not return an "image object".
2. You are confusing the image url. The full image you upload in the albums folder is not the url you get. For this there are also functions.
I fear I don't understand your problem as well with the user sized image. You can of course make your own version of that plugin.
I guess you concern is to switch the image size without page reload. That is quite easy actually. Store the image urls in a JS array and just switch that using jQuery. The cached image will then be generated on request if it does not exist already.
2. You are confusing the image url. The full image you upload in the albums folder is not the url you get. For this there are also functions.
I fear I don't understand your problem as well with the user sized image. You can of course make your own version of that plugin.
I guess you concern is to switch the image size without page reload. That is quite easy actually. Store the image urls in a JS array and just switch that using jQuery. The cached image will then be generated on request if it does not exist already.
Member
Yes, you are basically wrong. First, you cannot "call" i.php. It is a script, not a function. Second, URLs are generated referencing i.php only when there is no cached version of the image existing. i.php creates the cache version and then serves the image.
As to your idea for viewer sized images. Seems mostly pointless. i.php returns errors only in debug mode. Errors will occur normally only when there is insufficient memory to process the image resize. In this case pretty much all references to that image will fail, including the thumbnail and any sized image to be shown in the first place. So the error report (if you could get such) from i.php would be pretty much secondary.
Finally, there is a general rule of thumb in software known as KISS--keep it simple stupid.
As to your idea for viewer sized images. Seems mostly pointless. i.php returns errors only in debug mode. Errors will occur normally only when there is insufficient memory to process the image resize. In this case pretty much all references to that image will fail, including the thumbnail and any sized image to be shown in the first place. So the error report (if you could get such) from i.php would be pretty much secondary.
Finally, there is a general rule of thumb in software known as KISS--keep it simple stupid.
Member
I was not clear on what I was saying, I apologize.
For my application, I wanted to generate the image and then pass the URL to the user. Your JS array will absolutely work for my needs. I just need to grab the image sizes and call getImageCacheFilename() for each image size. After that, I can rehook the onclick function for the radials (or selector). My problem is solved.
As to my original question of having i.php having an option to return a URL to a cached image:
Where this would come in handy would be in applications like viewer_size_image. Currently, after the swap occurs, there is a several second delay before the browser loads the new image. If you're upsizing (say from 100px to 500px), you get the 100px image until the 500px image is generated and then downloaded by the browser.
My thought was that if i.php could notify the browser when it was finished generating the image, that would cut out the delay where a user sees a terrible looking up-scaled image. To me, this is a better user experience than seeing the up-scaled image (even if it is only for a short time). To really make it complete, the image could be swapped out for a loading graphic until i.php completed.
If you think the idea is ridiculous, you can stop reading here. I agree, there is more than one way to skin a cat and my way of skinning isn't necessarily any better.
In order to get this functionality, one currently has to make a jQuery ajax() to call i.php.
The way I read lines 225 & 226 of i.php, i.php always exits with a 301 redirect (except in debug mode). Because XmlHttpRequest (XHR) handles 301 redirects by following them without notifying the browser. This means that the image gets returned to the DOM [b]as data[/b].
This is problematic for several reasons:
[list]
[*]The image, as data isn't useful and gets tossed immediately
[*]You could end up transferring several megabytes of useless data
[*]
[*]The browser javascript engine will end up with the image as data, which can cause the browser to choke - especially on low-memory machines like netbooks
[/list]
What I was suggesting would not be to functionally change i.php, but to have i.php exit without redirecting when called with a specific argument (similar to the way debug currently works). Since we would already be forcing i.php to run, it might as well output something and my thought was to have i.php exit by outputting $path (from line 204).
I hope that this makes much better sense to you.
For my application, I wanted to generate the image and then pass the URL to the user. Your JS array will absolutely work for my needs. I just need to grab the image sizes and call getImageCacheFilename() for each image size. After that, I can rehook the onclick function for the radials (or selector). My problem is solved.
As to my original question of having i.php having an option to return a URL to a cached image:
Where this would come in handy would be in applications like viewer_size_image. Currently, after the swap occurs, there is a several second delay before the browser loads the new image. If you're upsizing (say from 100px to 500px), you get the 100px image until the 500px image is generated and then downloaded by the browser.
My thought was that if i.php could notify the browser when it was finished generating the image, that would cut out the delay where a user sees a terrible looking up-scaled image. To me, this is a better user experience than seeing the up-scaled image (even if it is only for a short time). To really make it complete, the image could be swapped out for a loading graphic until i.php completed.
If you think the idea is ridiculous, you can stop reading here. I agree, there is more than one way to skin a cat and my way of skinning isn't necessarily any better.
In order to get this functionality, one currently has to make a jQuery ajax() to call i.php.
The way I read lines 225 & 226 of i.php, i.php always exits with a 301 redirect (except in debug mode). Because XmlHttpRequest (XHR) handles 301 redirects by following them without notifying the browser. This means that the image gets returned to the DOM [b]as data[/b].
This is problematic for several reasons:
[list]
[*]The image, as data isn't useful and gets tossed immediately
[*]You could end up transferring several megabytes of useless data
[*]
[*]The browser javascript engine will end up with the image as data, which can cause the browser to choke - especially on low-memory machines like netbooks
[/list]
What I was suggesting would not be to functionally change i.php, but to have i.php exit without redirecting when called with a specific argument (similar to the way debug currently works). Since we would already be forcing i.php to run, it might as well output something and my thought was to have i.php exit by outputting $path (from line 204).
I hope that this makes much better sense to you.
Administrator
The delay you notice is actally the delay the server requires to generate the cached image. That delay only happens once until the image is generated and cached. The bigger the dimensions of your images and the less powerful your server the more that might take.
Regarding the js array way. I am not sure why you call `getImageCacheFilename()` at all. I have never used that function in any themes/sites I made. Just use an array with what one of the `customsize` image functions return. It might even be better to store the full `<img>` tag so you can replace the image you want to swap via jQuery.
For a loading graphic you can for example attach a background image to the image.
Sorry, if I maybe still not completely understand the issue. I admit I am not too familiar with the i.php internal stuff itself.
Regarding the js array way. I am not sure why you call `getImageCacheFilename()` at all. I have never used that function in any themes/sites I made. Just use an array with what one of the `customsize` image functions return. It might even be better to store the full `<img>` tag so you can replace the image you want to swap via jQuery.
For a loading graphic you can for example attach a background image to the image.
Sorry, if I maybe still not completely understand the issue. I admit I am not too familiar with the i.php internal stuff itself.
Member
Bottom line: you really want to use the image url functions and not mess around. If you load i.php directly you have forced always to run the processor even when there already exists a cached version of the image. Of course, using getImageCacheFilename() directly works only if the image has been cached. Really now, do you think that you will better know what has happened/is going on than Zenphoto does?
Using Ajax does not make i.php process more quickly than when the browser fetches the "image" it refers to. Of course, if the image has already got a cache version, your technique will cause the delay but the used method will just load the image without delay.
Of course, if you know better how Zenphoto works than we, by all means, do your best.
Using Ajax does not make i.php process more quickly than when the browser fetches the "image" it refers to. Of course, if the image has already got a cache version, your technique will cause the delay but the used method will just load the image without delay.
Of course, if you know better how Zenphoto works than we, by all means, do your best.