Looks like the variable $emptylink (in fb.php) is not defined. I get errors on this (line 452 and 454).

When I'm going to post anything the following warning occurs:

Warning: touch(): Utime failed:
Operation not permitted in /is/htdocs/67336/www.jowra.de/fb38/fb.php
on line 246

I've read somewhere that the touch()-function only works if the "user" owns that file. may that be the problem? (Hopefully not!)

I also get this error message:
Notice: Undefined variable: emptylink in /usr/local/psa/home/vhosts/talx.nl/httpdocs/photos/fb.php on line 453

$emptylink is defined in the new version of 'template_settings.php', and looks like this:

$emptylink = "javascript:;";

Since this variable is called by fb.php itself, I'd perhaps recormend defining this in fb_vars.php.

I don't get the second error about the touch() function, but then I've set the chmod to 777 for Folderblog, which might effect this.

NEW BUG: Comments don't work any more. Several issues here:

First, while fb3b08 saves the cookie and remembers the user, and saves the comment to the '/comments' directory, and emails you about the addition, it fails to display them (this happens in the default template too). Comments are now saved as something like "0_com.txt", which is new (fb3b07 named them like "imagename_com.txt". Oddly, it will display comments made under fb3b07, but won't display comments made by fb3b08.

Second, I can't delete checked comments in post mode.

Third, the change in <#fbtitle#> and <#fbdate#> means that comments lose their date stamp. Where ever you used <#fbdate#> when reading the comments, you have to use <#fbtitle#> (this bug is even in the default template). If you use <#fbdate#>, the tag isn't replaced by the date; if you use <#fbtitle#>, it is. This seems to be because <#fbdate#> is now the file date of the image, not the read date saved in comments.

This probably isn't explained very well, so it might be a good idea to play about with the demo I have running HERE. This is a basic install of fb3b08, with only my fb_mimetype extension running (so, all the DOCTYPE declarations in the default template have been removed).

Also, I've noticed that post mode doesn't seem to actually change the file modified timestamp. I'm assuming that you simply need to hit the 'Now' button to get the current date, and hit Update. If so, it doesn't do anything (i.e. the caption date isn't changed).

Did you have the php-warnings on, Elwing? I've set now everything to 777 and the touch()-warning still remains. But since your timestamp isn't modified too, I guess its the same problem.

Oh, and for the touch() function to work, it must be on a file the user owns. PHP is 'nobody'. This means that each and every one of the image files you upload must be set to chmod 777 (this is needed for FotoBuzz, anyway, so all mine are set this way, but I'm guessing that folks who don't use FotoBuzz won't be doing this).

There is a workaround to this problem, posted here in the PHP manual. I've no idea if Donald is using something like this. Either way, it's not working for me, but I don't get Jowra's warning message.

To the comments-problem: When you post a comment it wont be displayed, but is saved in the 0_com.txt file correctly. If you go on to another photo and post a comment, the comment-file is called 1_com.txt and so on.

I guess the problem is this:

<code>
if(($page=="main") || ($page=="comments")) { // Main Page or Comments Page
$number = $show_thumbs<3 ? 1 : floor($show_thumbs/2);
if ($image) {
for($i=0; ($i<$total) && ($image!=$files[$i][0]); $i++);
if ($i<$total) {
$image = $i;
}
}
if (!is_int($image)) {
if ($reverse==0) {
$image = $total-1;
} else {
$image = 0;
}
}
</code>

the $image variable is defined as an integer. is that intended?

Whew, I messed that one up pretty bad.

Try fb3b09. All files have been updated (except the style.css and the exif extension). Updates in addition to those above:
- Note the addition of:

<input type="hidden" name="image" value="<#fbimagename#>" style="display: none;" /> 

in the comments form.
- $emptylink, $thumbs_perrow, and $rows_perpage moved to fb_settings.php
- fb_vars.php renamed to fb_settings.php
- bug fixes for the bugs mentioned in this thread (hopefully)

jowra, let me know if this fixes the touch() error you've been getting. After this I have one more thing to try, then will move to the workaround Elwing linked to.

Elwing wrote:

"There is a workaround to this problem, posted here in the PHP manual."

I've tested this in fb.php at the 2 parts where touch() is used. It works. :-)

Oh, overlapped. I'm going to test v09. ;)

Okay. touch() still brings the warning and the timestamp modification failed. I had tested the code mendtioned by Elwing and hacked it in the fb.php for testing:

foreach($categories as $thiscat) {
if (in_array($thiscat, $cat)) {
target_file = "$thiscat/$image/$file_extension";
$file_content = implode("",file($target_file));
@unlink($target_file);
if($savetofile = fopen($target_file, "w")) {
fputs($savetofile, $file_content);
fclose($savetofile);
}
touch("$thiscat/$image$file_extension", $timestamp);
...
...

This works. (I've already set the images via chown to 777 manually and it didn't work for me.)

----

There is a little problem leftover with the comments. The first comment works fine (e.g. max2_com.txt is written, when I stay at the comments-page an post another comment the file _com.txt is generated and all the other comments will written in this file.

jowra, thanks.

Did you also edit line 299 (touch("", $timestamp);), or did you have no problems there? Did you try changing line 290 and 298 to 0777 (instead of 0755)?

I can't duplicate your comments bug in my demo blog, even putting the comments form on the main page. You did add the hidden image input, right?

(Oh, and you should add a body { min-height: 100.05% } to your template to force the scrollbar in Mozilla — that way you won't have the right-left jump when you expand the comments (as seen here).

I have edited Line 299 too. Without it, it wont work. I can try the 777, but since I've manually edited the files and they are already set to 777, I think that doesn't matter. ;)

And hey, thanks a lot for this 100.5% tip Donald!!! The jumping was really annoying. :)

html { min-height }, rather.

Thanks, jowra. Even though the workaround apparently works, I was trying to avoid it because it just doesn't feel very graceful. I'll post an updated version momentarily, though.

Oh and yes I have added the hidden input field. Aehm must I do this in the *_comments.php too? But I can face this later since a.t.m. I'm just hacking around and test a lot. :)

jowra, you shouldn't need the comments file at all anymore. Leave the comments form action on your main page as action=""

html { min-height }, rather. -> done.

Leave the comments form action on your main page as action="" --> done. (works fine :) )

I've changed the chmod-parameter to 0777, still no luck. would be interesting if other users have this problem too. if not, you can leave it as it is (chmod) and I will hack my fb.php just for me. ;)

thanks for the help donald!

jowra, I'm sure if it happens on your server, it will happen to someone else. Thanks for working through it — I've posted an updated version, which I'll start a new thread for (as this one is so long already).

Just a small note, before I start messing with fb3b09...

Leaving the action attribute blank results in a validation warning. Yes, it may still validate and will work, but it's not very elegant. It might be an idea to use $_SERVER['PHP_SELF'] here.

I've just set up a fresh new install, still the touch()-warning/error. It seems like the "owning" of a file (in case of the touch()-function) is another thing then the chmod-0777?

When you say fresh install, do you mean of b09 or b10? The b10 version is using the workaround — unless I messed something up, there shouldn't be any error.

Elwing, thanks once again. I'll put that on the to-do for the next build.

Meh. Just tried this, and while it works, it still results in the validation warning. Tried a few other ideas too, but get the same thing. I doubt this is a big issue, and can be avoided if you clone the 'template_main.php' file as 'template_comments.php' and use <#fbcommentslink#> as the action. In all cases, it validates.

No, sorry Donald, I meant b09. Just thinking about that... since you're right, the workaround is not very elegant.

b10 works fine.

Elwing, I'm using just the template_main.php and for me the post="" method is validating:

fb3b10 test-installation

The only difference seems to be, that I'm not using your mime-type extension at the moment.

Jowra, the mime-type extension will make no difference, and your install still gets the validation warning. Note, this is a warning, not an error. W3C's XHTML validator thinks it's fine, but HTML Tidy pounces on it, since an attribute contained in a tag that does not contain a value when a value is expected (like 'action=""') is incorrect. Valid, in terms of XHTML and XML, but still incorrect.

Folderblog does this a lot, for things like:

<tag>$message</tag>

When $message is nothing, the result is:

<tag></tag>

Since the tag is properly closed, it will validate as XML, and W3C think it's fine to have this under even the DTD for XHTML 1.1. But it's still an empty tag, and ideally, you don't want empty tags or attributes.

It really just depends on how much of a geek you are. Otherwise, you can always find out why all web standards suck. :-)

*g*

Okay, I think I'm geek enough, but I didn't touched HTML-Tidy for a long time now. :shame: ;-) Hm... at least the action="" thing should be solvable. I'm keep my eyes open...

In which way are you using HTML-Tidy? Via the Firefox-Extension?

Yeah, that's the version I'm using, which is very handy as it shows the errors, warnings and access warnings in a neat little status bar addition. Great for having a giggle at the leading sites out there, that can run up some impressive numbers! :-)

I've put this in the postform:

<form method="post" action="<?php echo$_SERVER['PHP_SELF']; ?>">

and the warning is gone (just installed HTML-Tidy too :-) ).

Go for overkill, and use this:

action="<?php echo $_SERVER['REQUEST_URI']; ?>"

This stops the silly stuff that appears on the browser's address bar. ;-)