$allow_comments = 2; // 1: Allow comments; 2: Disable comments

doesn't work.
even if i set this variable to 2, comments are still allowed.

there is a link pointing to "javascript:;" in the last picture on the left side. i would prefer if there wouldn't be no link at all.

maybe this isn't a bug...

i'm not sure yet if i like the fact, that there are two links on each picture depending on where you click.
do you plan to code an option that you can switch back to the old link that just pointed to the last picture?

i hope you get what i'm trying to say. my english isn't unfortunately the best...

If I klick on the "archive"-link, I get the following error-message:

Notice: Undefined variable: fbimage in /is/htdocs/67336/www.jowra.de/fb3/extensions/fb_exif.php on line 7

Warning: exif_read_data(): unable to open file in /is/htdocs/67336/www.jowra.de/fb3/extensions/fb_exif.php on line 7

john,
sure exif-data is there? (photoshops' save.for.web-feature destroys this data) ... just an idea

No, atm there is no EXIF-Data, but I guess FB should take pictures without EXIF-Information too, without problems.

On the other side: The error looks like an undeclared variable at this point of execution and therefor the imagefile #fbimage# cannot be found... (?)

why does the archive need exif-data anyway?

i think you should test using only-with-exif-data files, anyway...
because i dont have any other idea, so far
...and can't handle variable problems (lack of php skills, you know... :-(

[...]The error looks like an undeclared variable at this point of execution and therefor the imagefile #fbimage# cannot be found[...]
if so, which image can't be found? i'm seeing the thumbs as well as the bigview, furthermore links working, too

might sound banal, but:
whats your php-version? have something like this?
< ?php phpinfo(); ? >

[...]why does the archive need exif-data anyway?[...]

good question nick. maybe that is the problem, that the fb_exif.php is include in the archive page and can't find a big image, because there isn't one. but - am I the only one with this error, then it really might be a problem with my php-version or dir-structure or something like that...

Thanks for the heads up. Don't know how I let the EXIF one slip by me. It now checks to make sure it's on the right page (redownload and .

The comments variable was a typo. 0 disables comments.

nick, you can get rid of the half-image and javascript:; links by editing the main template file.

That should be (redownload and you only have to update the fb_exif.php file).

hi, i'have the same probleme with fb_exif.php file and i dont now what i can do for resolve it.
some one have a solution?

licoben, look at the posting right over yours ;-)

thanks donald! works great now.

hmm, whats wrong over here?
(line 194 - something with reading the cookie?)
any ideas?
problem didnt show up on localhost (but there was another message when pointing to a category in the catlist...)

sorry! first error is gone (incomplete transfer)
but 2nd remains: has somthing changed regarding categories.txt? (because the foldername appears instead of the description)

ehem, numerous posts (sorry for that) but i found out, that by adding &menu=(0,1,2,nothing,...works) to the end of url opening the category can be achieved, but: error still shows up when trying to open an image...
ideas to fix?

The categories have been completely redone (they were too counter-intuitive) -- put a file called "category.txt" in the category folder with just the name of that category.

Erik, not sure what you're getting at with your latest post. Can you clarify?

donald,
ok, thats the solution - category.txt was missing, thx!

last post (when i only had my fb202 categories.txt) should say: cat=nature didnt open the category but cat=nature&menu= did... (nevermind...)
just didnt know that...

I get this message when trying to see the web:

Warning: Undefined index: SCRIPT_NAME in /home/html/3/fb.php on line 32

Fatal error: Call to undefined function: glob() in /home/html/3/fb.php on line 103

Have no idea what i did wrong... maybe is a problem with the server?
many thanks in advance for any help!

elpeaton, are you sure your server is running at least 4.3.1? Make a phpinfo file according to Erik's instructions above.

I feel like an idiot, I'm obviously overlooking something, but what happened to post.php? How do I access the web interface?

that is my question too!
i have created a new folder for the new version, since i don't want to overwrite my other files and also to play around with fb3.0. - i don't get it... where is post.php...??

Thank you very much, donald.
That was it, server running PHP 4.1.2... :-(
I am really sorry not to be able to enjoy FB3!!
Thanks anyway!!

Whoops, I forgot to say one of the most important things — the new post page is accessed by adding /post/ directly after your fb.php file (i.e. fb.php/post/image/photoname/). Sorry about the delay in putting up some documentation; I'm still kind of sleeping off that last leg of the development cycle. I'll try to get it up today.

Not sure if I followed what's happening with EXIF - I've got the latest beta and I'm just not getting any EXIF data appearing. No error messages, and I've triple checked that all my JPGs have the EXIF data in the first place.

A related EXIF question: is there any way to just completely disable the EXIF functionality? For the gallery I'm creating, I don't want it, and it's just causing trouble. Spedifically, it's giving the following error for images from the d70 (but not the 20d):
Notice: Undefined index: WhiteBalance in /www/k/kaiwen/htdocs/test/extensions/fb_exif.php on line 20
I tried removing all the EXIF lines from template_main, but that didn't help.

Tried deleting the fb_exif.php file?

If I delete the fb_exif.php file, I get even more errors, on every image:
Warning: Invalid argument supplied for foreach() in /www/k/kaiwen/htdocs/test/fb.php on line 469

Interesting, I just tried deleting my fb_exif.php file and I get no errors. Instead when I load my page all my EXIF fields (which are usually blank) are filled in with their variable names (<#fbcamera#>, etc.)

I just addressed your errors, James and Kevin (fb3b02.zip). The only files you'll need to update are fb_exif.php and fb.php.

The reason deleting the fb_exif file reverts the exif data to their tag names is that the tags exist only when fb_exif is installed. You can delete the tags in template_main.php.

(Oh, and the reason that Kevin got the foreach() warning and you didn't, james, comes down to server settings/configuration. The warning should be gone altogether now.)

Thanks for the quick update, but still no go on the EXIF data for me. I'm beginning to think that perhaps my admin hasn't compiled PHP with --enable-exif. I know I've got PHP 4.31 but I'm not sure if EXIF is enabled or not. Anyone know how i can check?

James, create a PHP file whose body is

<?php echo php_info(); ?>

If --enable-exif was set, it should be under the Configure Commands in the first info box.

Well that solves it - no --enable-exif for me. Unluckily my sysadmin is on holiday in Vietnam too! So I'm going to be without EXIF for a while. Thanks for your help donald! I'll be sure to donate in a couple of days when i get paid.

Thanks! That update fixed it.

Here's some unexpected behaviour: I put the fb3 files in the Folderblog directory. My photos, comments, etc. directories are subdirectories of this Folderblog directory. The new vars.php file points to "photos/", etc. as it should. However, when I try to load the page, I get this:

"folderblog error
No image files found in photos/folderblog/. Please upload files or confirm directory location and permissions."

It's as if Folderblog is trying to add the suffix "folderblog/" to the directories I've specified in the new vars.php.

The funny thing is that I can see everything just fine in the Post option. After doing so, I can go back to the regular Folderblog view and see everything fine as well -- only on that browser. When I switch to a new computer or browser, same problem all over again.

Any ideas?

Ah, OK, it works when I include the trailing "/" on the URL. Compare:
http://www.photosensitive.ca/folderblog/fb.php
with
http://www.photosensitive.ca/folderblog/fb.php/

With the second, though, when I browse back through my images, I don't get "clean" (filename-less) URLs.

not a bug, but: i have 2 categories:
cat1: 1.jpg, 2.jpg, 3.jpg
cat2: 1.jpg, 2.jpg, 3.jpg, 4.jpg, 5.jpg, 6.jpg
1.jpg in cat1 and 1.jpg in cat2 aren't the same pictures. with your new implementation, this isn't possible anymore. the pictures have to have unique filenames.
maybe you should think about a solution that solves this "problem".

that was possible before? :-P

i don't know. i never worked with categories before. but i try to make a portfolio site for a photographer. i have two categories and named the photos with numbers...
that didn't work...

now i have to design a modern and plain layout. if my plans are doable with fb3, i'll be very happy!

grüzi nick,
it wasnt (because all images came from within one directory) so i think the new handling is a good improvement.
one note: i think the background behind naming the files with numbers came from your image-sorting (older thread) but you should consider search engines too (/images.google.com) that would be thankful to have a little more info on an image then raw numbers. is the site commercial? if yes images should IMHO be named like photographer_category_short_description.jpg (for example) at least ...

Jordan, that's quite a strange bug. I'll email you tonight with some debug code you can add to your file that will help me diagnose the problem.

nick, erik explained it right. The categories system is open to suggestions and maybe deserves it's own thread. It's hard to strike a balance between pure intuition (for technical know-nothings) and flexibility/functionality (for the rest of us).

I'm still getting to foreach() error; have the latest version.

Warning: Invalid argument supplied for foreach() in /home/coghorn/www/index.php on line 336

At http://uncouthyouth.com/

until now :-) (fb3b04.zip)