Thanks for the update.  Here is my new debug information:

I am using

to call the plugin.

Still not working, but hopefully this will narrow down the problem.  I already tried to remove the double “//” in img_rootstep, but that still did not work.  Thanks for your persistence in helping to get this working on my site.

I just figured out that $img_rootstep is calling the wrong path.  It should call “/usr/www/gm/public_html/ee/images/feature_photos”.  Instead it is calling “/usr/local/apache/htdocs//gm/ee/images/feature_photos” I was able to get a resized image hard-coding the path.  Is there any way to make the plugin call “/usr/www/gm/public_html/ee/images/VARIABLE_IMAGE_DIRECTORY”?  I have limited PHP knowledge, but it seems like it should be pretty simple. This is going to be an invaluable plugin for my site…so glad I’m getting it to work!

I would imagine that {feature_photo} is coming from a {filedir_1} like variable in your publish page?

the filedir variable is set by your “URL of Upload Directory” in the Control Panel
CP Home › Admin › Weblog Administration › File Upload Preferences › Edit File Upload Preferences

the way i have it setup is so the paths are relative to my install of EE

for instance
Server Path to Upload Directory = “../images/uploads/”
URL of Upload Directory = “images/uploads/”

as you can see in the error output img_rootstep i am appending the input to the src= to the root directory of your htdocs

so “/usr/local/apache/htdocs//gm/ee/images/feature_photos”
would look for the photo at this location after it removes the double slashes
“/usr/local/apache/htdocs/gm/ee/images/feature_photos/secs_state-24414-381_575.jpg”

so try changing your file upload preferences to be
Server Path to Upload Directory = “../images/feature_photos/”
URL of Upload Directory = “images/feature_photos/”

Hi David (and others!) I’ve just come up against an unusual problem. I had the imgsizer plug-in installed and all was working well. I’ve since made a few changes to my set up, installed CURL on the server and installed the eeFlickr Module. Because of some problems elsewhere I have also cleared the EE cache both via the CP and manually.

Shortly after this I noticed that wherever I was using the imgsizer plugin that nothing was being displayed, no img tag at all. So I added debug=“1” to the params and I get back:

This is odd because I have done a sanity check, the image ‘is’ there and even when I hard code the URL I have the same problem. I have even tried turning off caching. I did wonder if I had somehow inadvertently not included GD in the PHP build when I installed CURL but PHP info is reporting it as available (http://wiredin.org.uk/test.php).

Any ideas?

*Update* Having read back a few posts I see that I’m having the very same problem as others here and will try the latest build with the extra debug info.

Ok, very odd. I downloaded the revised plug-in and installed it. Was distracted for 30 mins or so, came back and all is good.

Hi David,

I turned the debugging on and have discovered that the img_rootstep is wrong (output below).
It should be /something/web/mac/images/alumni/profiles.

I read what you advised for Derek, but that won’t work for me because our images aren’t uploaded to the file upload area. We have a photo gallery set up and then use a relationship field in EE to link to the picture.

Eg:

  src = /mac/images/alumni/profiles/Veamatahau_Adrian_72.jpg
  img_base = /mac/images/alumni/profiles
  img_basename = Veamatahau_Adrian_72.jpg
  img_extension = jpg
  img_filename = Veamatahau_Adrian_72
  img_rootstep = /something/web/alumni//mac/images/alumni/profiles
  img_rootpath =
  img_fromroot = /Veamatahau_Adrian_72.jpg
       

/Veamatahau_Adrian_72.jpg is not readable

I was able to solve my problem today. Hopefully this will help some others who were having the same problem.

The first step was to re-assign the DOCUMENT-ROOT in EE’s path.php file. (Thank you mdesign - see post). I added the following to the CONFIGURABLE VARIABLES:

Because my install is in a subfolder, img_rootstep was then calling:

I needed to remove the “/gm” after “public_html” in order to get the plugin to find the correct path.

Back in pi.imgsizer.php, I had to make a slight adjustment to the code at line 158.  I created a new variable from $img_base called $img_base_edit which removed the first 3 characters from the string (/gm).  Then, in the following line, I changed $img_base to the new variable $img_base_edit.

Everything seems to be working fine now.

Hello and thanks for this great plug-in!

Is there a reason why

is not working on my side? Is there anything I would be doing wrong with this parameter?!

I actually found what’s going on:

If say - I have:

...then later if I decide to have a grayscale version of the same image - the above code won’t return a grayscale unless cache is set to “yes” - which will replace already cached (colored) images from the very first code.

thus, having:

this WILL return a greyscale…

then you can remove cache=“yes”...

I guess a good way to “fix” the greyscale parameter, would be for it to create a chached version of the same image with a ‘x’ letter added to it. In other words: greyscale parameter creates cached version in the following matter - rotarylogo-80x80g.jpg (adding the letter ‘g’ at the end of the filename - this way you don’t have to fiddle with the cache=“yes/no” parameter.

...agree?

lumis - 18 July 2008 12:40 PM

the way i have it setup is so the paths are relative to my install of EE

for instance
Server Path to Upload Directory = “../images/uploads/”
URL of Upload Directory = “images/uploads/”

as you can see in the error output img_rootstep i am appending the input to the src= to the root directory of your htdocs

so try changing your file upload preferences to be
Server Path to Upload Directory = “../images/feature_photos/”
URL of Upload Directory = “images/feature_photos/”

Hi Lumis. Thanks for the great plug-in! Thanks also to those of you trying to resolve server path issues…

Lumis’ above advice was useful, but I am using a university server for the first time for a new site. I also get the ‘image not readable’ error.

You access us from a URL with the dreaded tilde.

http://www.arts.university.ca/~ourfolder

I guess this is something like running in a subdirectory, but if I try to mess with the configurable variables in path.php I get an error no matter what I change it to. Perhaps because we are in a folder within a subdomain? Ugh.

The server path to my web directory is thus like this:

and the file upload folder

Rather than this folder, /Users2/ourfolder/web-docs/img/events/, it wants to produce

If I try to make my server paths to the file upload folder relative to the EE folder, as Lumis has described above, I get

If I try Derek’s touch-up to the code, I seem to get an even longer string in img_rootstep… ugh, I think I need to go and look at the paths with fresh eyes tomorrow.

Just wanted to post a very quick reply to say GREAT BIG THANKS for writing this plugin!

This will replace a lot of cumbersome code I have written in the past…

Hey Lumis, any chance of getting this to play nice with Extract URL or doesn it not work like this -

You can add parse=“inward” to imgsizer OR use this code:

‘extract_url’ and ‘html_strip’ are plugins

So this should work?

stinhambo - 30 July 2008 08:15 PM

So this should work?

{exp:imgsizer:size image="{exp:extract_url}{artists_works_piece}{/exp:extract_url}" width="140" alt="{title} {gallery_year}" parse="inward"}

“Should” work..

Nope it doesn’t :(

parse=“inwards” doesn’t seem to be listed on the plugin site page now.

stinhambo - 30 July 2008 08:26 PM

Nope it doesn’t :(

parse=“inwards” doesn’t seem to be listed on the plugin site page now.

Then try my other suggestion that does work

I assume that if I use the custom fields from my template and utilise your example I get -

What is the {field}{/field} tag pair?