We need some testers!

trisweb

@bitbybit - Thanks immensely for the bug reports, that's a huge help. Yes, I do need to work on garbage collection bigtime, and test things out with duplicate/extra entries lying around as well. Zenphoto shouldn't choke regardless of what's in the database.

Glad to hear sharpening is working. I've set it pretty low by default, but that'll eventually be in zp-config.php as well.

The setup/upgrade problems have been resolved; I moved the adding of those backticks to the prefix() function, so the table names were getting double-backticked. I've removed them and the latest SVN's setup/upgrade should now work.

Those last two items are expected behavior. The theme.txt is where the current theme is stored, so without it, zenphoto doesn't know what theme you set and has to go back to the default. That will be moved to the database with an options screen in the admin in 1.1 or 1.2. Images in the root /albums folder aren't displayed because they're not in an album, so that's expected as well. Let me know if you think they should be shown somewhere, like in a "Root" album or something.

bitbybit

Rev 363 setup.php working great

Regarding root images, it seems more intuitive to me that all images in /albums and below should be displayed somehow. I would tend to lean towards having /albums be a pseudo-album itself, meaning that any photos located in /albums would be displayed when visiting blah.com/albums/, along with the subalbums also located there.

I'm definitely not married to to that solution though. Anything that would avoid the blackhole that is currently an image in the /albums root dir would be good And certainly a low priority request at that :P

trisweb

Yeah, I'd say the requirement of images to be in albums is pretty clear and makes sense, so I'll stick with that for now...

thinkdreams

Here's an interesting one that I just noticed:

Why would this function output incorrect URLs? The URL is structured like:
http://www.bushwoodworking.com/zenphoto/projects/bushwoodshop/dirtcheapcabinets/IMG_2908.JPG

and the function:

`function getURL($image) {

if (zp_conf('mod_rewrite'))

{

return WEBPATH . "/" . urlencode($image->getAlbumName()) . "/" . urlencode($image->name);

}

else

{

return WEBPATH . "/index.php?album=" . urlencode($image->getAlbumName()) . "&image=" . urlencode($image->name);

}

}`

I'm running Rev 363 from SVN.

thinkdreams

Bingo. urlencode was screwing up the paths on the mod rewrite. this works better:

`function getURL($image) {

if (zp_conf('mod_rewrite'))

{

return WEBPATH . "/" . $image->getAlbumName() . "/" . urlencode($image->name);

}

else

{

return WEBPATH . "/index.php?album=" . urlencode($image->getAlbumName()) . "&image=" . urlencode($image->name);

}

}`

Any other glaring errors that are noticeable? Should I remove urlencode entirely from the mod_rewrite section?

trisweb

I've got a `pathurlencode()` function for that very purpose (splits by / before urlencoding), I just forgot it there. I'll add it and check it in later.

On a side note, how you you guys feel about using a different character for spaces in the URLs? I'm tired of seeing all those %20's, it's rather messy. The idea would be to convert the URL's in the link functions, then when looking at the paths, look for a folder with the exact name first, then one with the space character (probably a dash `-`) replaced with spaces. Should cover all the bases.

trisweb

Is that a custom function Craig? I can't find it...

In any case, it should look like:
`return WEBPATH . "/" . pathurlencode($image->getAlbumName()) . "/" . urlencode($image->name);`

thinkdreams

Yup. It's part of the random image function. It's used in my themes, grabbed it off the forums here a while back, and Stephane also uses it in her Effervescence theme. I'll make sure to update her as well for future reference. If you have another function that accomplishes the same goal I'd be glad to use that instead and have less custom functions floating around....

Do I need to use that pathurlencode for the non-mod-rewrite option in that function as well? Didn't test it with mod_rewrite off yet.

And I'm cool with another character for spaces. I'm of the same opinion that the %20 looks kind strange.

thinkdreams

Here's a snippet from Effervescence so you can see what I mean:

`

<?php $randomImage = getRandomImages(); $randomImageURL = getURL($randomImage); print "<a href='".getURL($randomImage)."' title='Random Picture...'>getCustomImage(1000, 620, 180, 620, 180, 300, 300)."' alt='".$randomImage->getTitle()."' />"; ?>

`

bitbybit

You've got my vote for replacing %20s with dashes. I'm all for prettiness Along that line, maybe strip out all non-alpha numeric characters from the url too (a la wordpress)? Though maybe that'd cause potential url conflicts/issues? Hrm.

S'more useless oddities for you I noticed if you create two peer directories named the same but using different case (why anyone would want to do this is beyond me...), it lowercases them both in the album display.

I told you it was useless!

trisweb

Do they both show? Haha, I guess I can test that... *nix servers only, correct? Windows won't let you do that...

Anyway, why would anyone want to do that? like you said. :-) I'll leave it at that.

bitbybit

I figure it's my job to try and think up wacky things that some users might do and report back if I notice strangeness about it

Yup, they both show as lowercase - as soon as you change the name of one of them, the case settings return to the other. Some flavor of linux on my webhost in this case - I assume windows will just bark at the directory creation/renaming :P

trisweb

Yep, windows doesn't even let you do it. Eh, as long as they both show up I think that's fine. It's probably using the same database entry for both of 'em, so that's why one gets the case of the other. I'll take a look someday if I remember, otherwise I really don't think it's a big deal.

Thanks for being so thorough, seriously!

aitf311

The newest SVN gives me this error while trying to hit the root index:

Fatal error: Cannot redeclare geturl() (previously declared in /home/.mairona/aitf311/zp/zen/functions-controller.php:60) in /home/.mairona/aitf311/zp/zen/functions-custom.php on line 208

trisweb

@aitf311 -- functions-custom.php isn't any file I include with zenphoto.... ;-) Looks like there's a function name conflict there. I'll just rename the function in Zenphoto to avoid this problem for others.

trisweb

Done.

aitf311

Thanks tris. Problem fixed.

trisweb

FYI to all, I just did some major refactoring of the request controller, so I'd appreciate lots of navigation testing on the SVN code.