Sane integration of tricasa in zenphoto.

ulfben

I upgraded to trunk yesterday and have been fiddling with it for a good number of hours now.

I believe that the most important step for zenphoto now, is to make image flipping smooth (like slim/grey/light/dark/thick-box, simpleviewer or the tricasa hack) by default. By _default_ I mean that it must integrate nicely into the zenphoto structure of `index.php / albums.php / image.php` - which only tricasa manages (somewhat) so far.

Thus I integrated tricasa in the Default theme to see what needs to be done.

This works perfectly well:
Images are preloaded (and flipping between them is nothing short of impressive!).
Existing image descriptions are kept in sync with the images as we flip through.

These are the problems (and bugs):

• URL remain constant.
(refreshing and linking wont work properly)
• Tricasa always flips from the first image no matter what image you actually start at.
• Comments, tags and EXIF remains static and is never updated.
(eg. you'll always comment the first image you visit in a album, even if you're currently viewing another.)
• The image container size is static, so smaller images won't be centered.
(my default size is 800x600. A 600x800 image will be noticably missplaced at the far left side of the container)

The solution would be to make index.php an entirely ajaxified beast. With tricasa, we have images and descriptions fed to the page in realtime. If we had comments and EXIF data delivered like that too, we'd practically be done already. Of course, we need to keep the comment fields in sync too - so it adds comments to the correct image. (Perhaps a hidden field holding the image ID, so the server side comment code knows where to put it?)

I don't know if fiddling with the URL is within the powers of JS - but I could live without it anyway.

So... how difficult would this be to do? Is it possible at all?

####
My gallery offers a fairly big sample set to see how tricasa behaves. You're free to browse around of course, but here's a few usefull links to save you time:
Album with image description
Album with image comments.

ulfben

Here's a fix for issue #2; that tricasa isn't aware of where we enter an album.

function preLoadLores() {
fgdisplay = $('#imagemain1');
bgdisplay = $('#imagemain2');
current = <?php global $_zp_current_image; echo $_zp_current_image->getIndex(); ?>;

albumImages[current] = createImage(current, 2);
albumImages[current].onload = null;
albumImages[current].src = images[current][2];
var cont = document.getElementById('imagecontainer');
cont.style.width = images[current][3]+'px';
cont.style.height = images[current][4]+'px';
preloadAround(current);
}

(`code`-markup on bbpress is a joke...)

ulfben

I've added support for reading/writing comments and keeping the EXIF-data in sync. You can download my Tricasa enabled default theme (v. 0.1). Just visit my gallery for a demo.

You'll have to replace one of zenphotos core files (functions-controller.php) - I added some logic to allow you to post a comment to any image ID, not just the $zp_current_image. This is of course necessary for adding comments to the correct image. (I'm hoping this "patch" might get accepted into core proper?)

The theme is only modified in two ways: it's made to allow larger default image dimensions (800x600), and the image.php it tricasified. (oh, and I believe I removed the subalbum RSS-links, since it doesn't work properly anyway).

Still left to do:

• Center smaller images in the image container.
• Keep the tags in sync.
• Images that are larger than the default dimensions, should be thickbox links for full display.

What really needs to be done:

• Populate comments, EXIF, tags and description via AJAX.
• Write and update comments, EXIF, tags and description via AJAX.

aitf311

Looking great!

Hope to see you finish it.

Your #2 fix is awesome, thanks a ton. I've updated the version on the themes page to reflect your change.

ulfben

Just a slight update to this hack. You can grab the tricasa_default 0.2 here.
Changes:
*added wrap-around for album browsing
*disabled exif, geo and tag-data (unused bloat)
*disabled auto-fire. (unused, buggy and stupid)
*somewhat useable in IE.
*code cleanup. (a bit more readable now)

Once again:
This is the "default" theme with only a few modifications: better fit for larger images (800x600), minimizing page height (no footers, no RSS-icons etc), some javascript actions to link the large divs in album view. I've also disabled paging in most views.

Note:
Flipping through images works very well for visitors (... providing they're on Firefox...), but less so for administrative purposes. Do not modify the ajax fields (image description, image title, tags) after flipping to a new image. These are not kept in sync with the tricasa hack so you'll end up altering the data of the first image you visited in the album.

titou

for issue #1, you can use in javascript:
document.location.hash = "Write all what you need";
(I don't know if it's working with the rewrite rules...)

With this, you will be able to change the url or to reload the good page.
it's just an idea

AlexWilson

Mostly the same issues I ran into with my Galleria/jCarousel theme:
http://www.zenphoto.org/support/topic.php?id=2571

I disable paging just by setting my image and album limits per page to be very high.

I opted to not use image.php for the problems with the URLs for SEO and bookmarking and such -- the image display is done on album.php, and it use document.location.hash to change the URL for the displayed image.

ulfben

Thanks for the feedback, both of you.

Using the location.hash seems to be difficult; something in the ajax-library (or otherwhere) keeps reseting in every time I flip an image.

I did however turn the end node of the bread crumb navigation to a link that's kept in sync with the tricasa-browsing; thus giving users atleast one way to find a link.

tricasa_default 0.2.1
Changes:
*keeping the end-node of the bread crumb navigation in sync,
to allow users some way to link correctly.
*using thumbnails instead of generating custom low-rez images
*honoring the default size setting

jssmadtown

Perhaps this is known already, if "allow comments" is toggled off, then the images don't advance with the title. Gets stuck on the first image selected from the thumbnail page, while the title advances back/forth just fine.

ulfben

Good catch!

I've updated 0.2.1 with a fix.
Changes:
*fixed: flipping works when allow_comments is off.

Now, if anyone could tell me what the hell is going on in IE when flipping between images, I'd be very happy.

Note though that IE centers images nicely. Let me know if you can get Firefox to behave as well.

jssmadtown

Nice quick fix!

How hard is it to make the full image appear clicking on its large image, as in the default theme?

Thanks!

ulfben

Done. (though not thickboxed, that turned out to be tricky indeed)

tricasa_default 0.2.2
*added full-size links to images that are larger than the default settings.

jssmadtown

So, when flipping through, when I click on an image I get from the brower (Firefox & Safari):

`NOT FOUND

The requested URL /albums/.../IMG.jpg.php was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.`

The desired full image is IMG.jpg, so the .php isn't getting stripped.

Thanks!

jssmadtown

ulfben,

Although default is already very clean, I like the even more streamlined approach you've taken (and of course the tricasa speed).

Of the elements left out (RSS, etc.), I miss the "image info" the most.

Is this hard to maintain? Could be placed somewhere else, e.g., inline to the right of image if need be.

Also, I don't use comments much, but I notice that the comment form captcha isn't working? You probably know this

Thanks!

trisweb

Sweet, thanks for working on this.

The URLs need to work like this:

When on an image page, instead of linking to `/albumname/imagename.jpg.php` it should be something like `/albumname/img#imagename.jpg`, and then as was said above you can use document.locations.hash to retrieve and change that value. That's exactly how it works in Picasa Web, check it out there if you're confused.

So, what would be required is some sort of new rewrite rule for `/albumname/img` that would just redirect to `/index.php?a=albumname&i=[anything-really]` (image doesn't matter as you'll be getting it from the javascript).

Then you'll also have to update the image links in the album to use the `/albumname/img#imagename.jpg` instead of the `/albumname/imagename.jpg.php` form.

All in all not too difficult, and that should give you reliable current image, and even stuff like bookmarking and sending links should work just fine.

trisweb

BTW - Even more ideal (and theoretically possible) would be to make this generic for any theme. So, it could just be an option in the admin and would "just work"

ulfben

The desired full image is IMG.jpg, so the .php isn't getting stripped.

Sorry mate. I'm using ZenPhoto's `getImageLinkURL()` straight up. I don't know why it would append .php to it. Please check your settings and let me know if you find out what causes it.

I miss the "image info" [...]

It's still in there, just commented out. Check image.php in the default_tricasa folder; I believe I've commented the disabled lines. The only thing you need to think about is to offset the imgurl and fullSize-entries of the array. (eg, they're at 8 and 9 now, but will be 9 and 10 if you enable exif-data. 10 and 11 if you turn on tags too.)

The reason for turning it off is performance. Every image has EXIF-fields, and every image's data gets loaded (in full mark up form) when you enter an album (image.php). Considering how useless that data is for the vast amount of visitors, it's just rubbish to keep it. YMMV of course.

the comment form captcha isn't working

Yeah, I'll add that soon.

sbillard

The .php append is from the option `Mod_rewrite Image suffix`. If the image is being loaded by i.php this should cause no problem.

ulfben

(soddit, blockquote is broken)

Tris - you're the one who truly understand the CSS witchcraft doing the image-flipping. Could you please take a look at my gallery in IE and see if you can find a solution to the weird behaviour when loading new images? (eg: it seems to display the low-rez image two steps back or something, while loading the new one).

Also: do you know how to have the images centered in Firefox like they are in IE?

jssmadtown

Ok, I now "understand" the origin of the .php suffix (I wouldn't qualify as a php/apache novice, even...)

Still, I suspect a bug. I turned off mod_rewrite. I now get the error

`The requested URL /albums/gallery/index.php was not found on this server.`

This is quite puzzling, since I don't have this directory structure.

I have /gallery/index.php and /gallery/albums/ etc., where ZP is installed on my "gallery" directory (name chosen by me).

P.S. There's a suspicious line `//assuming images are in the album folder.` in index.php

Sorry, not quite familiar enough with this yet to track back...

jssmadtown

sorry, I meant to say saw the suspicious line in image.php...

trisweb

jssmadtown - the URL will change if you turn off mod_rewrite, so it will no longer be `/albums/gallery/x`, it will be `index.php?album=gallery&image=x`, so start from the root of the gallery when you change that setting and things should work...

ulfben - I'm not seeing any problems, but I do remember there being bugs if you went too fast and got ahead of the loading, so it is possible. I'm also noticing that the size of the lo-res image seems to be wrong, like the wrong proportion or something. Not sure why that is either... I'll download the latest and see if I can find out.

jssmadtown

Well, I've tried default_tricasa with mod_rewrite on/off in the administration settings. I get a "not found" error in both cases when asking for the full image, and in both a leading prefix /albums/ appears which will certainly not work for my directory setup (if the browser's reporting an error looking for the actual image URL). The URL's are different in detail, but have the /albums/ prefix in common. They might work if /albums/ and my ZP root directory (/gallery/) were interchanged in order.

Of course the default theme works fine (with both mod_rewrite on/off).

Take this as friendly, if ill informed feedback. I hope it goes better later if ulfben keeps up the good work, as I like the tricasa speed.

Thanks!

acrylian

Regarding image centering, try `margin: 0 auto` in combination with `text-align: center` on the image.

ulfben

ulfben - I'm not seeing any problems [...]

In IE6 the order of the low-rez images are off. Not so for you?

[...] I'm also noticing that the size of the lo-res image seems to be wrong, like the wrong proportion or something. [...]

Yeah, I'm using the thumbnails instead of generating a new low-rez. Reason: performance again. The thumbnails are already in the cache (at the client even), and are very small. We wont be looking at the low-rex version for very long so the quality of them is largely inrelevant.

(I've got thumbnail cropping on, thus the aspect is off.)

ulfben

Aight. I've spent some time refactoring and cleaning up. The script should be much easier to modify now (and the page source looks much nicer. )

There are two significant patches to the ZP core (included) - I'll try and get them onto trac later today.

`template-functions.php` - added symmetric getters for various "print"-functions. (for feeding comments to the javascript).
`functions-controller.php` - redirects after posting comments now takes you back to the image properly. (also when you fail the captcha!)

Search the files for "ulfben" to quickly find my changes.

default_tricasa 0.2.3

*captchas are back
*fixed: full size images should work for everyone
*refactoring: images[] holds associative arrays instead of numericly indexed ones.
seeding the javascript is handled purely by PHP now

ulfben

Still 0.2.3, but replaced my custom `functions-controller.php` with a `customfunctions.php` for the theme so you won't need to replace the ZP core-file.

You'll still need my `functions-controller.php` for proper redirects when people comment though. I put a patch on trac so hopefully it'll not be a problem for long.

ulfben

I begin full time work on my final exam-thingy tomorrow so I'll be putting this hack down for a while again.

Still left to do:

• make the ajax description-field aware of what image we're working on. (zebaron has already solved this)
• smaller (than default) images are centered in IE6 but not in Firefox.
• IE6 displays the image two steps back before showing the right one, every time you step forward.
• get rid of `/imagename.JPG` from the URLs of image pages, so we can have `/#imagename.JPG` and handle it with JS from there.

jssmadtown

Thanks, uflben. Gave it a whirl, and all seems swell.

I may try a hand at putting back exif. Besides uncomments, looks like one needs to add the exif data to the image array. Anything else? I'll give this a try for my own education.

RE you're updated 0.2.3 with customfunctions.php. I didn't see this in the file set (still the original two functions). Also looked to see if it was embedded somewhere else, didn't see it, so thought I'd ask.

ulfben

Try clearing your browser cache; you probably got the old copy.

(and yes: `echo $exifstring` into an `'exif'`-field of the array, and then uncomment every function that has with exif to do.)

jssmadtown

Ok, thanks. Thought I had cleared cache, but in any case now have the latest.