[Koha-bugs] [Bug 6840] error in Template.pm in logs

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6840

--- Comment #9 from M. Tompsett <mtompset at hotmail.com> ---
(In reply to comment #8)
> (In reply to comment #7)
...
> > Fred P's suggestion of:
> > #addition to test error parameter status
> > if ( $error ) {
> > 	$template -> param (
> > 		$error => 1,
> > 		error => 1,
> > 	);
> > }
> > is overkill compared to simply splitting up the large $template->param()
> > call,
> > and having
> > $template->param($error => 1) if $error;
> > separately from the long list.
> > 
> > No, I didn't do any testing. I just don't want a good patch wasted. :)
> 
> Well setting $error=>1 is different because the value of $error isn't
> 'error' so you would have to change the template as well. To match that in
> your patch you arent setting error in the template

True it should be:
> > 		$error => 1,
> > 		error => $error,
I was merely quoting from comment #5

Otherwise, it would potentially break:
upload-images.tt
edithelp.tt
addbooks.tt
paycollect.tt
step2.tt (the web installer!)
step3.tt (yes, the web installer!)
sms-home.tt

But, it would probably still work in:
linkitem.tt
moveitem.tt
senshelfform.tt
moremember.tt
label-manage.tt
clone-rules.tt
sendbasketform.tt
opac-sendbasketform.tt
opac-sendshelfform.tt

On a git repo of master, I did a:
$ vi `grep -l "IF ( error )" \`find . -name '*.tt'\``
This obviously may miss the plain [% error %]. So I did a:
$ vi `grep -l "% error %" \`find . -name '*.tt'\``
And it returned 6 of the 7 files I listed as potentially broken.

And as I said before, Fred P.'s suggestion to fix what bug he did find is
better served by taking the '$error => 1' out of the larger $template->param()
section and putting:
    $template->param($error => 1) if $error;
just after that large section. The bug described by Fred P. is likely the same
as the one discussed in bug 7352 and bug 7630.

In fact, I decided to do a:
$ grep "\$error\s*=>\s1" `find .`
I found:
./tools/batchMod.pl
./cataloguing/additem.pl
./members/moremember.pl
./members/member-password.pl
./members/memberentry.pl
If $error is undefined, all these modules will have problems. I did not look
further, as that is beyond the scope of this error and the two bug reports I
have mentioned. The patch viewable by diff is perfectly sufficient for the bug
described in this bug report. However, as I said before Fred P.'s suggestion is
better addressed by bug 7352 and bug 7630 being fixed as suggested above.

A warning, which this patch generates, is better than the error generated by
not having it. Clearly this patch is functioning, because it seems to be in
3.6.3 which we are currently running, and I found the other errors as a result
of this cleanly generated "error" (really a warning), rather than an ugly
error.

In short, I think the status should be closed, so focus on bug 7352 and bug
7630 can be dealt with, which is what I believe Fred P. encountered.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are watching all bug changes.