DB.php is part of the PEAR library of useful PHP code. It is distributed as part of the more recent PHP distributions (at least since 4.0.4pl1, probably since before that.)
It's probably somewhere on your system. Try
looking for:
/usr/lib/php/DB.php
/usr/local/lib/php/DB.php
/usr/share/php/DB.php
/usr/local/share/php/DB.php
(Or on a unix/linux system try running
'locate DB.php'
)
Then, in index.php (near the top, in "Part
Zero") put in something like:
ini_set('include_path', '.:/usr/lib/php')
But wait! Your troubles are not over.
(Well, they might not be.) Apparently,
some release versions of DB.php are buggy
enough that PhpWiki won't run with them.
(If you get some error messages, one of
which involves the message "(LOCK TABLES...)",
that's the problem I'm talking about...)
I have a kludgy fix for this problem, and
I'm working on writing a README as well as
a better long-term solution to the buggy DB.php
problem. (Write to me, if you're in a big rush
to get things working and I'll tell you the
kludgy fix --- otherwise hold on for a day or
two...)
Jeff <dairiki@dairiki.org>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the clues.
My situation is even worse - I need it running on the win2k box :-) My PHP installation was tool old so I've downloaded the latest distribution from the php.net and Pear was there. After some tuning the message You mentioned was on my screen.
Well, I've commented out some lines in mysql.php and now it works with the cost of not locking/unlocking tables. As for a couple of days (weeks) I'll be the only person to access this wiki it seems to be the solution :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just (a few hours ago) checked in some fixes to the new PhpWiki code which fix/work-around the bugs in PHP 4.0.6's version PEAR DB.php.
So if you get the latest PhpWiki code from the CVS, (and you have the PEAR DB code from any PHP distribution at least a recent as 4.0.4pl1,) it should just work.
(Let me know if it doesn't.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It works fine with little patch to pear/DB/mysql.php - one should add 0 => 0 mapping to errorcode_map to stop PHP warnings about 'undefined offset: 0'.
Thanks again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought I'd kludged up the PhpWiki code enough to hide that notice...
(See WikiDB_backend_PearDB::_pear_notice_filter()
in lib/WikiDB/backend/PearDB.php.)
Can you quote me the exact error notice your getting (including the reported source file and line number)? I'll add it to the filter.
(The reason for these gyrations, is that I'd like to avoid having to force users to patch PEAR code...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems that /lib/WikiDB/backend/DB.php file is not in CVS so SQL backends cannot work.
Sorry for typo :-)
Hi.
DB.php is part of the PEAR library of useful PHP code. It is distributed as part of the more recent PHP distributions (at least since 4.0.4pl1, probably since before that.)
It's probably somewhere on your system. Try
looking for:
/usr/lib/php/DB.php
/usr/local/lib/php/DB.php
/usr/share/php/DB.php
/usr/local/share/php/DB.php
(Or on a unix/linux system try running
'locate DB.php'
)
Then, in index.php (near the top, in "Part
Zero") put in something like:
ini_set('include_path', '.:/usr/lib/php')
But wait! Your troubles are not over.
(Well, they might not be.) Apparently,
some release versions of DB.php are buggy
enough that PhpWiki won't run with them.
(If you get some error messages, one of
which involves the message "(LOCK TABLES...)",
that's the problem I'm talking about...)
I have a kludgy fix for this problem, and
I'm working on writing a README as well as
a better long-term solution to the buggy DB.php
problem. (Write to me, if you're in a big rush
to get things working and I'll tell you the
kludgy fix --- otherwise hold on for a day or
two...)
Jeff <dairiki@dairiki.org>
Thanks for the clues.
My situation is even worse - I need it running on the win2k box :-) My PHP installation was tool old so I've downloaded the latest distribution from the php.net and Pear was there. After some tuning the message You mentioned was on my screen.
Well, I've commented out some lines in mysql.php and now it works with the cost of not locking/unlocking tables. As for a couple of days (weeks) I'll be the only person to access this wiki it seems to be the solution :-)
I just (a few hours ago) checked in some fixes to the new PhpWiki code which fix/work-around the bugs in PHP 4.0.6's version PEAR DB.php.
So if you get the latest PhpWiki code from the CVS, (and you have the PEAR DB code from any PHP distribution at least a recent as 4.0.4pl1,) it should just work.
(Let me know if it doesn't.)
It works fine with little patch to pear/DB/mysql.php - one should add 0 => 0 mapping to errorcode_map to stop PHP warnings about 'undefined offset: 0'.
Thanks again.
I thought I'd kludged up the PhpWiki code enough to hide that notice...
(See WikiDB_backend_PearDB::_pear_notice_filter()
in lib/WikiDB/backend/PearDB.php.)
Can you quote me the exact error notice your getting (including the reported source file and line number)? I'll add it to the filter.
(The reason for these gyrations, is that I'd like to avoid having to force users to patch PEAR code...)
Here it is:
c:\progra~1\php\pear\DB\common.php:126: Notice[8]: Undefined offset: 0
You should tear off the Pear lib path from the errfile.
Thanks! I just checked in a fix.
If it doesn't work, let me know.
It doesn't :-)
For some strange reason I needed to add the third backslash to make it to work.
...
&& preg_match('|DB[/\\\]common.php$|', $err->errfile));
...
Doh! Fun with regexps...
I think it's fixed again. I put four backslashes in there, just for the sake of symmetry.
Thanks for the help!