I just moved my site from one host to another, and upgraded to ZP 1.4.0 in the process.
I have some scripts that link to an image through some ZP mod_rewrite magic:
http://domain.tld/gallery/album-name/image/image-file-name.jpg
and
http://domain.tld/gallery/album-name/image/thumb/image-file-name.jpg

The pointer to the full image just redirects endlessly to:

http://domain.tld/gallery/albums/albums/albums/albums/albums/album-name/image/image-file-name.jpg and then Chrome stops after having been redirected to "/albums.." about 20 times.

When pointing to the thumb pointer nothing happens, well chrome tells me the link is broken. IE and FF just shows nothing.

When accessing the images directly or through the zp-core/i.php script (which is the on the mod_rewrite just points to anyway) then it works fine.

Please someone, help. I'm not sure if it's an issue with 1.4.0 or something else. All I did was take down the old host, install ZP on the new with the same Default theme and only added some pictures. Can't check the old site any longer since I already took that down.

You have exactly followed the instructions to move your install on our troubleshooting? Is it installed correctly, did setup report anything?

First I moved WordPress 3.0.4 to the root "/" of my new host along with the database.

Then I did a fresh install of ZP 1.4 to the "/gallery" folder of my new host. Nothing was re-used from the old host. All pictures were re-uploaded for re-indexing/caching.

Setup only reported that I was recommended to set mbstring.internal_encoding to UTF-8, which I have done by adding the following to the top of the "/gallery/.htaccess" file (before the [IfModule mod_rewrite.c]):
[IfModule mod_php5.c]
php_value mbstring.internal_encoding "UTF-8"
[/IfModule]
[IfModule mod_php4.c]
php_value mbstring.internal_encoding "UTF-8"
[/IfModule]

less-/greater than replaced by square brackets in this post.

The way I found the problem is because I have made a few additions to my WP which links to images in the ZP using the http://domain.tld/gallery/album-name/image-name.jpg.

When they just showed as "image not found" placeholders I attempted to open the images directly using the same path, and that is when Chrome reported the "Too many redirects" error, where it keeps redirecting to the same URL just with "albums" continuosly pre-pended as mentioned in my first post.

The effect you are seeing would tend to indicate that something is now working in the mod_rewrite handling. Since the UTF-8 encoding is not critical unless you need non-English support I suggest you first try a "vanila" Zenphot .htaccess file and see if the problem exists.

If not, then something in your change caused the problem. (Although I would not know what.) The mbstring_internal encoding can also be set in your PHP.ini file, avoiding changing the .htaccess.

First, thanks for taking the time to help me out...

Okay, so I thought I would start from scratch, so I removed the entire ZenPhoto installation from my "/gallery" folder, except the "albums" folder (so I didn't have to re-upload all the pictures. I also removed all the zp_ tables from MySQL.

I then proceeded to download the ZP 1.4 .zip package. Unpacked it on my Windows 7 computer using 7-zip. Then I uploaded it all using FileZilla.

Running the setup I ignored the mbstring.internal_encoding warning (warn: PHP mbstring package [Your internal character set is EUC-JP] Setting mbstring.internal_encoding to UTF-8 in your php.ini file is recommended to insure accented and multi-byte characters function properly.). I also created the "charset.tést" folder so ZP could check the filesystem charset (The Zenphoto filesystem character define is ISO‑8859‑1 [confirmed]). Last time I just forced UTF-8.

So now I have a complete default install, no changes to any files. Still the same problem :-(

Also, I don't have access to php.ini since it's a shared host, which is why I need to do the ini changes either through PHP's ini_set function or through .htaccess.

Took a look in the Apache log from my webhost and plucked out the relevant details for the issues I'm experiencing. I've anonymized the log entries.
http://pastebin.com/TMSepagf

What I'm doing is that I'm first browsing the gallery normally, which is shown by the call to i.php. That then is redirected to the image page.

Then I manually modify the URL to the "image", and as can be seen the Webserver keeps giving me 302's (temporarily moved).

A quick look in the rewrite rules in .htaccess shows that it's only doing 301's (permanently moved).

So a quick grep -r 302 * shows me that only 2 files actually do 302 redirects; zp-core/admin-functions.php and zp-core/zp-extensions/seo_locale.php . I haven't activated seo_locale extension, not even just to try it out.

So basically I'm still at a loss

Hope it tells you something and perhaps could help with a solution.

Is the install available for WEB access? I'd like to look at it.

I don't see anywhere that Zenphoto would be adding "albums" into the URIs. The .htaccess simply changes it to album=...image= URI syntax.

There is a function is `functions-controller.php` named `fix_path_redirect` that might be involved. It has some code:
`
if (strlen($sfx) > 0 && in_context(ZP_IMAGE) && substr($request_uri, -strlen($sfx)) != $sfx ) {
$redirecturl = zpurl(true, NULL, NULL, NULL, $params);
header("HTTP/1.0 301 Moved Permanently");
header("Status: 301 Moved Permanently");
header('Location: ' . FULLWEBPATH . '/' . $redirecturl);
exit();
}
`
that we can change to let us know if it is the culpret.

Just add a line:
`debugLog("sfx=$slf; request_uri=$request_uri");` after the if statement. This will put some debugging information into the debug log. Please report the results.

Just saw your post with the log. From it the problem seems to be comming from loading the full image directly. Is that something your theme or access from Wordpress does? Still do not know why the redirect loop, but maybe something in the WP .htaccess? Can you try without any .htaccess files except the Zenphoto ones?

I'm assuming it's the Debug Log in the Admin interface where the entries should show? Nothing got added to this log. The actual Apache logs is a bit of a hazzle to get access to, because I have to contact my friend who then zips and sends them to me, as I don't have access to the folder where they are stored.

Tried renaming the .htaccess for the WP install. Checked that it no longer were used by accessing a sub-page, which would normally be rewritten into index.php?some=arguments&page=to-be-loaded or some such. Got a 404 wich was confirmation enough that the WP .htaccess no longer were used. Issue with the redirects in ZP didn't get resolved

Whenever I link to pictures in my ZP install I prefer to use the "pretty" URLs that is rewritten rather than a pointer to i.php, even though the end result is the same, so it's intentional that I link to the image that way. Especially links to the thumbnails looks a lot prettier this way, although now I get 404 when I attempt to link to the /gallery/album-name/image/thumb/image-name.jpg.

You can see the actual installation here:
http://briped.net/gallery

Just to try it, I just installed an older version (1.2.8) in /zenphoto subfolder for testing (with another table prefix as well). Redirects works exactly as I am used to, no issues here.

You can try using the .htaccess file from 1.2.8 and see if that makes a difference. RSS will not work with it, but if it fixes the other problem at least we have a clue.

I do not see how the 1.4 changes would have made the problem, though.

Do these loops occur only with that external URL?

The .htaccess from 1.2.8 doesn't solve the issue, and I did remember to change the RewriteBase to the correct folder.

Even tried renaming the /gallery folder to /zen and likewise correct the RewriteBase to /zen, just to check if there were something that just made a mess out of the /gallery folder. Still no solution.

Out of pure desperation I just tried deleting the seo_locale.php file just to see if that is what was causing the odd redirects even though it wasn't activated. Didn't do anything

Thanks.

I have found the problem. Fix is at http://www.zenphoto.org/trac/attachment/ticket/1776/

Superb, it works now. Thanks a ton