Good heavens! Did you post to phpwiki-talk? I haven't done any development on PhpWiki in over a year, just doing the releases. Jeff Dairiki is the principle architect over the last two years; I'm sure they can pinpoint the problems very quickly! ~swain On 2003年3月27日, David E. Weekly wrote: > Steve, > > I need your help; our company is about to give up on PHP Wiki, declaring it > "too broken to use"! It has been badly corrupting large files, freezing when > tables get too large, etc. Please call me at (deleted by swain) as soon as you > can. I'd love to see PHP Wiki widely implemented, but I've seen these bugs > and they're bad. > > Yours, > David > > > > > > --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa
Steve, Thanks for getting back to me. Jeff and others - our company has vigorously adopted PHPWiki in part due to my strong recommendations and prior experience working with this wiki. We've encountered a number of issues with PHPWiki, however, the most serious by far being corruption of large documents. When we take a large wiki node, edit it, preview it, and save it, whole paragraphs are duplicated in the result. This is not operator error - it's happened several times, even from cut-and-pasting from a text editor window! I'm unclear as to what is causing this corruption, but it has rendered the wiki all but unuseable for large documents. There are other somewhat less serious issues, too -- when a wiki node has a large table in it (>200 rows) it simply freezes up the machine. PHP times out after 30 seconds and cancels the page load. "Document History" does not appear to work correctly for documents that have been edited a large number of times. (It does not show the most recent changes made.) Also, our listing of RecentChanges seems to have stopped about seven days ago. While these are all issues I'd like to see resolved, without the first -- namely fixing the corruption issue, we're going to have to switch to a different wiki. Have any of you guys seen this? Is this a misconfiguration? Is it a bug with an easy fix? We're using MySQL 3.23.49 as the backing store, PHP 4.3.1 with MySQL, Apache 2.0.43, and PEAR v1.50. This is using PHPWiki 1.3.4. One patch that you might want to know about (tiny) is in lib/config.php, where in order to support Apache2, this line: if (php_sapi_name() == 'apache') got changed to this line: if (php_sapi_name() == 'apache' || php_sapi_name() == 'apache2filter') Could it be something about our Apache2 interactions that's messing things up? Please help! :) Cheerio, Dave Weekly Developer, There.com ----- Original Message ----- From: "Steve Wainstead" <sw...@pa...> To: "David E. Weekly" <da...@we...> Cc: <php...@li...> Sent: Thursday, March 27, 2003 11:51 AM Subject: Re: Serious PHP Wiki Issue > > Good heavens! Did you post to phpwiki-talk? I haven't done any development > on PhpWiki in over a year, just doing the releases. Jeff Dairiki is the > principle architect over the last two years; I'm sure they can pinpoint > the problems very quickly! > > ~swain > > > On 2003年3月27日, David E. Weekly wrote: > > > Steve, > > > > I need your help; our company is about to give up on PHP Wiki, declaring it > > "too broken to use"! It has been badly corrupting large files, freezing when > > tables get too large, etc. Please call me at (deleted by swain) as soon > as you > > can. I'd love to see PHP Wiki widely implemented, but I've seen these bugs > > and they're bad. > > > > Yours, > > David > > > > > > > > > > > > > > --- > http://www.panix.com/~swain/ > "Without music to decorate it, time is just a bunch of boring > production deadlines or dates by which bills must be paid." > -- Frank Zappa >
On 2003年3月27日, David E. Weekly wrote: > When we take a large wiki node, edit it, preview it, and save it, whole > paragraphs are duplicated in the result. This is not operator error - it's > happened several times, even from cut-and-pasting from a text editor window! > I'm unclear as to what is causing this corruption, but it has rendered the > wiki all but unuseable for large documents. If you could provide a samlpe doc, that would be helpful. It's probably too large to send to the list, so you could send it to me directly and I could forward it, or else you could dump it into the demo or test sites: http://phpwiki.sourceforge.net/test/index.php/HomePage (the nightly build) http://phpwiki.sourceforge.net/demo/ (is probably closer to 1.3.4) > There are other somewhat less serious issues, too -- when a wiki node has a > large table in it (>200 rows) it simply freezes up the machine. HTML table, I take it... hmm... > PHP times > out after 30 seconds and cancels the page load. "Document History" does not > appear to work correctly for documents that have been edited a large number > of times. (It does not show the most recent changes made.) Also, our listing > of RecentChanges seems to have stopped about seven days ago. I'd wager the database has proprietary info, otherwise I'd try to get a mysqldump that one of us could set up and test.. ~swain > > ----- Original Message ----- > From: "Steve Wainstead" <sw...@pa...> > To: "David E. Weekly" <da...@we...> > Cc: <php...@li...> > Sent: Thursday, March 27, 2003 11:51 AM > Subject: Re: Serious PHP Wiki Issue > > > > > > Good heavens! Did you post to phpwiki-talk? I haven't done any development > > on PhpWiki in over a year, just doing the releases. Jeff Dairiki is the > > principle architect over the last two years; I'm sure they can pinpoint > > the problems very quickly! > > > > ~swain > > > > > > On 2003年3月27日, David E. Weekly wrote: > > > > > Steve, > > > > > > I need your help; our company is about to give up on PHP Wiki, declaring > it > > > "too broken to use"! It has been badly corrupting large files, freezing > when > > > tables get too large, etc. Please call me at (deleted by swain) as soon > > as you > > > can. I'd love to see PHP Wiki widely implemented, but I've seen these > bugs > > > and they're bad. > > > > > > Yours, > > > David > > > > > > > > > > > > > > > > > > > > > > --- > > http://www.panix.com/~swain/ > > "Without music to decorate it, time is just a bunch of boring > > production deadlines or dates by which bills must be paid." > > -- Frank Zappa > > > > > > > --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa
> How large is large? Qualitatively speaking, about 50+ lines of text. More data as we get more reproduction cases. > Could the problem be browser dependent? Doesn't seem to be so far. > > There are other somewhat less serious issues, too -- when a wiki node > > has a large table in it (>200 rows) it simply freezes up the machine. > > Is this a "new-style" table or an old-style table (via the OldStyleTable > plugin)? Is there an example at a publicly accessable URL? New-style. The URL is not accessible, as it is an intranet wiki with confidential information. :( > Or can you send me some example wiki-text which will trigger the bug? Trigger the table bug? I will post a page to the master phpwiki. > (Do you really mean "freezes up the machine"? Do other > concurrent requests to the web server get hung?) No, but that Apache process goes bonkers, consuming huge amounts of CPU. PHP terminates it after 30 seconds, giving up. > Are you sure that things are happy on the MySQL front? > (Run (my)isamchk on the tables. Any filesystem errors? Enough disk > space?) myisamchk succeeds on the .MYI files. The partition has used 1.5GB and has 1.8GB free, which means it is 43% used. > > if (php_sapi_name() == 'apache' || php_sapi_name() == 'apache2filter') > > (This has been fixed in CVS.) Cool. I will continue trying to reproduce this issue in a consistent fashion to see what is breaking. -david
"David E. Weekly" <da...@we...> writes: >> How large is large? > > Qualitatively speaking, about 50+ lines of text. More data as we get > more reproduction cases. After I changed the columns in the tables to LONGTEXT, then I'm able to deal with a ~210 KiB page here: http://www.gimpster.com/wiki/CommandLine Before that change, the text on the page got truncated to 2^16 bytes which is the capacity of a TEXT column in MySQL. I guess a MEDIUMTEXT column with a capacity of 2^24 bytes = 16 MiB would suffice for most pages. -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather: Shows the current weather on your webpage and PHP Shell: A telnet-connection (almost :-) in a PHP page. Join Freenet: http://gimpster.com/downloads/freenet/
On 2003年3月28日, Martin Geisler wrote: > Before that change, the text on the page got truncated to 2^16 bytes > which is the capacity of a TEXT column in MySQL. I guess a MEDIUMTEXT > column with a capacity of 2^24 bytes = 16 MiB would suffice for most > pages. Hmm. But the page column was always a MEDIUMTEXT; it is in CVS right now... ~swain > > -- > Martin Geisler My GnuPG Key: 0xF7F6B57B > > See http://gimpster.com/ and http://phpweather.net/ for: > PHP Weather: Shows the current weather on your webpage and > PHP Shell: A telnet-connection (almost :-) in a PHP page. > Join Freenet: http://gimpster.com/downloads/freenet/ > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > > > --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa
Steve Wainstead <sw...@pa...> writes: > On 2003年3月28日, Martin Geisler wrote: > >> Before that change, the text on the page got truncated to 2^16 bytes >> which is the capacity of a TEXT column in MySQL. I guess a MEDIUMTEXT >> column with a capacity of 2^24 bytes = 16 MiB would suffice for most >> pages. > > Hmm. But the page column was always a MEDIUMTEXT; it is in CVS right > now... Yes, you're right... I checked the log in CVS and it says that it's always been MEDIUMTEXT... Thinking back, then I must have changed it when I was playing with using full-text indexes in MySQL. They are (unfortunately) only allowed on TEXT columns. By the way, a full-text index worked well for me, giving me relevant hits for my searches. -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather: Shows the current weather on your webpage and PHP Shell: A telnet-connection (almost :-) in a PHP page. Join Freenet: http://gimpster.com/downloads/freenet/
Steve, Thanks for getting back to me. Jeff and others - our company has vigorously adopted PHPWiki in part due to my strong recommendations and prior experience working with this wiki. We've encountered a number of issues with PHPWiki, however, the most serious by far being corruption of large documents. When we take a large wiki node, edit it, preview it, and save it, whole paragraphs are duplicated in the result. This is not operator error - it's happened several times, even from cut-and-pasting from a text editor window! I'm unclear as to what is causing this corruption, but it has rendered the wiki all but unuseable for large documents. There are other somewhat less serious issues, too -- when a wiki node has a large table in it (>200 rows) it simply freezes up the machine. PHP times out after 30 seconds and cancels the page load. "Document History" does not appear to work correctly for documents that have been edited a large number of times. (It does not show the most recent changes made.) Also, our listing of RecentChanges seems to have stopped about seven days ago. While these are all issues I'd like to see resolved, without the first -- namely fixing the corruption issue, we're going to have to switch to a different wiki. Have any of you guys seen this? Is this a misconfiguration? Is it a bug with an easy fix? We're using MySQL 3.23.49 as the backing store, PHP 4.3.1 with MySQL, Apache 2.0.43, and PEAR v1.50. This is using PHPWiki 1.3.4. One patch that you might want to know about (tiny) is in lib/config.php, where in order to support Apache2, this line: if (php_sapi_name() == 'apache') got changed to this line: if (php_sapi_name() == 'apache' || php_sapi_name() == 'apache2filter') Could it be something about our Apache2 interactions that's messing things up? Please help! :) Cheerio, Dave Weekly Developer, There.com ----- Original Message ----- From: "Steve Wainstead" <sw...@pa...> To: "David E. Weekly" <da...@we...> Cc: <php...@li...> Sent: Thursday, March 27, 2003 11:51 AM Subject: Re: Serious PHP Wiki Issue > > Good heavens! Did you post to phpwiki-talk? I haven't done any development > on PhpWiki in over a year, just doing the releases. Jeff Dairiki is the > principle architect over the last two years; I'm sure they can pinpoint > the problems very quickly! > > ~swain > > > On 2003年3月27日, David E. Weekly wrote: > > > Steve, > > > > I need your help; our company is about to give up on PHP Wiki, declaring it > > "too broken to use"! It has been badly corrupting large files, freezing when > > tables get too large, etc. Please call me at (deleted by swain) as soon > as you > > can. I'd love to see PHP Wiki widely implemented, but I've seen these bugs > > and they're bad. > > > > Yours, > > David > > > > > > > > > > > > > > --- > http://www.panix.com/~swain/ > "Without music to decorate it, time is just a bunch of boring > production deadlines or dates by which bills must be paid." > -- Frank Zappa >
> When we take a large wiki node, edit it, preview it, and save it, whole > paragraphs are duplicated in the result. This is not operator error - > it's happened several times, even from cut-and-pasting from a text > editor window! I'm unclear as to what is causing this corruption, but it > has rendered the wiki all but unuseable for large documents. How large is large? Could the problem be browser dependent? (I vaguely remember stories about some browsers having issues when the data in the textareas gets to be larger than a certain size (32K or 64K).) > There are other somewhat less serious issues, too -- when a wiki node > has a large table in it (>200 rows) it simply freezes up the machine. Is this a "new-style" table or an old-style table (via the OldStyleTable plugin)? Is there an example at a publicly accessable URL? Or can you send me some example wiki-text which will trigger the bug? (Do you really mean "freezes up the machine"? Do other concurrent requests to the web server get hung?) > "Document History" does not > appear to work correctly for documents that have been edited a large > number of times. (It does not show the most recent changes made.) Also, > our listing of RecentChanges seems to have stopped about seven days ago. Those problems sound related. I've never seen nor heard of behavior like that before. Are you sure that things are happy on the MySQL front? (Run (my)isamchk on the tables. Any filesystem errors? Enough disk space?) > Have any of you guys seen this? I haven't. > if (php_sapi_name() == 'apache' || php_sapi_name() == 'apache2filter') (This has been fixed in CVS.) > Could it be something about our Apache2 interactions that's messing > things up? I doubt it, but I don't have an alternative theory either, so who knows?
Hello, first... thanks for this software!.. I like the theme stuff and the easy to install stuff. Now.. problems: after a server software update (berlios.de swiching to the latest php version) my wiki has crash. this is the error msg: lib/DbaDatabase.php:32: Fatal[256]: driver initialization failed ------------------------------------------------------------------------ Fatal PhpWiki Error lib/DbaDatabase.php:32: Fatal[256]: driver initialization failed I am working off line with the gdbm file to rescue the wiki data ( 9MB of data ) but is hard because my localhost apache+php dont support gdbm files, I suspect. I want to: * fix the error or * rescue the data Something help will be wellcome. --Tei telejano.berlios.de/wiki3
Quoting Tei (42...@in...): > > Hello, first... thanks for this software!.. I like the theme stuff and > the easy to install stuff. Now.. problems: > > after a server software update (berlios.de swiching to the latest php > version) my wiki has crash. this is the error msg: > > lib/DbaDatabase.php:32: Fatal[256]: driver initialization failed Hi, Loooks like you may have forgotten to compile in the database driver with php. That would be my guess. That, or the database isn't running, or accepting connections. jeremy -- Jeremy Kelley <je...@au...> Information Security Analyst