phplib-trackers — List for monitoring the phplib SourceForge trackers.

[Phplib-trackers] [ phplib-Support Requests-581211 ] Cannot call mysql_pconnect() function

[<no...@so...>]

Support Requests item #581211, was opened at 2002-07-13 21:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403612&aid=581211&group_id=31885

Category: Install Problem (example)
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot call mysql_pconnect() function

Initial Comment:
"Call to undefined function: mysql_pconnect()"

I'm running RedHat 7.2, Apache 1.3.22, PHP 4.0.6, 
PHPLib 1.7d, mySQL server 3.23.41  PHPlib seems to 
be working fine up until it tries to hit the db.  I was able 
to call phpinfo() without any trouble.  Most of the help 
I've found online so far points toward mysql support not 
being compiled in with apache, but phpinfo reports "--
with-mysql=shared,/usr" which I take to mean that it 
was compiled with all the right options.  Any help would 
be greatly appreciated.

Thanks,
Chip

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403612&aid=581211&group_id=31885

[Phplib-trackers] [ phplib-Bugs-580453 ] TRANSACTION in ct_split_sql

[<no...@so...>]

Bugs item #580453, was opened at 2002-07-12 00:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=580453&group_id=31885

Category: Session
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Bondurant (bondu)
Assigned to: Nobody/Anonymous (nobody)
Summary: TRANSACTION in ct_split_sql

Initial Comment:
get a database error when using ct_split_sql.  Here is 
the fix from the mailing list back in 2000: MySQL 
doesn't like TRANSACTION.



- comment the BEGIN TRANSACTION line of 
ct_split_sql.inc (function ac_store)
-    "     "  END TRANSACTION    "        "                     "
- add this line just before return $ret (function 
ac_store);   
        $this->db->query("COMMIT");     



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=580453&group_id=31885

[Phplib-trackers] [ phplib-Bugs-580446 ] Error using parse(append true AND false)

[<no...@so...>]

Bugs item #580446, was opened at 2002-07-11 23:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=580446&group_id=31885

Category: Template
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error using parse(append true AND false)

Initial Comment:
If youre working with nested blocks and parse a block 
inside an other block using append=false AND 
append=true alternatly the output is wrong.

1.Step
set_var("foo","foobar")
parse("target","handle",false)
parse("main_block","MAIN_BLOCK",true)

output:
foobar

2. Step
$array=array("test1","test2","test3")
while($bar) = each($array){
    set_var("foo",$bar)
    parse("target","handle",true)
}
parse("main_block","MAIN_BLOCK",true)

output:
foobar
test1
test2
test3


My Workaround:
I'am using a flag $reset which is by default false. If i add 
a row into a block with append=false i change this flag 
to true.

Depending on this flag and after parsing main_block i'm 
emptying the varvalue $target by set_var("target","")

If somebodys got a better Idea... ;-)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-11 23:54

Message:
Logged In: NO 

Sorry, i forgot...

my Name is Frank Schenk and my Mail is fr...@yp...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=580446&group_id=31885

[Phplib-trackers] [ phplib-Bugs-580446 ] Error using parse(append true AND false)

[<no...@so...>]

Bugs item #580446, was opened at 2002-07-11 23:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=580446&group_id=31885

Category: Template
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error using parse(append true AND false)

Initial Comment:
If youre working with nested blocks and parse a block 
inside an other block using append=false AND 
append=true alternatly the output is wrong.

1.Step
set_var("foo","foobar")
parse("target","handle",false)
parse("main_block","MAIN_BLOCK",true)

output:
foobar

2. Step
$array=array("test1","test2","test3")
while($bar) = each($array){
    set_var("foo",$bar)
    parse("target","handle",true)
}
parse("main_block","MAIN_BLOCK",true)

output:
foobar
test1
test2
test3


My Workaround:
I'am using a flag $reset which is by default false. If i add 
a row into a block with append=false i change this flag 
to true.

Depending on this flag and after parsing main_block i'm 
emptying the varvalue $target by set_var("target","")

If somebodys got a better Idea... ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=580446&group_id=31885

[Phplib-trackers] [ phplib-Patches-467563 ] db_odbc num_rows and num_fields fixed

[<no...@so...>]

Patches item #467563, was opened at 2001-10-04 03:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403613&aid=467563&group_id=31885

Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
>Priority: 3
Submitted By: Greg Jorgensen (gregjor)
>Assigned to: Richard Archer (richardarcher)
Summary: db_odbc num_rows and num_fields fixed

Initial Comment:
1) db_odbc.num_fields() would return 0 unless 
next_record had been called at least once.

2) db_odbc.num_rows() improved when the ODBC driver 
can't return the number of rows. The binary search is 
clearer, and the common case of 1 row returned is 
discovered faster.


----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-12 09:59

Message:
Logged In: YES 
user_id=279311

I think these changes were already implemented in the -devel
tree. I've just merged the devel version into -stable.

Closing.

----------------------------------------------------------------------

Comment By: Greg Jorgensen (gregjor)
Date: 2001-10-04 03:23

Message:
Logged In: YES 
user_id=340037

3) also fixes db_odbc.metadata() to return column length 
and scale.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403613&aid=467563&group_id=31885

[Phplib-trackers] [ phplib-Bugs-478978 ] function affected_rows() and ODBC

[<no...@so...>]

Bugs item #478978, was opened at 2001-11-07 14:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=478978&group_id=31885

Category: DB_SQL
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Richard Archer (richardarcher)
Summary: function affected_rows() and ODBC

Initial Comment:
If you say "Many ODBC drivers don't support 
odbc_num_rows() on SELECT statements" -msaccess97 is 
one- why you use this function to set affected_rows()??
Will be better use your class function num_rows()?

----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-12 09:25

Message:
Logged In: YES 
user_id=279311

I've just merged in changes to db_odbc.inc which fixes
num_rows(). It will now return the number of rows from a
select. It does this by counting the number of results if
odbc_num_rows() fails.

affected_rows() however is more problematic. If the data
source doesn't return this value to PHP, then there is no
way to calculate it. You can't walk the result set because
there isn't one.

Closing this one.

----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-04 06:34

Message:
Logged In: YES 
user_id=279065

Sounds like he says phplib is using odbc_num_rows() to 
set affected_rows().  If so, that's not right.  Need to 
double-check the code.  In my somewhat older than 
current CVS version, this is in fact in error.  From 
db_odbc.inc:

function affected_rows() {
    return odbc_num_rows($this->Query_ID);
}

Unless, of course, PHP does something funky with 
odbc_num_rows() which results in correct behavior after 
an INSERT, UPDATE or DELETE.  Here's what 
www.php.net says on the subject:

odbc_num_rows() will return the number of rows in an 
ODBC result. This function will return -1 on error. For 
INSERT, UPDATE and DELETE statements odbc_num_rows
() returns the number of rows affected. For a SELECT 
clause this can be the number of rows available. 

Note: Using odbc_num_rows() to determine the number of 
rows available after a SELECT will return -1 with many 
drivers. 


So, I'd say this is NOT a bug.  Anyone have an ODBC 
driver to test it with?

..chris

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-03 05:14

Message:
Logged In: YES 
user_id=19736

Err.. I don't get it?

affected_rows() returns the number of rows changed by an
UPDATE, INSERT or DELETE statement

num_rows() returns the number of rows from a SELECT statement.  

The phplib num_rows is a thin wrapper around the php
function for the specific database you are using, it doesn't
create a num_rows in php.  A php version could be written;
however it would suffer horrible memory issues and would not
perform well on large queries.

The warning in the documentation I belive is there to make
the users aware that this specific fucntion isn't generally
well implemented by the udnerlying ODBC drivers, and
therefore isn't always availible.

Isn't there also a warning for async db's (like oracle) to
emulate this by getting the count of the intended query? 
Would this also work for the ODBC drivers as well?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=478978&group_id=31885

[Phplib-trackers] [ phplib-Feature Requests-531792 ] Templates and SSI

[<no...@so...>]

Feature Requests item #531792, was opened at 2002-03-19 19:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=531792&group_id=31885

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Dipl.-Inform. Kai Hofmann (powerstat)
>Assigned to: Richard Archer (richardarcher)
Summary: Templates and SSI

Initial Comment:
It would be very helpful when Templates could be used correctly in conjunction with Apache Server 
Side Includes.
The simples way would be using Apache 2.0 I think - but please make sure that it is possible to 
have SSI commands within templates that will later be expanded by Apache 2.0.
For Apache 1.3 I am not sure maybe there are two ways:
1) Doing an internal get on a shtml file an using the result as the template
2) template engine internal parsing of SSI commands (must be recursive!)

This would be a great enhancement for large websites which are based on shtml and php to make 
maintanance of parts that are the same for all pages much simpler.


----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-12 08:43

Message:
Logged In: YES 
user_id=279311

Closing this one...

----------------------------------------------------------------------

Comment By: Dipl.-Inform. Kai Hofmann (powerstat)
Date: 2002-06-02 02:30

Message:
Logged In: YES 
user_id=286352

Tested and works perfectly with Apache 2.0!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=531792&group_id=31885

[Phplib-trackers] [ phplib-Feature Requests-543468 ] unset_var for template.inc!

[<no...@so...>]

Feature Requests item #543468, was opened at 2002-04-14 05:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=543468&group_id=31885

Category: None
Group: None
>Status: Closed
Priority: 1
Submitted By: Dipl.-Inform. Kai Hofmann (powerstat)
>Assigned to: Richard Archer (richardarcher)
Summary: unset_var for template.inc!

Initial Comment:
Please add a method unset_var("varname/array") to the template engine.
This is required when handling blocks within blocks!!!!
Because in this situation you have sometime to clear already set variables!
Blocks within blocks can be very power- and helpfull but one ran into strange situations when no 
unset_var is available.
Its 5 Minutes of work or less!

Thanks.


----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-12 08:42

Message:
Logged In: YES 
user_id=279311

I've added clear_var method which sets the value of an
variable (or array of variables) to "". Also added an
unset_var method which unsets the variable completely. Use
whichever seems appropriate.

This is in the CVS only at this stage. I also merged the
-devel version of template.inc into the -stable tree. I'm
tired of maintaining two versions.

----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-07-06 03:03

Message:
Logged In: YES 
user_id=278685

You're correct, there are 2 different issues here. In the case of 
embedded blocks, setting the variable to "" is adequate 
because the variable is going to be reused immediately - 
there's no need to destroy it and then recreate it.

On the other hand, I often use 2 Template instances to 
minimize the variables parsed during long loops - in this case 
I always do a full unset between loops.

FWIW, I discovered some less-than-ideal programming and 
variable use when using an actual unset; setting the variable 
to "" covered the problem up.

----------------------------------------------------------------------

Comment By: Dipl.-Inform. Kai Hofmann (powerstat)
Date: 2002-07-04 19:27

Message:
Logged In: YES 
user_id=286352

Sorry to say, but my experience shows that it is not a
simple set_var("name","") because this is different from a
real unset() !

----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-16 01:13

Message:
Logged In: YES 
user_id=278685

A unset_var() (or clear_var() as I use in my personal 
extension) is simply an alias for set_var("varname", ""). 
Someone may get around to adding such an alias to the 
official library, but it is far less urgent than many 
existing bugs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=543468&group_id=31885

[Phplib-trackers] [ phplib-Bugs-577922 ] Error: now disappears $xx and \

[<no...@so...>]

Bugs item #577922, was opened at 2002-07-06 06:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=577922&group_id=31885

Category: Template
Group: 7.4pre1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alejandro W. (awoywood)
>Assigned to: Richard Archer (richardarcher)
Summary: Error: now disappears $xx and \

Initial Comment:
Hi, I was looking for a correction to the disappearing $, 
then I tried this version of templates.inc

But I found two errors:
- templates.inc->set_var still eats "$xx", where x is a 
literal
- templates.inc->set_var eats the \ in "\"

if you do the following:
$t->set_var(array(	"t1" => " $es ",       "t2" => " 
\23 " ));
the variables inside the template object will became:
t1="" and t2="$123".
t1 is clearly wrong.
t2 seems wrong too (I don't know the inner 
representation). After doing a $t->parse and a $t->p, in 
place of {t2} you will get a "$123" which is wrong.

----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-11 18:02

Message:
Logged In: YES 
user_id=279311

I tested this, and it works fine for me.

Test files attached...

----------------------------------------------------------------------

Comment By: Joe Winter (jwinter1)
Date: 2002-07-11 05:21

Message:
Logged In: YES 
user_id=206472

I second layne weathers on this.  

Also add ${noTDTags} to your testspecialchars.tpl where 
there is no space, no td tags, nothing, between the $ sign 
and the curly brace.


----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2002-07-06 08:20

Message:
Logged In: YES 
user_id=279311

I am confident that the current CVS version of template.inc
behaves correctly in both these situations. Your second test
result containing a "$" suggests to me that you're
running an old version of template.inc. That kludge was
removed from the script in April.

The last change I made to resolve this issue was to run all
variable values through preg_replace prior to substitution.
While this incurs a performance hit over the previous
kludges, it's practically guaranteed to result in the
correct behaviour.

I have attached my test script and template for this
problem. The output consists of all template.inc's debugging
output followed by a table of three columns. The first
column is a description of the test, the second is the
intended result as plain text and the third is the result
after running through template.

 ...R.


----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-07-06 06:48

Message:
Logged In: YES 
user_id=278685

t1 depends completely on your setting of the PHP variable 
$es - you should be testing against ' $es ' so that PHP is not 
doing variable substitution within the string.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=577922&group_id=31885

[Phplib-trackers] [ phplib-Bugs-579766 ] Error with Dollar sign ($) in template

[<no...@so...>]

Bugs item #579766, was opened at 2002-07-11 04:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=579766&group_id=31885

Category: Template
Group: 7.2.x
>Status: Closed
Resolution: Duplicate
Priority: 1
Submitted By: Joe Winter (jwinter1)
>Assigned to: Richard Archer (richardarcher)
Summary: Error with Dollar sign ($) in template

Initial Comment:
If you have the following text in your template:
${money} 

This will result in .50, if the variable money is set_var'ed 
to 7.50.  See:

www.geocrawler.com/archives/3/195/2001/1/200/4917647
/ 
http://bugs.php.net/bug.php?id=8339

For further details.  

The solutions provided suck, those being:
(a) change all of your templates to have a space after 
the dollar sign.
(b) use the HTML character code for the dollar sign.

Changing the template class is the only way to fix this 
by making a single change in one place.  Any ideas?

Thanks in advance,
Joe 

----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-11 17:58

Message:
Logged In: YES 
user_id=279311

Closing...

----------------------------------------------------------------------

Comment By: Joe Winter (jwinter1)
Date: 2002-07-11 04:54

Message:
Logged In: YES 
user_id=206472

Ack!  I swear I searched for this bug before I submitted it.  
Obviously not,  
http://sourceforge.net/tracker/index.php?
func=detail&aid=577922&group_id=31885&atid=403611

Sorry, please ignore. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=579766&group_id=31885

[Phplib-trackers] [ phplib-Bugs-577922 ] Error: now disappears $xx and \

[<no...@so...>]

Bugs item #577922, was opened at 2002-07-05 16:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=577922&group_id=31885

Category: Template
Group: 7.4pre1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alejandro W. (awoywood)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error: now disappears $xx and \

Initial Comment:
Hi, I was looking for a correction to the disappearing $, 
then I tried this version of templates.inc

But I found two errors:
- templates.inc->set_var still eats "$xx", where x is a 
literal
- templates.inc->set_var eats the \ in "\"

if you do the following:
$t->set_var(array(	"t1" => " $es ",       "t2" => " 
\23 " ));
the variables inside the template object will became:
t1="" and t2="$123".
t1 is clearly wrong.
t2 seems wrong too (I don't know the inner 
representation). After doing a $t->parse and a $t->p, in 
place of {t2} you will get a "$123" which is wrong.

----------------------------------------------------------------------

Comment By: Joe Winter (jwinter1)
Date: 2002-07-10 15:21

Message:
Logged In: YES 
user_id=206472

I second layne weathers on this.  

Also add ${noTDTags} to your testspecialchars.tpl where 
there is no space, no td tags, nothing, between the $ sign 
and the curly brace.


----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2002-07-05 18:20

Message:
Logged In: YES 
user_id=279311

I am confident that the current CVS version of template.inc
behaves correctly in both these situations. Your second test
result containing a "$" suggests to me that you're
running an old version of template.inc. That kludge was
removed from the script in April.

The last change I made to resolve this issue was to run all
variable values through preg_replace prior to substitution.
While this incurs a performance hit over the previous
kludges, it's practically guaranteed to result in the
correct behaviour.

I have attached my test script and template for this
problem. The output consists of all template.inc's debugging
output followed by a table of three columns. The first
column is a description of the test, the second is the
intended result as plain text and the third is the result
after running through template.

 ...R.


----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-07-05 16:48

Message:
Logged In: YES 
user_id=278685

t1 depends completely on your setting of the PHP variable 
$es - you should be testing against ' $es ' so that PHP is not 
doing variable substitution within the string.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=577922&group_id=31885

[Phplib-trackers] [ phplib-Bugs-579766 ] Error with Dollar sign ($) in template

[<no...@so...>]

Bugs item #579766, was opened at 2002-07-10 14:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=579766&group_id=31885

Category: Template
Group: 7.2.x
Status: Open
Resolution: Duplicate
>Priority: 1
Submitted By: Joe Winter (jwinter1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with Dollar sign ($) in template

Initial Comment:
If you have the following text in your template:
${money} 

This will result in .50, if the variable money is set_var'ed 
to 7.50.  See:

www.geocrawler.com/archives/3/195/2001/1/200/4917647
/ 
http://bugs.php.net/bug.php?id=8339

For further details.  

The solutions provided suck, those being:
(a) change all of your templates to have a space after 
the dollar sign.
(b) use the HTML character code for the dollar sign.

Changing the template class is the only way to fix this 
by making a single change in one place.  Any ideas?

Thanks in advance,
Joe 

----------------------------------------------------------------------

Comment By: Joe Winter (jwinter1)
Date: 2002-07-10 14:54

Message:
Logged In: YES 
user_id=206472

Ack!  I swear I searched for this bug before I submitted it.  
Obviously not,  
http://sourceforge.net/tracker/index.php?
func=detail&aid=577922&group_id=31885&atid=403611

Sorry, please ignore. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=579766&group_id=31885

[Phplib-trackers] [ phplib-Bugs-579766 ] Error with Dollar sign ($) in template

[<no...@so...>]

Bugs item #579766, was opened at 2002-07-10 14:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=579766&group_id=31885

Category: Template
Group: 7.2.x
Status: Open
Resolution: Duplicate
Priority: 5
Submitted By: Joe Winter (jwinter1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with Dollar sign ($) in template

Initial Comment:
If you have the following text in your template:
${money} 

This will result in .50, if the variable money is set_var'ed 
to 7.50.  See:

www.geocrawler.com/archives/3/195/2001/1/200/4917647
/ 
http://bugs.php.net/bug.php?id=8339

For further details.  

The solutions provided suck, those being:
(a) change all of your templates to have a space after 
the dollar sign.
(b) use the HTML character code for the dollar sign.

Changing the template class is the only way to fix this 
by making a single change in one place.  Any ideas?

Thanks in advance,
Joe 

----------------------------------------------------------------------

>Comment By: Joe Winter (jwinter1)
Date: 2002-07-10 14:54

Message:
Logged In: YES 
user_id=206472

Ack!  I swear I searched for this bug before I submitted it.  
Obviously not,  
http://sourceforge.net/tracker/index.php?
func=detail&aid=577922&group_id=31885&atid=403611

Sorry, please ignore. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=579766&group_id=31885

[Phplib-trackers] [ phplib-Bugs-579766 ] Error with Dollar sign ($) in template

[<no...@so...>]

Bugs item #579766, was opened at 2002-07-10 14:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=579766&group_id=31885

Category: Template
Group: 7.2.x
Status: Open
>Resolution: Duplicate
Priority: 5
Submitted By: Joe Winter (jwinter1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with Dollar sign ($) in template

Initial Comment:
If you have the following text in your template:
${money} 

This will result in .50, if the variable money is set_var'ed 
to 7.50.  See:

www.geocrawler.com/archives/3/195/2001/1/200/4917647
/ 
http://bugs.php.net/bug.php?id=8339

For further details.  

The solutions provided suck, those being:
(a) change all of your templates to have a space after 
the dollar sign.
(b) use the HTML character code for the dollar sign.

Changing the template class is the only way to fix this 
by making a single change in one place.  Any ideas?

Thanks in advance,
Joe 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=579766&group_id=31885

[Phplib-trackers] [ phplib-Bugs-579766 ] Error with Dollar sign ($) in template

[<no...@so...>]

Bugs item #579766, was opened at 2002-07-10 14:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=579766&group_id=31885

Category: Template
Group: 7.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Winter (jwinter1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with Dollar sign ($) in template

Initial Comment:
If you have the following text in your template:
${money} 

This will result in .50, if the variable money is set_var'ed 
to 7.50.  See:

www.geocrawler.com/archives/3/195/2001/1/200/4917647
/ 
http://bugs.php.net/bug.php?id=8339

For further details.  

The solutions provided suck, those being:
(a) change all of your templates to have a space after 
the dollar sign.
(b) use the HTML character code for the dollar sign.

Changing the template class is the only way to fix this 
by making a single change in one place.  Any ideas?

Thanks in advance,
Joe 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=579766&group_id=31885

[Phplib-trackers] [ phplib-Bugs-578859 ] db_pgsql.inc problems

[<no...@so...>]

Bugs item #578859, was opened at 2002-07-09 06:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=578859&group_id=31885

Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Archer (richardarcher)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_pgsql.inc problems

Initial Comment:
Received via email from Oliver Duke-Williams:

I've spotted a couple of problems with the pgsql class
in phplib that 
are present in both the php-lib and php-lib-stable CVS
branches.

i) The halt() function does not call haltmsg() as
descibed in the 
documentation; I've modified my db_pgslq.inc by copying
relevant parts 
of the mysql code and can send a diff if you like.  In
addition, the 
current function does not respect the value of
Halt_On_Error and 
requires modification.

ii) The metadata() function is slow for large tables;
performance can be 
improved by modifying the function to use "select *
from $table limit 0" 
in the pg_exec call.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=578859&group_id=31885

[Phplib-trackers] [ phplib-Support Requests-576415 ] re offset 0 ligne 130

[<no...@so...>]

Support Requests item #576415, was opened at 2002-07-03 00:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403612&aid=576415&group_id=31885

>Category: None
>Group: None
Status: Open
Priority: 5
Submitted By: courou (courou)
Assigned to: Nobody/Anonymous (nobody)
Summary: re offset 0 ligne 130

Initial Comment:
hey,

i use the same template 
Version : v 1.11 2002/04/25 12:49:17 richardarcher

it's about a function wich is called twice in the script 
cause of the usage of DHTML. This is the function:
If I called one and again, the error appear.
Could you translate it me please

// liste les fichiers d'un repertoire
// @param $direction = chemin d'installation
// @param $pid = utilisateur
function Simplify_function_for_offset($directory,$pid) {
     Global $TEMPLATE;
          $File = array();
          $Dir = opendir("$directory/$pid");
          while($tmp = readdir($Dir)) $File[] = "$tmp";
          closedir($Dir);
          rsort($File); next($File); next($File);  reset($File);

     $TEMPLATE->set_block
("FILE_32", "BOUCLE_OPTION_FILE_FORM", "BLOCK
_32");
     while($tmp = each($File))
          if(eregi(".sql", $tmp[1])) {
          $TEMPLATE->set_var(array
("CHOIX_OPEN_SWITCH" => '<option value="$directory/
$pid/$tmp[1]">$tmp[1]</option>'));
          $TEMPLATE->parse
("BLOCK_32","BOUCLE_OPTION_FILE_FORM",true);
          }
     $TEMPLATE->parse("EXECUTE_32","FILE_32");
echo $TEMPLATE->get("EXECUTE_32");
}

seen you soon
Courou



----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-06 08:22

Message:
Logged In: YES 
user_id=279311

This was in the wrong forum for support requests. Being moved...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403612&aid=576415&group_id=31885

[Phplib-trackers] [ phplib-Bugs-577922 ] Error: now disappears $xx and \

[<no...@so...>]

Bugs item #577922, was opened at 2002-07-06 06:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=577922&group_id=31885

Category: Template
Group: 7.4pre1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alejandro W. (awoywood)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error: now disappears $xx and \

Initial Comment:
Hi, I was looking for a correction to the disappearing $, 
then I tried this version of templates.inc

But I found two errors:
- templates.inc->set_var still eats "$xx", where x is a 
literal
- templates.inc->set_var eats the \ in "\"

if you do the following:
$t->set_var(array(	"t1" => " $es ",       "t2" => " 
\23 " ));
the variables inside the template object will became:
t1="" and t2="$123".
t1 is clearly wrong.
t2 seems wrong too (I don't know the inner 
representation). After doing a $t->parse and a $t->p, in 
place of {t2} you will get a "$123" which is wrong.

----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-06 08:20

Message:
Logged In: YES 
user_id=279311

I am confident that the current CVS version of template.inc
behaves correctly in both these situations. Your second test
result containing a "$" suggests to me that you're
running an old version of template.inc. That kludge was
removed from the script in April.

The last change I made to resolve this issue was to run all
variable values through preg_replace prior to substitution.
While this incurs a performance hit over the previous
kludges, it's practically guaranteed to result in the
correct behaviour.

I have attached my test script and template for this
problem. The output consists of all template.inc's debugging
output followed by a table of three columns. The first
column is a description of the test, the second is the
intended result as plain text and the third is the result
after running through template.

 ...R.


----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-07-06 06:48

Message:
Logged In: YES 
user_id=278685

t1 depends completely on your setting of the PHP variable 
$es - you should be testing against ' $es ' so that PHP is not 
doing variable substitution within the string.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=577922&group_id=31885

[Phplib-trackers] [ phplib-Bugs-577922 ] Error: now disappears $xx and \

[<no...@so...>]

Bugs item #577922, was opened at 2002-07-05 15:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=577922&group_id=31885

Category: Template
Group: 7.4pre1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alejandro W. (awoywood)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error: now disappears $xx and \

Initial Comment:
Hi, I was looking for a correction to the disappearing $, 
then I tried this version of templates.inc

But I found two errors:
- templates.inc->set_var still eats "$xx", where x is a 
literal
- templates.inc->set_var eats the \ in "\"

if you do the following:
$t->set_var(array(	"t1" => " $es ",       "t2" => " 
\23 " ));
the variables inside the template object will became:
t1="" and t2="$123".
t1 is clearly wrong.
t2 seems wrong too (I don't know the inner 
representation). After doing a $t->parse and a $t->p, in 
place of {t2} you will get a "$123" which is wrong.

----------------------------------------------------------------------

>Comment By: Layne Weathers (layne_weathers)
Date: 2002-07-05 15:48

Message:
Logged In: YES 
user_id=278685

t1 depends completely on your setting of the PHP variable 
$es - you should be testing against ' $es ' so that PHP is not 
doing variable substitution within the string.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=577922&group_id=31885

[Phplib-trackers] [ phplib-Bugs-577922 ] Error: now disappears $xx and \

[<no...@so...>]

Bugs item #577922, was opened at 2002-07-05 20:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=577922&group_id=31885

Category: Template
Group: 7.4pre1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alejandro W. (awoywood)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error: now disappears $xx and \

Initial Comment:
Hi, I was looking for a correction to the disappearing $, 
then I tried this version of templates.inc

But I found two errors:
- templates.inc->set_var still eats "$xx", where x is a 
literal
- templates.inc->set_var eats the \ in "\"

if you do the following:
$t->set_var(array(	"t1" => " $es ",       "t2" => " 
\23 " ));
the variables inside the template object will became:
t1="" and t2="$123".
t1 is clearly wrong.
t2 seems wrong too (I don't know the inner 
representation). After doing a $t->parse and a $t->p, in 
place of {t2} you will get a "$123" which is wrong.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=577922&group_id=31885

[Phplib-trackers] [ phplib-Feature Requests-543468 ] unset_var for template.inc!

[<no...@so...>]

Feature Requests item #543468, was opened at 2002-04-13 14:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=543468&group_id=31885

Category: None
Group: None
Status: Open
Priority: 1
Submitted By: Dipl.-Inform. Kai Hofmann (powerstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: unset_var for template.inc!

Initial Comment:
Please add a method unset_var("varname/array") to the template engine.
This is required when handling blocks within blocks!!!!
Because in this situation you have sometime to clear already set variables!
Blocks within blocks can be very power- and helpfull but one ran into strange situations when no 
unset_var is available.
Its 5 Minutes of work or less!

Thanks.


----------------------------------------------------------------------

>Comment By: Layne Weathers (layne_weathers)
Date: 2002-07-05 12:03

Message:
Logged In: YES 
user_id=278685

You're correct, there are 2 different issues here. In the case of 
embedded blocks, setting the variable to "" is adequate 
because the variable is going to be reused immediately - 
there's no need to destroy it and then recreate it.

On the other hand, I often use 2 Template instances to 
minimize the variables parsed during long loops - in this case 
I always do a full unset between loops.

FWIW, I discovered some less-than-ideal programming and 
variable use when using an actual unset; setting the variable 
to "" covered the problem up.

----------------------------------------------------------------------

Comment By: Dipl.-Inform. Kai Hofmann (powerstat)
Date: 2002-07-04 04:27

Message:
Logged In: YES 
user_id=286352

Sorry to say, but my experience shows that it is not a
simple set_var("name","") because this is different from a
real unset() !

----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-15 10:13

Message:
Logged In: YES 
user_id=278685

A unset_var() (or clear_var() as I use in my personal 
extension) is simply an alias for set_var("varname", ""). 
Someone may get around to adding such an alias to the 
official library, but it is far less urgent than many 
existing bugs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=543468&group_id=31885

[Phplib-trackers] [ phplib-Feature Requests-577332 ] Template caching

[<no...@so...>]

Feature Requests item #577332, was opened at 2002-07-04 04:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=577332&group_id=31885

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Dipl.-Inform. Kai Hofmann (powerstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Template caching

Initial Comment:
It would be nice to have a kind of template output
caching to speed up template processing. For example
some template outputs will only change in 24 hours or
more.
This will not work for all templates but for a lot it
might bring significant improvement - especially in
combination with php-accelerator.
Maybe it is helpful to take a look at the "Smarty 2.x"
template engine, also please take a look at the
PHP-Accelerator Benchmarks at
http://www.phpinsider.com/benchmarks/


----------------------------------------------------------------------

>Comment By: Layne Weathers (layne_weathers)
Date: 2002-07-05 11:55

Message:
Logged In: YES 
user_id=278685

This is not a Template issue at all. Content caching applies 
to any page whether it's inline or template-based - even static 
HTML pages benefit from caching.

There are many caching engines out there - perhaps we can 
mention those in the documentation.

If PHPLib wants to provide a basic caching mechanism in 
8.x, let's please keep it pure.

----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2002-07-04 15:59

Message:
Logged In: YES 
user_id=279311

There is a patch to enable this in the file attached to:
https://sourceforge.net/tracker/index.php?func=detail&aid=450744&group_id=31885&atid=403614

This won't apply cleanly to the latest template.inc, but
should be a good starting point if you require this
functionality.

I decided against including it in the standard template.inc
because of the additional complexity... maybe I should
re-think that decision.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=577332&group_id=31885

[Phplib-trackers] [ phplib-Feature Requests-577332 ] Template caching

[<no...@so...>]

Feature Requests item #577332, was opened at 2002-07-04 19:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=577332&group_id=31885

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Dipl.-Inform. Kai Hofmann (powerstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Template caching

Initial Comment:
It would be nice to have a kind of template output
caching to speed up template processing. For example
some template outputs will only change in 24 hours or
more.
This will not work for all templates but for a lot it
might bring significant improvement - especially in
combination with php-accelerator.
Maybe it is helpful to take a look at the "Smarty 2.x"
template engine, also please take a look at the
PHP-Accelerator Benchmarks at
http://www.phpinsider.com/benchmarks/


----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-05 06:59

Message:
Logged In: YES 
user_id=279311

There is a patch to enable this in the file attached to:
https://sourceforge.net/tracker/index.php?func=detail&aid=450744&group_id=31885&atid=403614

This won't apply cleanly to the latest template.inc, but
should be a good starting point if you require this
functionality.

I decided against including it in the standard template.inc
because of the additional complexity... maybe I should
re-think that decision.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403614&aid=577332&group_id=31885

[Phplib-trackers] [ phplib-Bugs-561019 ] db_pgsql.inc: lock() causes a warning

[<no...@so...>]

Bugs item #561019, was opened at 2002-05-27 10:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885

Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco Pratesi (pratesi)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_pgsql.inc: lock() causes a warning

Initial Comment:
With the PostgreSQL class, the following code causes a
warning:

$qid = new DB_Sql();
$qid->lock("tablename");

The warning is:

Warning: Supplied argument is not a valid PostgreSQL
link resource...

This is due to the fact that in this case the
constructor issues
an empty query, that causes a "return 0" without issuing
"$this-connect()".
When lock() is requested, the following line is executed:

$result = pg_Exec($this->Link_ID, "lock table $table");

but $this->Link_ID is not a valid link, as connect()
has not been
executed yet.
The problem could be solved using $this->query() instead of
pg_Exec(), in analogy to what is done in db_mysql.inc,
as in the following:

$result = $this->query("lock table $table");


----------------------------------------------------------------------

>Comment By: Marco Pratesi (pratesi)
Date: 2002-07-04 12:26

Message:
Logged In: YES 
user_id=65709

I agree.
I am working on the new development branch of PgMarket
and I could be useful just with testing the MySQL and PgSQL
classes.
I am using the MySQL class taken from 7.4pre1, but, if that
class is too much outdated w.r.t. the CVS, my tests are not
as much useful as they could be.

I am also using the PgSQL class (and I develop mainly
using PostgreSQL rather than MySQL); to solve some problems
I have switched to a CVS snapshot of the PgSQL class + some
changes made by me, that fix some minor problems:

   function unlock() {
-    return pg_Exec($this->Link_ID, "commit");
+    return $this->query("commit");
   }

I have made this change for coherence with the lock() method,
where I have also eliminated an "else" to simplify the code:

   function lock($table, $mode = "write") {
     if ($mode == "write") {
-      $result = pg_Exec($this->Link_ID, "lock table $table");
-    } else {
-      $result = 1;
+       return $this->query("lock table $table");
     }
-    return $result;
+    return 1;
   }

Moreover, I have made the following changes to avoid
the possibility of warnings with error_reporting = E_ALL :

   function f($Name) {
-    return $this->Record[$Name];
+    if (isset($this->Record[$Name])) {
+      return $this->Record[$Name];
+    }
   }

   function p($Name) {
-    print $this->Record[$Name];
+    if (isset($this->Record[$Name])) {
+      print $this->Record[$Name];
+    }
   }

BTW, if I can be helpful for the PHPLib classes I am using,
I am happy to help.
I am also developing some new PHP classes
that are compatible also with PHP3 and that I release
under the GNU LGPL.

Bye,

Marco Pratesi


----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 22:15

Message:
Logged In: YES 
user_id=279065

I say go for it.  

I think getting a packaged pre-release out the door is 
more important at this point in time than trying to scare 
up the people and resources to do that kind of coverage 
testing.

..chris

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-03 21:56

Message:
Logged In: YES 
user_id=19736

> Maybe we should just bite the bullet and commit this stuff
> to -stable and then fix any problems which arise.

Yes please :)  

That's what the -pre's are for.. to suss out the bugs by the
advertursome and intelligent users before releasing to the
masses.

----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2002-07-03 21:46

Message:
Logged In: YES 
user_id=279311

I did a lot of work on some of the db classes (MySQL, OCI8,
ODBC come to mind). But I don't have most of those other
databases running to test with. I think you'll find most of
my work is in the devel tree only. I wasn't willing to
commit untested code to the -stable tree.

For example, the odbc driver in devel has *heaps* of
improvements and bug fixes. It even implements lock(). While
I did have an ODBC datasource at the time, I wasn't willing
to commit a 500 line patch to -stable based on my
development testing alone. 

Maybe we should just bite the bullet and commit this stuff
to -stable and then fix any problems which arise.


----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 21:05

Message:
Logged In: YES 
user_id=279065

I thought one of our fearless programmers had gone 
through the db_* classes and made them more uniform?  
Or was a I dreaming?

..chris

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885

[Phplib-trackers] [ phplib-Bugs-540956 ] default login problem solved (login_if)

[<no...@so...>]

Bugs item #540956, was opened at 2002-04-08 05:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=540956&group_id=31885

Category: docs
Group: current CVS
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Dr Tarique Sani (tarique)
Summary: default login problem solved (login_if)

Initial Comment:
Hi, i solved a login_if problem. I wonder if someone else experienced this issue!?.

PHPlib 7.2 under Linux 2.4.10 (SuSE 7.3) with Konqueror.

By using the default login feature (var $nobody = true;)i discovered a problem while login in as a specific user (via url?again=yes): 
The login form claimed 'Either your username ... are invalid' even if i definitly put in the correct username/password.

I found a vulnerability (bug?) in the *loginform.ihtml files: They use 

<form name="login" action="<?php print $this->url() ?>" method=post> 

to redirect to the page you come from. 
Unfortunately this gives the 'again=yes' back and results in a 'login-loop'.

Hint: Replace the PHP line above with:

<form name="login" action="<?php 
    $full_url = $this->url();
    $url = substr($full_url,0,strpos($full_url,"?"));
    print $url; ?>" method=post>

This should fix the problem.
Sascha

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-04 05:24

Message:
Logged In: NO 

Hi Nathan,

your solution with 'ereg_replace' is much smarter than mine ;-) BUT:
My understanding is, that everyone working with 'default login' is experiencing this issue. Therefore it might make sense to implement this into the library itself. 
By creating an object inherited from 'Auth' the programmer is able to decide if 'default login' is allowed. What about to define the magic token (default 'again=yes') in this context. Then the actual code is able to remove this during the login procedure.

Cheers,
Sascha

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-03 14:28

Message:
Logged In: YES 
user_id=19736

Becasue the ?again=yes syntax is specfic to the example pages.  

There's no magic flag in the auth code the looks for again
and forces a login if it's there, that is left up to the end
user.  IMHO, this is better becasie it can be more flexible
(a developer can use any flag they so desire); however, it
also means that the user/devloper needs to remove her
specific relogin flag at reauth time to avoid the loop.

It's a doc bug because I don't think it's clear that the
again=yes symantics are examples, and not hardcoded class
restrictions.  Also, the documentation should be updated to
remind the devloper to remove her flag before begining the
login process.

In the end it may be better to implement this is a class
option; however I don't feel that is a prudent thing to do
in 7.x.

----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-03 13:54

Message:
Logged In: YES 
user_id=279065

Why is this a doc bug instead of fixing code as suggested 
in defauth.php3?

Color me confused,
..chris

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-02 13:09

Message:
Logged In: YES 
user_id=19736

Wouldn't this crush any GET requests during the login
process?  The 'again' needs to be stripped but not all of
the GET request.

See comment in top of pages/defauth.php3 for a better way to
remove the 'again'.

Well. that's a pain.. here's the copy.. :)
  // Remove the "again=yes" from QUERY_STRING. This is required
  // because the login form will be submitted to the URL of this
  // page. This URL is constructed from $PHP_SELF and
$QUERY_STRING.
  // So, we need to remove this parameter from QUERY_STRING
or else
  // after the user submits a username and password, we will
unauth 
  // them before they even get logged in!
  $HTTP_SERVER_VARS["QUERY_STRING"] = ereg_replace(
    "(^|&)again=yes(&|$)",
    "\1", $HTTP_SERVER_VARS["QUERY_STRING"]);

Marking this as a documentation bug, as it something that
needs to be added to the docs
 :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=540956&group_id=31885