You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(103) |
Jul
(105) |
Aug
(16) |
Sep
(16) |
Oct
(78) |
Nov
(36) |
Dec
(58) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(100) |
Feb
(155) |
Mar
(84) |
Apr
(33) |
May
(22) |
Jun
(77) |
Jul
(36) |
Aug
(37) |
Sep
(183) |
Oct
(74) |
Nov
(235) |
Dec
(165) |
2002 |
Jan
(187) |
Feb
(183) |
Mar
(52) |
Apr
(10) |
May
(15) |
Jun
(19) |
Jul
(43) |
Aug
(90) |
Sep
(144) |
Oct
(144) |
Nov
(171) |
Dec
(78) |
2003 |
Jan
(113) |
Feb
(99) |
Mar
(80) |
Apr
(44) |
May
(35) |
Jun
(32) |
Jul
(34) |
Aug
(34) |
Sep
(30) |
Oct
(57) |
Nov
(97) |
Dec
(139) |
2004 |
Jan
(132) |
Feb
(223) |
Mar
(300) |
Apr
(221) |
May
(171) |
Jun
(286) |
Jul
(188) |
Aug
(107) |
Sep
(97) |
Oct
(106) |
Nov
(139) |
Dec
(125) |
2005 |
Jan
(200) |
Feb
(116) |
Mar
(68) |
Apr
(158) |
May
(70) |
Jun
(80) |
Jul
(55) |
Aug
(52) |
Sep
(92) |
Oct
(141) |
Nov
(86) |
Dec
(41) |
2006 |
Jan
(35) |
Feb
(62) |
Mar
(59) |
Apr
(52) |
May
(51) |
Jun
(61) |
Jul
(30) |
Aug
(36) |
Sep
(12) |
Oct
(4) |
Nov
(22) |
Dec
(34) |
2007 |
Jan
(49) |
Feb
(19) |
Mar
(37) |
Apr
(16) |
May
(9) |
Jun
(38) |
Jul
(17) |
Aug
(31) |
Sep
(16) |
Oct
(34) |
Nov
(4) |
Dec
(8) |
2008 |
Jan
(8) |
Feb
(16) |
Mar
(14) |
Apr
(6) |
May
(4) |
Jun
(5) |
Jul
(9) |
Aug
(36) |
Sep
(6) |
Oct
(3) |
Nov
(3) |
Dec
(3) |
2009 |
Jan
(14) |
Feb
(2) |
Mar
(7) |
Apr
(16) |
May
(2) |
Jun
(10) |
Jul
(1) |
Aug
(10) |
Sep
(11) |
Oct
(4) |
Nov
(2) |
Dec
|
2010 |
Jan
(1) |
Feb
|
Mar
(13) |
Apr
(11) |
May
(18) |
Jun
(44) |
Jul
(7) |
Aug
(2) |
Sep
(14) |
Oct
|
Nov
(6) |
Dec
|
2011 |
Jan
(2) |
Feb
(6) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(11) |
Feb
(3) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(1) |
2015 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2016 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
(11) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
(3) |
2024 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Harold H. <ha...@ha...> - 2022-01-17 19:27:57
|
THANKS for all your work on this! I moved the latest_ver, links, page_data, and ver_data to a backup directory, created new empty files, then did a restore from a downloaded dump zip. All looks good so far with the garbage files gone. I'll check in a few days to make sure they do not reappear as people try to hack the system. THANKS! Harold On Mon, January 17, 2022 4:04 am, Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay) wrote: > Hi Harold, > > With the modification introduced in Subversion 10904, accessing a > non-existent page should no longer create a file in page_data directory. > Please test it is working for you. > > I expect to publish PhpWiki 1.6.1 soon. > > Best regards, > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Monday, January 17, 2022 5:27 AM > To: php...@li... > Subject: Re: [Phpwiki-talk] Issues with Wiki Dump and Garbage in page_data > > Done! Actually, the method of my previous updates was pretty poor, and I > ended up with nested versions. So, it was difficult to tell what version > was actually running. I have now just unzipped version 10904, renamed it, > and copied over my old config.ini after comparing it with config-dist to > see what changes needed to be made. It appears to be working! > > So, back to the original question. Are files now created in page_data and > ver_data when a nonexistant page is requested? Again, my DB method is > file. I have a lot of trash in those two directories. > > I don't see an easy way of getting rid of the trash other than doing a > dump of the wiki, deleting everything in those directories, then doing a > respore. Is this a reasonable approach? > > THANKS! > > Harold > > > On Sun, January 16, 2022 12:43 pm, Vargenau, Marc-Etienne (Nokia - > FR/Paris-Saclay) wrote: >> Hi Harold, >> >> Can you please update to Subversion 10904 and test? >> >> Also, can you do an >> https://bh.hallikainen.org/wiki/index.php/HomePage?action=upgrade&over >> write=1 you have quite old versions of system files like >> PhpWikiAdministration >> >> Best regards, >> >> Marc-Etienne >> >> -----Original Message----- >> From: Harold Hallikainen <ha...@ha...> >> Sent: Saturday, January 15, 2022 11:43 PM >> To: php...@li... >> Subject: Re: [Phpwiki-talk] Issues with Wiki Dump >> >> Thanks for the QUICK response! >> >> I ran >> >> dnf install php-zip >> service httpd restart >> >> and it works! >> >> >> I am using the flat file database. In wiki_data, I find page_data and >> ver_data. It LOOKS like ver_data has all versions of the page while >> page_data has just the most current. I have tried deleting the files >> in page_data and then looking at the wiki. The latest versions of the >> pages still show up, and are then added to page_data. >> >> Since access data is stored in the page file, every time someone tries >> to access a page that does not exist, it appears that an appropriate >> file is created to hold that access data. As people try to hack the >> system, I end up with files like those below in page_data. >> >> >> %27A >> %28%29 >> %28CASE+WHEN+%283541%3D3541%29+THEN+3541+ELSE+3541%2A%28SELECT+3541+FR >> OM+DUAL+UNION+SELECT+2885+FROM+DUAL%29+END%29 >> %28CASE+WHEN+%284882%3D2501%29+THEN+4882+ELSE+4882%2A%28SELECT+4882+FR >> OM+DUAL+UNION+SELECT+2501+FROM+DUAL%29+END%29 >> %28CASE+WHEN+%289302%3D9302%29+THEN+SLEEP%2832%29+ELSE+9302+END%29 >> %28CASE+WHEN+4772%3D4772+THEN+4772+ELSE+NULL+END%29 >> %28CASE+WHEN+7219%3D9319+THEN+7219+ELSE+NULL+END%29 >> %28SELECT+%28CASE+WHEN+%283521%3D3521%29+THEN+%27RCA%27+ELSE+%28SELECT >> +5220+UNION+SELECT+3216%29+END%29%29 >> %28SELECT+%28CASE+WHEN+%289983%3D6874%29+THEN+%27RCA%27+ELSE+%28SELECT >> +6874+UNION+SELECT+8819%29+END%29%29 >> %28SELECT+CONCAT%280x7162716a71%2C%28ELT%284931%3D4931%2C1%29%29%2C0x7 >> 17a767871%29%29 >> %28SELECT+CONCAT%280x716a6b7071%2C%28ELT%282020%3D2020%2C1%29%29%2C0x7 >> 17a786b71%29%29 >> %28SELECT+CONCAT%280x7170717171%2C%28ELT%281739%3D1739%2C1%29%29%2C0x7 >> 171627a71%29%29 >> %28SELECT+CONCAT%280x7176627171%2C%28ELT%289244%3D9244%2C1%29%29%2C0x7 >> 16a717a71%29%29 >> %28SELECT+CONCAT%280x71766a7871%2C%28ELT%285835%3D5835%2C1%29%29%2C0x7 >> 178787871%29%29 >> %28SELECT+CONCAT%280x717a7a6271%2C%28ELT%284238%3D4238%2C1%29%29%2C0x7 >> 1626a6b71%29%29 >> %28SELECT+CONCAT%28CONCAT%28%27qbqjq%27%2C%28CASE+WHEN+%283392%3D3392% >> 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qzvxq%27%29%29 >> %28SELECT+CONCAT%28CONCAT%28%27qjkpq%27%2C%28CASE+WHEN+%284051%3D4051% >> 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qzxkq%27%29%29 >> %28SELECT+CONCAT%28CONCAT%28%27qpqqq%27%2C%28CASE+WHEN+%282945%3D2945% >> 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qqbzq%27%29%29 >> %28SELECT+CONCAT%28CONCAT%28%27qvbqq%27%2C%28CASE+WHEN+%281904%3D1904% >> 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qjqzq%27%29%29 >> %28SELECT+CONCAT%28CONCAT%28%27qvjxq%27%2C%28CASE+WHEN+%281582%3D1582% >> 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qxxxq%27%29%29 >> %28SELECT+CONCAT%28CONCAT%28%27qzzbq%27%2C%28CASE+WHEN+%282980%3D2980% >> 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qbjkq%27%29%29 >> >> When I unzip the dump, I do not see those filenames, so that's good! >> So, how do I get rid of these "hack" files? Maybe empty the page_data >> and page_ver directories, then do a restore? >> >> Also, it would be great if an attempt to access a non-existent page >> would not create a file for it. >> >> THANKS! >> >> Harold >> >> >> >> >> >> On Sat, January 15, 2022 2:36 pm, Vargenau, Marc-Etienne (Nokia - >> FR/Paris-Saclay) wrote: >>> Hi Harold, >>> 'ZipArchive' is a standard class of PHP since PHP 5.2.0 >>> https://www.php.net/manual/en/class.ziparchive >>> Probably your PHP is not compiled with that class. >>> You should check with phpinfo(). >>> Best regards, >>> Marc-Etienne >>> -----Original Message----- >>> From: Harold Hallikainen <ha...@ha...> >>> Sent: Saturday, January 15, 2022 8:23 PM >>> To: Harold Hallikainen <ha...@ha...> >>> Cc: Discussion on PhpWiki features, bugs, development. >>> <php...@li...> >>> Subject: [Phpwiki-talk] Issues with Wiki Dump I am having issues with >>> the wiki dump. Here are the PHP error messages: >> [15-Jan-2022 18:55:17 UTC] PHP Fatal error: Uncaught Error: Class >> 'ZipArchive' not found in >>> /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 >>> Stack trace: >>> #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): >>> MakeWikiZip(Object(WikiRequest)) >>> #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): >>> WikiRequest->action_zip() >>> #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): >>> WikiRequest->handleAction() >>> #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 >> /home/harold/public_html/org/bh/wiki/index.php(60): >>> include('/home/harold/pu...') >>> #5 {main} >>> thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on >> line >>> 217 >>> [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MinPage in >> /home/harold/public_html/fr/index.php on line 9 >>> [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MaxPage in >> /home/harold/public_html/fr/index.php on line 10 >>> [15-Jan-2022 18:56:00 UTC] PHP Notice: Undefined index: HOME in >> /home/harold/public_html/org/w6iwi/script/rbn.php on line 108 >>> [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MinPage in >> /home/harold/public_html/fr/index.php on line 9 >>> [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MaxPage in >> /home/harold/public_html/fr/index.php on line 10 >>> [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MinPage in >> /home/harold/public_html/fr/index.php on line 9 >>> [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MaxPage in >> /home/harold/public_html/fr/index.php on line 10 >>> [15-Jan-2022 18:56:35 UTC] PHP Fatal error: Uncaught Error: Class >> 'ZipArchive' not found in >>> /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 >>> Stack trace: >>> #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): >>> MakeWikiZip(Object(WikiRequest)) >>> #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): >>> WikiRequest->action_zip() >>> #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): >>> WikiRequest->handleAction() >>> #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 >> /home/harold/public_html/org/bh/wiki/index.php(60): >>> include('/home/harold/pu...') >>> #5 {main} >>> thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on >> line >>> 217 >>> Using Dump To Directory, a lot of files (perhaps all) show up in the >> specified directory, but this error message appears at the bottom of >> the page. >>> Fatal PhpWiki Error: couldn't open file "/home/harold/tmp/wikidump/" >>> for >> writing >>> I just updated to phpwiki-code-r10903-trunk and the errors still >> appear. >>> I am going to try a restore from the dump to directory since it looks >> like >>> it may be working. >>> THANKS! >>> Harold >>> _______________________________________________ >>> Phpwiki-talk mailing list >>> Php...@li... >>> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk >>> _______________________________________________ >>> Phpwiki-talk mailing list >>> Php...@li... >>> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk >> >> >> -- >> FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an >> iPhone. >> >> >> >> >> >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk >> >> >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk >> >> > > > -- > FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an > iPhone. > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2022-01-17 12:37:57
|
Hi Harold, With the modification introduced in Subversion 10904, accessing a non-existent page should no longer create a file in page_data directory. Please test it is working for you. I expect to publish PhpWiki 1.6.1 soon. Best regards, Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Monday, January 17, 2022 5:27 AM To: php...@li... Subject: Re: [Phpwiki-talk] Issues with Wiki Dump and Garbage in page_data Done! Actually, the method of my previous updates was pretty poor, and I ended up with nested versions. So, it was difficult to tell what version was actually running. I have now just unzipped version 10904, renamed it, and copied over my old config.ini after comparing it with config-dist to see what changes needed to be made. It appears to be working! So, back to the original question. Are files now created in page_data and ver_data when a nonexistant page is requested? Again, my DB method is file. I have a lot of trash in those two directories. I don't see an easy way of getting rid of the trash other than doing a dump of the wiki, deleting everything in those directories, then doing a respore. Is this a reasonable approach? THANKS! Harold On Sun, January 16, 2022 12:43 pm, Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay) wrote: > Hi Harold, > > Can you please update to Subversion 10904 and test? > > Also, can you do an > https://bh.hallikainen.org/wiki/index.php/HomePage?action=upgrade&over > write=1 you have quite old versions of system files like > PhpWikiAdministration > > Best regards, > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Saturday, January 15, 2022 11:43 PM > To: php...@li... > Subject: Re: [Phpwiki-talk] Issues with Wiki Dump > > Thanks for the QUICK response! > > I ran > > dnf install php-zip > service httpd restart > > and it works! > > > I am using the flat file database. In wiki_data, I find page_data and > ver_data. It LOOKS like ver_data has all versions of the page while > page_data has just the most current. I have tried deleting the files > in page_data and then looking at the wiki. The latest versions of the > pages still show up, and are then added to page_data. > > Since access data is stored in the page file, every time someone tries > to access a page that does not exist, it appears that an appropriate > file is created to hold that access data. As people try to hack the > system, I end up with files like those below in page_data. > > > %27A > %28%29 > %28CASE+WHEN+%283541%3D3541%29+THEN+3541+ELSE+3541%2A%28SELECT+3541+FR > OM+DUAL+UNION+SELECT+2885+FROM+DUAL%29+END%29 > %28CASE+WHEN+%284882%3D2501%29+THEN+4882+ELSE+4882%2A%28SELECT+4882+FR > OM+DUAL+UNION+SELECT+2501+FROM+DUAL%29+END%29 > %28CASE+WHEN+%289302%3D9302%29+THEN+SLEEP%2832%29+ELSE+9302+END%29 > %28CASE+WHEN+4772%3D4772+THEN+4772+ELSE+NULL+END%29 > %28CASE+WHEN+7219%3D9319+THEN+7219+ELSE+NULL+END%29 > %28SELECT+%28CASE+WHEN+%283521%3D3521%29+THEN+%27RCA%27+ELSE+%28SELECT > +5220+UNION+SELECT+3216%29+END%29%29 > %28SELECT+%28CASE+WHEN+%289983%3D6874%29+THEN+%27RCA%27+ELSE+%28SELECT > +6874+UNION+SELECT+8819%29+END%29%29 > %28SELECT+CONCAT%280x7162716a71%2C%28ELT%284931%3D4931%2C1%29%29%2C0x7 > 17a767871%29%29 > %28SELECT+CONCAT%280x716a6b7071%2C%28ELT%282020%3D2020%2C1%29%29%2C0x7 > 17a786b71%29%29 > %28SELECT+CONCAT%280x7170717171%2C%28ELT%281739%3D1739%2C1%29%29%2C0x7 > 171627a71%29%29 > %28SELECT+CONCAT%280x7176627171%2C%28ELT%289244%3D9244%2C1%29%29%2C0x7 > 16a717a71%29%29 > %28SELECT+CONCAT%280x71766a7871%2C%28ELT%285835%3D5835%2C1%29%29%2C0x7 > 178787871%29%29 > %28SELECT+CONCAT%280x717a7a6271%2C%28ELT%284238%3D4238%2C1%29%29%2C0x7 > 1626a6b71%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qbqjq%27%2C%28CASE+WHEN+%283392%3D3392% > 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qzvxq%27%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qjkpq%27%2C%28CASE+WHEN+%284051%3D4051% > 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qzxkq%27%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qpqqq%27%2C%28CASE+WHEN+%282945%3D2945% > 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qqbzq%27%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qvbqq%27%2C%28CASE+WHEN+%281904%3D1904% > 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qjqzq%27%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qvjxq%27%2C%28CASE+WHEN+%281582%3D1582% > 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qxxxq%27%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qzzbq%27%2C%28CASE+WHEN+%282980%3D2980% > 29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qbjkq%27%29%29 > > When I unzip the dump, I do not see those filenames, so that's good! > So, how do I get rid of these "hack" files? Maybe empty the page_data > and page_ver directories, then do a restore? > > Also, it would be great if an attempt to access a non-existent page > would not create a file for it. > > THANKS! > > Harold > > > > > > On Sat, January 15, 2022 2:36 pm, Vargenau, Marc-Etienne (Nokia - > FR/Paris-Saclay) wrote: >> Hi Harold, >> 'ZipArchive' is a standard class of PHP since PHP 5.2.0 >> https://www.php.net/manual/en/class.ziparchive >> Probably your PHP is not compiled with that class. >> You should check with phpinfo(). >> Best regards, >> Marc-Etienne >> -----Original Message----- >> From: Harold Hallikainen <ha...@ha...> >> Sent: Saturday, January 15, 2022 8:23 PM >> To: Harold Hallikainen <ha...@ha...> >> Cc: Discussion on PhpWiki features, bugs, development. >> <php...@li...> >> Subject: [Phpwiki-talk] Issues with Wiki Dump I am having issues with >> the wiki dump. Here are the PHP error messages: > [15-Jan-2022 18:55:17 UTC] PHP Fatal error: Uncaught Error: Class > 'ZipArchive' not found in >> /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 >> Stack trace: >> #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): >> MakeWikiZip(Object(WikiRequest)) >> #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): >> WikiRequest->action_zip() >> #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): >> WikiRequest->handleAction() >> #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 > /home/harold/public_html/org/bh/wiki/index.php(60): >> include('/home/harold/pu...') >> #5 {main} >> thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on > line >> 217 >> [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MinPage in > /home/harold/public_html/fr/index.php on line 9 >> [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MaxPage in > /home/harold/public_html/fr/index.php on line 10 >> [15-Jan-2022 18:56:00 UTC] PHP Notice: Undefined index: HOME in > /home/harold/public_html/org/w6iwi/script/rbn.php on line 108 >> [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MinPage in > /home/harold/public_html/fr/index.php on line 9 >> [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MaxPage in > /home/harold/public_html/fr/index.php on line 10 >> [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MinPage in > /home/harold/public_html/fr/index.php on line 9 >> [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MaxPage in > /home/harold/public_html/fr/index.php on line 10 >> [15-Jan-2022 18:56:35 UTC] PHP Fatal error: Uncaught Error: Class > 'ZipArchive' not found in >> /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 >> Stack trace: >> #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): >> MakeWikiZip(Object(WikiRequest)) >> #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): >> WikiRequest->action_zip() >> #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): >> WikiRequest->handleAction() >> #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 > /home/harold/public_html/org/bh/wiki/index.php(60): >> include('/home/harold/pu...') >> #5 {main} >> thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on > line >> 217 >> Using Dump To Directory, a lot of files (perhaps all) show up in the > specified directory, but this error message appears at the bottom of > the page. >> Fatal PhpWiki Error: couldn't open file "/home/harold/tmp/wikidump/" >> for > writing >> I just updated to phpwiki-code-r10903-trunk and the errors still > appear. >> I am going to try a restore from the dump to directory since it looks > like >> it may be working. >> THANKS! >> Harold >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > > -- > FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an > iPhone. > > > > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
From: Harold H. <ha...@ha...> - 2022-01-17 04:27:30
|
Done! Actually, the method of my previous updates was pretty poor, and I ended up with nested versions. So, it was difficult to tell what version was actually running. I have now just unzipped version 10904, renamed it, and copied over my old config.ini after comparing it with config-dist to see what changes needed to be made. It appears to be working! So, back to the original question. Are files now created in page_data and ver_data when a nonexistant page is requested? Again, my DB method is file. I have a lot of trash in those two directories. I don't see an easy way of getting rid of the trash other than doing a dump of the wiki, deleting everything in those directories, then doing a respore. Is this a reasonable approach? THANKS! Harold On Sun, January 16, 2022 12:43 pm, Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay) wrote: > Hi Harold, > > Can you please update to Subversion 10904 and test? > > Also, can you do an > https://bh.hallikainen.org/wiki/index.php/HomePage?action=upgrade&overwrite=1 > you have quite old versions of system files like PhpWikiAdministration > > Best regards, > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Saturday, January 15, 2022 11:43 PM > To: php...@li... > Subject: Re: [Phpwiki-talk] Issues with Wiki Dump > > Thanks for the QUICK response! > > I ran > > dnf install php-zip > service httpd restart > > and it works! > > > I am using the flat file database. In wiki_data, I find page_data and > ver_data. It LOOKS like ver_data has all versions of the page while > page_data has just the most current. I have tried deleting the files in > page_data and then looking at the wiki. The latest versions of the pages > still show up, and are then added to page_data. > > Since access data is stored in the page file, every time someone tries to > access a page that does not exist, it appears that an appropriate file is > created to hold that access data. As people try to hack the system, I end > up with files like those below in page_data. > > > %27A > %28%29 > %28CASE+WHEN+%283541%3D3541%29+THEN+3541+ELSE+3541%2A%28SELECT+3541+FROM+DUAL+UNION+SELECT+2885+FROM+DUAL%29+END%29 > %28CASE+WHEN+%284882%3D2501%29+THEN+4882+ELSE+4882%2A%28SELECT+4882+FROM+DUAL+UNION+SELECT+2501+FROM+DUAL%29+END%29 > %28CASE+WHEN+%289302%3D9302%29+THEN+SLEEP%2832%29+ELSE+9302+END%29 > %28CASE+WHEN+4772%3D4772+THEN+4772+ELSE+NULL+END%29 > %28CASE+WHEN+7219%3D9319+THEN+7219+ELSE+NULL+END%29 > %28SELECT+%28CASE+WHEN+%283521%3D3521%29+THEN+%27RCA%27+ELSE+%28SELECT+5220+UNION+SELECT+3216%29+END%29%29 > %28SELECT+%28CASE+WHEN+%289983%3D6874%29+THEN+%27RCA%27+ELSE+%28SELECT+6874+UNION+SELECT+8819%29+END%29%29 > %28SELECT+CONCAT%280x7162716a71%2C%28ELT%284931%3D4931%2C1%29%29%2C0x717a767871%29%29 > %28SELECT+CONCAT%280x716a6b7071%2C%28ELT%282020%3D2020%2C1%29%29%2C0x717a786b71%29%29 > %28SELECT+CONCAT%280x7170717171%2C%28ELT%281739%3D1739%2C1%29%29%2C0x7171627a71%29%29 > %28SELECT+CONCAT%280x7176627171%2C%28ELT%289244%3D9244%2C1%29%29%2C0x716a717a71%29%29 > %28SELECT+CONCAT%280x71766a7871%2C%28ELT%285835%3D5835%2C1%29%29%2C0x7178787871%29%29 > %28SELECT+CONCAT%280x717a7a6271%2C%28ELT%284238%3D4238%2C1%29%29%2C0x71626a6b71%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qbqjq%27%2C%28CASE+WHEN+%283392%3D3392%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qzvxq%27%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qjkpq%27%2C%28CASE+WHEN+%284051%3D4051%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qzxkq%27%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qpqqq%27%2C%28CASE+WHEN+%282945%3D2945%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qqbzq%27%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qvbqq%27%2C%28CASE+WHEN+%281904%3D1904%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qjqzq%27%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qvjxq%27%2C%28CASE+WHEN+%281582%3D1582%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qxxxq%27%29%29 > %28SELECT+CONCAT%28CONCAT%28%27qzzbq%27%2C%28CASE+WHEN+%282980%3D2980%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qbjkq%27%29%29 > > When I unzip the dump, I do not see those filenames, so that's good! So, > how do I get rid of these "hack" files? Maybe empty the page_data and > page_ver directories, then do a restore? > > Also, it would be great if an attempt to access a non-existent page would > not create a file for it. > > THANKS! > > Harold > > > > > > On Sat, January 15, 2022 2:36 pm, Vargenau, Marc-Etienne (Nokia - > FR/Paris-Saclay) wrote: >> Hi Harold, >> 'ZipArchive' is a standard class of PHP since PHP 5.2.0 >> https://www.php.net/manual/en/class.ziparchive >> Probably your PHP is not compiled with that class. >> You should check with phpinfo(). >> Best regards, >> Marc-Etienne >> -----Original Message----- >> From: Harold Hallikainen <ha...@ha...> >> Sent: Saturday, January 15, 2022 8:23 PM >> To: Harold Hallikainen <ha...@ha...> >> Cc: Discussion on PhpWiki features, bugs, development. >> <php...@li...> >> Subject: [Phpwiki-talk] Issues with Wiki Dump I am having issues with >> the wiki dump. Here are the PHP error messages: > [15-Jan-2022 18:55:17 UTC] PHP Fatal error: Uncaught Error: Class > 'ZipArchive' not found in >> /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 >> Stack trace: >> #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): >> MakeWikiZip(Object(WikiRequest)) >> #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): >> WikiRequest->action_zip() >> #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): >> WikiRequest->handleAction() >> #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 > /home/harold/public_html/org/bh/wiki/index.php(60): >> include('/home/harold/pu...') >> #5 {main} >> thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on > line >> 217 >> [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MinPage in > /home/harold/public_html/fr/index.php on line 9 >> [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MaxPage in > /home/harold/public_html/fr/index.php on line 10 >> [15-Jan-2022 18:56:00 UTC] PHP Notice: Undefined index: HOME in > /home/harold/public_html/org/w6iwi/script/rbn.php on line 108 >> [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MinPage in > /home/harold/public_html/fr/index.php on line 9 >> [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MaxPage in > /home/harold/public_html/fr/index.php on line 10 >> [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MinPage in > /home/harold/public_html/fr/index.php on line 9 >> [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MaxPage in > /home/harold/public_html/fr/index.php on line 10 >> [15-Jan-2022 18:56:35 UTC] PHP Fatal error: Uncaught Error: Class > 'ZipArchive' not found in >> /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 >> Stack trace: >> #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): >> MakeWikiZip(Object(WikiRequest)) >> #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): >> WikiRequest->action_zip() >> #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): >> WikiRequest->handleAction() >> #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 > /home/harold/public_html/org/bh/wiki/index.php(60): >> include('/home/harold/pu...') >> #5 {main} >> thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on > line >> 217 >> Using Dump To Directory, a lot of files (perhaps all) show up in the > specified directory, but this error message appears at the bottom of the > page. >> Fatal PhpWiki Error: couldn't open file "/home/harold/tmp/wikidump/" >> for > writing >> I just updated to phpwiki-code-r10903-trunk and the errors still > appear. >> I am going to try a restore from the dump to directory since it looks > like >> it may be working. >> THANKS! >> Harold >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > > -- > FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an > iPhone. > > > > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2022-01-17 00:22:45
|
Hi Harold, Can you please update to Subversion 10904 and test? Also, can you do an https://bh.hallikainen.org/wiki/index.php/HomePage?action=upgrade&overwrite=1 you have quite old versions of system files like PhpWikiAdministration Best regards, Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Saturday, January 15, 2022 11:43 PM To: php...@li... Subject: Re: [Phpwiki-talk] Issues with Wiki Dump Thanks for the QUICK response! I ran dnf install php-zip service httpd restart and it works! I am using the flat file database. In wiki_data, I find page_data and ver_data. It LOOKS like ver_data has all versions of the page while page_data has just the most current. I have tried deleting the files in page_data and then looking at the wiki. The latest versions of the pages still show up, and are then added to page_data. Since access data is stored in the page file, every time someone tries to access a page that does not exist, it appears that an appropriate file is created to hold that access data. As people try to hack the system, I end up with files like those below in page_data. %27A %28%29 %28CASE+WHEN+%283541%3D3541%29+THEN+3541+ELSE+3541%2A%28SELECT+3541+FROM+DUAL+UNION+SELECT+2885+FROM+DUAL%29+END%29 %28CASE+WHEN+%284882%3D2501%29+THEN+4882+ELSE+4882%2A%28SELECT+4882+FROM+DUAL+UNION+SELECT+2501+FROM+DUAL%29+END%29 %28CASE+WHEN+%289302%3D9302%29+THEN+SLEEP%2832%29+ELSE+9302+END%29 %28CASE+WHEN+4772%3D4772+THEN+4772+ELSE+NULL+END%29 %28CASE+WHEN+7219%3D9319+THEN+7219+ELSE+NULL+END%29 %28SELECT+%28CASE+WHEN+%283521%3D3521%29+THEN+%27RCA%27+ELSE+%28SELECT+5220+UNION+SELECT+3216%29+END%29%29 %28SELECT+%28CASE+WHEN+%289983%3D6874%29+THEN+%27RCA%27+ELSE+%28SELECT+6874+UNION+SELECT+8819%29+END%29%29 %28SELECT+CONCAT%280x7162716a71%2C%28ELT%284931%3D4931%2C1%29%29%2C0x717a767871%29%29 %28SELECT+CONCAT%280x716a6b7071%2C%28ELT%282020%3D2020%2C1%29%29%2C0x717a786b71%29%29 %28SELECT+CONCAT%280x7170717171%2C%28ELT%281739%3D1739%2C1%29%29%2C0x7171627a71%29%29 %28SELECT+CONCAT%280x7176627171%2C%28ELT%289244%3D9244%2C1%29%29%2C0x716a717a71%29%29 %28SELECT+CONCAT%280x71766a7871%2C%28ELT%285835%3D5835%2C1%29%29%2C0x7178787871%29%29 %28SELECT+CONCAT%280x717a7a6271%2C%28ELT%284238%3D4238%2C1%29%29%2C0x71626a6b71%29%29 %28SELECT+CONCAT%28CONCAT%28%27qbqjq%27%2C%28CASE+WHEN+%283392%3D3392%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qzvxq%27%29%29 %28SELECT+CONCAT%28CONCAT%28%27qjkpq%27%2C%28CASE+WHEN+%284051%3D4051%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qzxkq%27%29%29 %28SELECT+CONCAT%28CONCAT%28%27qpqqq%27%2C%28CASE+WHEN+%282945%3D2945%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qqbzq%27%29%29 %28SELECT+CONCAT%28CONCAT%28%27qvbqq%27%2C%28CASE+WHEN+%281904%3D1904%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qjqzq%27%29%29 %28SELECT+CONCAT%28CONCAT%28%27qvjxq%27%2C%28CASE+WHEN+%281582%3D1582%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qxxxq%27%29%29 %28SELECT+CONCAT%28CONCAT%28%27qzzbq%27%2C%28CASE+WHEN+%282980%3D2980%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qbjkq%27%29%29 When I unzip the dump, I do not see those filenames, so that's good! So, how do I get rid of these "hack" files? Maybe empty the page_data and page_ver directories, then do a restore? Also, it would be great if an attempt to access a non-existent page would not create a file for it. THANKS! Harold On Sat, January 15, 2022 2:36 pm, Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay) wrote: > Hi Harold, > 'ZipArchive' is a standard class of PHP since PHP 5.2.0 > https://www.php.net/manual/en/class.ziparchive > Probably your PHP is not compiled with that class. > You should check with phpinfo(). > Best regards, > Marc-Etienne > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Saturday, January 15, 2022 8:23 PM > To: Harold Hallikainen <ha...@ha...> > Cc: Discussion on PhpWiki features, bugs, development. > <php...@li...> > Subject: [Phpwiki-talk] Issues with Wiki Dump I am having issues with > the wiki dump. Here are the PHP error messages: [15-Jan-2022 18:55:17 UTC] PHP Fatal error: Uncaught Error: Class 'ZipArchive' not found in > /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 > Stack trace: > #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): > MakeWikiZip(Object(WikiRequest)) > #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): > WikiRequest->action_zip() > #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): > WikiRequest->handleAction() > #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 /home/harold/public_html/org/bh/wiki/index.php(60): > include('/home/harold/pu...') > #5 {main} > thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on line > 217 > [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 > [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 > [15-Jan-2022 18:56:00 UTC] PHP Notice: Undefined index: HOME in /home/harold/public_html/org/w6iwi/script/rbn.php on line 108 > [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 > [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 > [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 > [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 > [15-Jan-2022 18:56:35 UTC] PHP Fatal error: Uncaught Error: Class 'ZipArchive' not found in > /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 > Stack trace: > #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): > MakeWikiZip(Object(WikiRequest)) > #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): > WikiRequest->action_zip() > #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): > WikiRequest->handleAction() > #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 /home/harold/public_html/org/bh/wiki/index.php(60): > include('/home/harold/pu...') > #5 {main} > thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on line > 217 > Using Dump To Directory, a lot of files (perhaps all) show up in the specified directory, but this error message appears at the bottom of the page. > Fatal PhpWiki Error: couldn't open file "/home/harold/tmp/wikidump/" > for writing > I just updated to phpwiki-code-r10903-trunk and the errors still appear. > I am going to try a restore from the dump to directory since it looks like > it may be working. > THANKS! > Harold > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
From: Harold H. <ha...@ha...> - 2022-01-15 22:52:06
|
Thanks for the QUICK response! I ran dnf install php-zip service httpd restart and it works! I am using the flat file database. In wiki_data, I find page_data and ver_data. It LOOKS like ver_data has all versions of the page while page_data has just the most current. I have tried deleting the files in page_data and then looking at the wiki. The latest versions of the pages still show up, and are then added to page_data. Since access data is stored in the page file, every time someone tries to access a page that does not exist, it appears that an appropriate file is created to hold that access data. As people try to hack the system, I end up with files like those below in page_data. %27A %28%29 %28CASE+WHEN+%283541%3D3541%29+THEN+3541+ELSE+3541%2A%28SELECT+3541+FROM+DUAL+UNION+SELECT+2885+FROM+DUAL%29+END%29 %28CASE+WHEN+%284882%3D2501%29+THEN+4882+ELSE+4882%2A%28SELECT+4882+FROM+DUAL+UNION+SELECT+2501+FROM+DUAL%29+END%29 %28CASE+WHEN+%289302%3D9302%29+THEN+SLEEP%2832%29+ELSE+9302+END%29 %28CASE+WHEN+4772%3D4772+THEN+4772+ELSE+NULL+END%29 %28CASE+WHEN+7219%3D9319+THEN+7219+ELSE+NULL+END%29 %28SELECT+%28CASE+WHEN+%283521%3D3521%29+THEN+%27RCA%27+ELSE+%28SELECT+5220+UNION+SELECT+3216%29+END%29%29 %28SELECT+%28CASE+WHEN+%289983%3D6874%29+THEN+%27RCA%27+ELSE+%28SELECT+6874+UNION+SELECT+8819%29+END%29%29 %28SELECT+CONCAT%280x7162716a71%2C%28ELT%284931%3D4931%2C1%29%29%2C0x717a767871%29%29 %28SELECT+CONCAT%280x716a6b7071%2C%28ELT%282020%3D2020%2C1%29%29%2C0x717a786b71%29%29 %28SELECT+CONCAT%280x7170717171%2C%28ELT%281739%3D1739%2C1%29%29%2C0x7171627a71%29%29 %28SELECT+CONCAT%280x7176627171%2C%28ELT%289244%3D9244%2C1%29%29%2C0x716a717a71%29%29 %28SELECT+CONCAT%280x71766a7871%2C%28ELT%285835%3D5835%2C1%29%29%2C0x7178787871%29%29 %28SELECT+CONCAT%280x717a7a6271%2C%28ELT%284238%3D4238%2C1%29%29%2C0x71626a6b71%29%29 %28SELECT+CONCAT%28CONCAT%28%27qbqjq%27%2C%28CASE+WHEN+%283392%3D3392%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qzvxq%27%29%29 %28SELECT+CONCAT%28CONCAT%28%27qjkpq%27%2C%28CASE+WHEN+%284051%3D4051%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qzxkq%27%29%29 %28SELECT+CONCAT%28CONCAT%28%27qpqqq%27%2C%28CASE+WHEN+%282945%3D2945%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qqbzq%27%29%29 %28SELECT+CONCAT%28CONCAT%28%27qvbqq%27%2C%28CASE+WHEN+%281904%3D1904%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qjqzq%27%29%29 %28SELECT+CONCAT%28CONCAT%28%27qvjxq%27%2C%28CASE+WHEN+%281582%3D1582%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qxxxq%27%29%29 %28SELECT+CONCAT%28CONCAT%28%27qzzbq%27%2C%28CASE+WHEN+%282980%3D2980%29+THEN+%271%27+ELSE+%270%27+END%29%29%2C%27qbjkq%27%29%29 When I unzip the dump, I do not see those filenames, so that's good! So, how do I get rid of these "hack" files? Maybe empty the page_data and page_ver directories, then do a restore? Also, it would be great if an attempt to access a non-existent page would not create a file for it. THANKS! Harold On Sat, January 15, 2022 2:36 pm, Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay) wrote: > Hi Harold, > 'ZipArchive' is a standard class of PHP since PHP 5.2.0 > https://www.php.net/manual/en/class.ziparchive > Probably your PHP is not compiled with that class. > You should check with phpinfo(). > Best regards, > Marc-Etienne > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Saturday, January 15, 2022 8:23 PM > To: Harold Hallikainen <ha...@ha...> > Cc: Discussion on PhpWiki features, bugs, development. > <php...@li...> > Subject: [Phpwiki-talk] Issues with Wiki Dump > I am having issues with the wiki dump. Here are the PHP error messages: [15-Jan-2022 18:55:17 UTC] PHP Fatal error: Uncaught Error: Class 'ZipArchive' not found in > /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 > Stack trace: > #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): > MakeWikiZip(Object(WikiRequest)) > #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): > WikiRequest->action_zip() > #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): > WikiRequest->handleAction() > #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 /home/harold/public_html/org/bh/wiki/index.php(60): > include('/home/harold/pu...') > #5 {main} > thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on line > 217 > [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 > [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 > [15-Jan-2022 18:56:00 UTC] PHP Notice: Undefined index: HOME in /home/harold/public_html/org/w6iwi/script/rbn.php on line 108 > [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 > [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 > [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 > [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 > [15-Jan-2022 18:56:35 UTC] PHP Fatal error: Uncaught Error: Class 'ZipArchive' not found in > /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 > Stack trace: > #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): > MakeWikiZip(Object(WikiRequest)) > #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): > WikiRequest->action_zip() > #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): > WikiRequest->handleAction() > #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 /home/harold/public_html/org/bh/wiki/index.php(60): > include('/home/harold/pu...') > #5 {main} > thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on line > 217 > Using Dump To Directory, a lot of files (perhaps all) show up in the specified directory, but this error message appears at the bottom of the page. > Fatal PhpWiki Error: couldn't open file "/home/harold/tmp/wikidump/" for writing > I just updated to phpwiki-code-r10903-trunk and the errors still appear. > I am going to try a restore from the dump to directory since it looks like > it may be working. > THANKS! > Harold > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2022-01-15 21:37:06
|
Hi Harold, 'ZipArchive' is a standard class of PHP since PHP 5.2.0 https://www.php.net/manual/en/class.ziparchive Probably your PHP is not compiled with that class. You should check with phpinfo(). Best regards, Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Saturday, January 15, 2022 8:23 PM To: Harold Hallikainen <ha...@ha...> Cc: Discussion on PhpWiki features, bugs, development. <php...@li...> Subject: [Phpwiki-talk] Issues with Wiki Dump I am having issues with the wiki dump. Here are the PHP error messages: [15-Jan-2022 18:55:17 UTC] PHP Fatal error: Uncaught Error: Class 'ZipArchive' not found in /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 Stack trace: #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): MakeWikiZip(Object(WikiRequest)) #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): WikiRequest->action_zip() #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): WikiRequest->handleAction() #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 /home/harold/public_html/org/bh/wiki/index.php(60): include('/home/harold/pu...') #5 {main} thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on line 217 [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 [15-Jan-2022 18:56:00 UTC] PHP Notice: Undefined index: HOME in /home/harold/public_html/org/w6iwi/script/rbn.php on line 108 [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 [15-Jan-2022 18:56:35 UTC] PHP Fatal error: Uncaught Error: Class 'ZipArchive' not found in /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 Stack trace: #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): MakeWikiZip(Object(WikiRequest)) #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): WikiRequest->action_zip() #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): WikiRequest->handleAction() #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 /home/harold/public_html/org/bh/wiki/index.php(60): include('/home/harold/pu...') #5 {main} thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on line 217 Using Dump To Directory, a lot of files (perhaps all) show up in the specified directory, but this error message appears at the bottom of the page. Fatal PhpWiki Error: couldn't open file "/home/harold/tmp/wikidump/" for writing I just updated to phpwiki-code-r10903-trunk and the errors still appear. I am going to try a restore from the dump to directory since it looks like it may be working. THANKS! Harold _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
From: Harold H. <ha...@ha...> - 2022-01-15 20:43:12
|
I am having issues with the wiki dump. Here are the PHP error messages: [15-Jan-2022 18:55:17 UTC] PHP Fatal error: Uncaught Error: Class 'ZipArchive' not found in /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 Stack trace: #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): MakeWikiZip(Object(WikiRequest)) #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): WikiRequest->action_zip() #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): WikiRequest->handleAction() #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 /home/harold/public_html/org/bh/wiki/index.php(60): include('/home/harold/pu...') #5 {main} thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on line 217 [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 [15-Jan-2022 18:55:59 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 [15-Jan-2022 18:56:00 UTC] PHP Notice: Undefined index: HOME in /home/harold/public_html/org/w6iwi/script/rbn.php on line 108 [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 [15-Jan-2022 18:56:05 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MinPage in /home/harold/public_html/fr/index.php on line 9 [15-Jan-2022 18:56:26 UTC] PHP Notice: Undefined index: MaxPage in /home/harold/public_html/fr/index.php on line 10 [15-Jan-2022 18:56:35 UTC] PHP Fatal error: Uncaught Error: Class 'ZipArchive' not found in /home/harold/public_html/org/bh/wiki/lib/loadsave.php:217 Stack trace: #0 /home/harold/public_html/org/bh/wiki/lib/main.php(1273): MakeWikiZip(Object(WikiRequest)) #1 /home/harold/public_html/org/bh/wiki/lib/main.php(819): WikiRequest->action_zip() #2 /home/harold/public_html/org/bh/wiki/lib/main.php(1456): WikiRequest->handleAction() #3 /home/harold/public_html/org/bh/wiki/lib/main.php(1480): main() #4 /home/harold/public_html/org/bh/wiki/index.php(60): include('/home/harold/pu...') #5 {main} thrown in /home/harold/public_html/org/bh/wiki/lib/loadsave.php on line 217 Using Dump To Directory, a lot of files (perhaps all) show up in the specified directory, but this error message appears at the bottom of the page. Fatal PhpWiki Error: couldn't open file /home/harold/tmp/wikidump/ for writing I just updated to phpwiki-code-r10903-trunk and the errors still appear. I am going to try a restore from the dump to directory since it looks like it may be working. THANKS! Harold |
From: Harold H. <ha...@ha...> - 2021-09-02 19:22:13
|
The warning shows up when I log in as a non-admin user (where I modified the password file to use the password generated by the password encrypt utinilty instead of by htpasswd). The warning is attached. Note that if I use htpasswd, the wiki will not accept that user. THANKS for all the work on this! Harold > Hi Harold, > > Good news! > > I do not see warnings on https://bh.hallikainen.org/ > > However, what is a bit strange is that you have blank entries on page > AllPages: > https://bh.hallikainen.org/wiki/index.php/AllPages > > Best regards, > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Friday, August 20, 2021 7:47 PM > To: php...@li... > Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation for > non-existent pages > > THANKS! It's working well! https://bh.hallikainen.org/ is running under > AlmaLinux. There are a few warnings at the end of the page. I have not yet > figured out where the error log is. These warnings do not show up in the > httpd error log, the php error log, or the php-fpm error log. > > Harold > > > >> Hi Harold, >> >> Yes, I made some improvements for DATABASE_TYPE = file. >> >> Please keep me informed if you have issues. >> >> Marc-Etienne >> >> -----Original Message----- >> From: Harold Hallikainen <ha...@ha...> >> Sent: Tuesday, August 17, 2021 6:39 PM >> To: php...@li... >> Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation >> for non-existent pages >> >> THANKS! Looking at the activity, you've been busy. I really appreciate >> all your work on this. I've started migrating to a new server running >> Alma Linux 8. My current server is running Centos 6. LOTS of PHP >> complaints on PhpWiki. I look forward to trying this new version. >> >> Again, thanks! >> >> Harold >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk >> >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk >> >> > > > -- > FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an > iPhone. > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2021-09-02 14:57:29
|
Hi Harold, Good news! I do not see warnings on https://bh.hallikainen.org/ However, what is a bit strange is that you have blank entries on page AllPages: https://bh.hallikainen.org/wiki/index.php/AllPages Best regards, Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Friday, August 20, 2021 7:47 PM To: php...@li... Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation for non-existent pages THANKS! It's working well! https://bh.hallikainen.org/ is running under AlmaLinux. There are a few warnings at the end of the page. I have not yet figured out where the error log is. These warnings do not show up in the httpd error log, the php error log, or the php-fpm error log. Harold > Hi Harold, > > Yes, I made some improvements for DATABASE_TYPE = file. > > Please keep me informed if you have issues. > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Tuesday, August 17, 2021 6:39 PM > To: php...@li... > Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation > for non-existent pages > > THANKS! Looking at the activity, you've been busy. I really appreciate > all your work on this. I've started migrating to a new server running > Alma Linux 8. My current server is running Centos 6. LOTS of PHP > complaints on PhpWiki. I look forward to trying this new version. > > Again, thanks! > > Harold > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2021-09-02 14:28:27
|
Hi Harold, No idea for the moment, I need to check. Best regards, Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Tuesday, August 24, 2021 10:07 PM To: php...@li... Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation for non-existent pages Back on user authorization, I am using file and using htpasswd to create the password file. I am now getting: Warning: "crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format." and the supplied password does not let the user in. Following up on this, I tried editing the user password file replacing the password created by htpasswd with one created by the Password Encryption Utility (wiki/passencrypt.php). That then does allow the user to log in, though there is still the error message at the bottom of the page: Warning: "crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format." Ideas? THANKS! Harold > Hi Harold, > > Yes, I made some improvements for DATABASE_TYPE = file. > > Please keep me informed if you have issues. > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Tuesday, August 17, 2021 6:39 PM > To: php...@li... > Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation for non-existent pages > > THANKS! Looking at the activity, you've been busy. I really appreciate all your work on this. I've started migrating to a new server running Alma Linux 8. My current server is running Centos 6. LOTS of PHP complaints on PhpWiki. I look forward to trying this new version. > > Again, thanks! > > Harold > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
From: Harold H. <ha...@ha...> - 2021-08-24 20:07:33
|
Back on user authorization, I am using file and using htpasswd to create the password file. I am now getting: Warning: "crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format." and the supplied password does not let the user in. Following up on this, I tried editing the user password file replacing the password created by htpasswd with one created by the Password Encryption Utility (wiki/passencrypt.php). That then does allow the user to log in, though there is still the error message at the bottom of the page: Warning: "crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format." Ideas? THANKS! Harold > Hi Harold, > > Yes, I made some improvements for DATABASE_TYPE = file. > > Please keep me informed if you have issues. > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Tuesday, August 17, 2021 6:39 PM > To: php...@li... > Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation for non-existent pages > > THANKS! Looking at the activity, you've been busy. I really appreciate all your work on this. I've started migrating to a new server running Alma Linux 8. My current server is running Centos 6. LOTS of PHP complaints on PhpWiki. I look forward to trying this new version. > > Again, thanks! > > Harold > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Harold H. <ha...@ha...> - 2021-08-23 23:07:39
|
Back on user authorization, I am using file and using htpasswd to create the password file. I am now getting: Warning: "crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format." and the supplied password does not let the user in. Ideas? THANKS! Harold > Hi Harold, > > Yes, I made some improvements for DATABASE_TYPE = file. > > Please keep me informed if you have issues. > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Tuesday, August 17, 2021 6:39 PM > To: php...@li... > Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation for non-existent pages > > THANKS! Looking at the activity, you've been busy. I really appreciate all your work on this. I've started migrating to a new server running Alma Linux 8. My current server is running Centos 6. LOTS of PHP complaints on PhpWiki. I look forward to trying this new version. > > Again, thanks! > > Harold > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Harold H. <ha...@ha...> - 2021-08-20 17:47:10
|
THANKS! It's working well! https://bh.hallikainen.org/ is running under AlmaLinux. There are a few warnings at the end of the page. I have not yet figured out where the error log is. These warnings do not show up in the httpd error log, the php error log, or the php-fpm error log. Harold > Hi Harold, > > Yes, I made some improvements for DATABASE_TYPE = file. > > Please keep me informed if you have issues. > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Tuesday, August 17, 2021 6:39 PM > To: php...@li... > Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation for > non-existent pages > > THANKS! Looking at the activity, you've been busy. I really appreciate all > your work on this. I've started migrating to a new server running Alma > Linux 8. My current server is running Centos 6. LOTS of PHP complaints on > PhpWiki. I look forward to trying this new version. > > Again, thanks! > > Harold > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2021-08-17 17:29:49
|
Hi Harold, Yes, I made some improvements for DATABASE_TYPE = file. Please keep me informed if you have issues. Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Tuesday, August 17, 2021 6:39 PM To: php...@li... Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation for non-existent pages THANKS! Looking at the activity, you've been busy. I really appreciate all your work on this. I've started migrating to a new server running Alma Linux 8. My current server is running Centos 6. LOTS of PHP complaints on PhpWiki. I look forward to trying this new version. Again, thanks! Harold _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
From: Harold H. <ha...@ha...> - 2021-08-17 16:39:12
|
THANKS! Looking at the activity, you've been busy. I really appreciate all your work on this. I've started migrating to a new server running Alma Linux 8. My current server is running Centos 6. LOTS of PHP complaints on PhpWiki. I look forward to trying this new version. Again, thanks! Harold > Hi Harold, > > Thank you for your continued interest in PhpWiki. > > I have finally the time to publish PhpWiki 1.6.0: > https://sourceforge.net/p/phpwiki/news/2021/08/phpwiki-160-released/ > > You might want to upgrade your wiki to this version. > > I have added some notes about user authentication in file > config/config-dist.ini, based on your notes below. > > Best regards, > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Monday, July 19, 2021 5:15 AM > To: Harold Hallikainen <ha...@ha...> > Cc: Discussion on PhpWiki features, bugs, development. > <php...@li...> > Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation for > non-existent pages > > > Following up on this, I have a couple solutions. > > To get rid of the files for pages that do not exist, I create a zip dump > of the wiki, move the wiki page files somewhere else as a backup, do a > restore from the dump. If all looks good, the moved page files are > deleted. > > I have not dug extensively into the code, but I understand that page > access data is saved in the wiki page file. If someone tries to access a > page that does not exist (typically trying to send a command to get > /etc/passwd), a file is created with that page name to record the access > even though the page does not exist. I might dig into the code a bit to > see if I can make an access not create a file. > > Second, on using file authentication, after grepping around a bit, I found > in config.ini > > ; File authentication options: > ; > ; File to read for authentication information. > ; Popular choices are /etc/shadow and /etc/httpd/.htpasswd ; > AUTH_USER_FILE = /etc/shadow AUTH_USER_FILE = > /home/harold/BhWikiData/users ; above line changed 7/18/21. hh See > /home/harold/BhWikiData/AddingUsers > for info. > > You can see how I changed the AUTH_USER_FILE. I made notes in > /home/harold/BhWikiData/AddingUsers to remind me how to add users: > > [harold@mai BhWikiData]$ cat AddingUsers User info is kept in > /home/harold/BhWikiData/users. > > To add a user, run the command > > htpasswd UserName > > where UserName is the user to be added. You will be prompted twice for the > password. > > hh > 7/18/21 > > > I added a test user, and IT WORKED! Hopefully this will help someone else > using file authentication. > > Thanks! > > Harold > > > > > -- > FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an > iPhone. > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2021-08-17 11:27:50
|
Hi Harold, Thank you for your continued interest in PhpWiki. I have finally the time to publish PhpWiki 1.6.0: https://sourceforge.net/p/phpwiki/news/2021/08/phpwiki-160-released/ You might want to upgrade your wiki to this version. I have added some notes about user authentication in file config/config-dist.ini, based on your notes below. Best regards, Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Monday, July 19, 2021 5:15 AM To: Harold Hallikainen <ha...@ha...> Cc: Discussion on PhpWiki features, bugs, development. <php...@li...> Subject: Re: [Phpwiki-talk] User Authorization and Page File Creation for non-existent pages Following up on this, I have a couple solutions. To get rid of the files for pages that do not exist, I create a zip dump of the wiki, move the wiki page files somewhere else as a backup, do a restore from the dump. If all looks good, the moved page files are deleted. I have not dug extensively into the code, but I understand that page access data is saved in the wiki page file. If someone tries to access a page that does not exist (typically trying to send a command to get /etc/passwd), a file is created with that page name to record the access even though the page does not exist. I might dig into the code a bit to see if I can make an access not create a file. Second, on using file authentication, after grepping around a bit, I found in config.ini ; File authentication options: ; ; File to read for authentication information. ; Popular choices are /etc/shadow and /etc/httpd/.htpasswd ; AUTH_USER_FILE = /etc/shadow AUTH_USER_FILE = /home/harold/BhWikiData/users ; above line changed 7/18/21. hh See /home/harold/BhWikiData/AddingUsers for info. You can see how I changed the AUTH_USER_FILE. I made notes in /home/harold/BhWikiData/AddingUsers to remind me how to add users: [harold@mai BhWikiData]$ cat AddingUsers User info is kept in /home/harold/BhWikiData/users. To add a user, run the command htpasswd UserName where UserName is the user to be added. You will be prompted twice for the password. hh 7/18/21 I added a test user, and IT WORKED! Hopefully this will help someone else using file authentication. Thanks! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
From: Harold H. <ha...@ha...> - 2021-07-19 03:47:36
|
> >> >>> Hi Harold, >>> >>> Unfortunately, I have never tested Phpwiki with DATABASE_TYPE: file >>> I have only tested with an SQL database. >>> I will need some time to test your issue. >>> >>> Best regards, >>> >>> Marc-Etienne >> >> THANKS! I wish I was better at reading the code in this complex >> application. So, there are two issues: >> >> 1. How to authorize users when authorization file method. >> >> 2. Using flat file for page data, how to avoid the creation of new files >> when someone tries to access a page that does not exist. >> >> THANKS! >> >> Harold >> http://bh.hallikainen.org/wiki/ >> > > I get a daily report of new files on the server. Here's a typical file > created by someone trying to access a nonexistent wiki page: > > page_data/Historic+Papers%27%2F%2A%2A%2Fand%28select%271%27from%2F%2A%2A%2Fpg_sleep%283%29%29%270 > > Someone is clearly trying to hack the database. It would be nice if > attempts to access nonexistent pages did not generate a page file. > > THANKS! > > Harold > Following up on this, I have a couple solutions. To get rid of the files for pages that do not exist, I create a zip dump of the wiki, move the wiki page files somewhere else as a backup, do a restore from the dump. If all looks good, the moved page files are deleted. I have not dug extensively into the code, but I understand that page access data is saved in the wiki page file. If someone tries to access a page that does not exist (typically trying to send a command to get /etc/passwd), a file is created with that page name to record the access even though the page does not exist. I might dig into the code a bit to see if I can make an access not create a file. Second, on using file authentication, after grepping around a bit, I found in config.ini ; File authentication options: ; ; File to read for authentication information. ; Popular choices are /etc/shadow and /etc/httpd/.htpasswd ; AUTH_USER_FILE = /etc/shadow AUTH_USER_FILE = /home/harold/BhWikiData/users ; above line changed 7/18/21. hh See /home/harold/BhWikiData/AddingUsers for info. You can see how I changed the AUTH_USER_FILE. I made notes in /home/harold/BhWikiData/AddingUsers to remind me how to add users: [harold@mai BhWikiData]$ cat AddingUsers User info is kept in /home/harold/BhWikiData/users. To add a user, run the command htpasswd UserName where UserName is the user to be added. You will be prompted twice for the password. hh 7/18/21 I added a test user, and IT WORKED! Hopefully this will help someone else using file authentication. Thanks! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Harold H. <ha...@ha...> - 2021-02-19 17:21:38
|
> >> Hi Harold, >> >> Unfortunately, I have never tested Phpwiki with DATABASE_TYPE: file >> I have only tested with an SQL database. >> I will need some time to test your issue. >> >> Best regards, >> >> Marc-Etienne > > THANKS! I wish I was better at reading the code in this complex > application. So, there are two issues: > > 1. How to authorize users when authorization file method. > > 2. Using flat file for page data, how to avoid the creation of new files > when someone tries to access a page that does not exist. > > THANKS! > > Harold > http://bh.hallikainen.org/wiki/ > I get a daily report of new files on the server. Here's a typical file created by someone trying to access a nonexistent wiki page: page_data/Historic+Papers%27%2F%2A%2A%2Fand%28select%271%27from%2F%2A%2A%2Fpg_sleep%283%29%29%270 Someone is clearly trying to hack the database. It would be nice if attempts to access nonexistent pages did not generate a page file. THANKS! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Harold H. <ha...@ha...> - 2021-02-09 00:55:15
|
> Hi Harold, > > Unfortunately, I have never tested Phpwiki with DATABASE_TYPE: file > I have only tested with an SQL database. > I will need some time to test your issue. > > Best regards, > > Marc-Etienne THANKS! I wish I was better at reading the code in this complex application. So, there are two issues: 1. How to authorize users when authorization file method. 2. Using flat file for page data, how to avoid the creation of new files when someone tries to access a page that does not exist. THANKS! Harold http://bh.hallikainen.org/wiki/ > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Thursday, February 4, 2021 5:53 PM > To: php...@li... > Subject: [Phpwiki-talk] User Authorization and Page File Creation for > non-existent pages > > > Good Morning! > > A follow-up and a new question: > > 1. I'm still having trouble determining how to grant write access to > authorized users. > > I'm using the File method for user authorization. > > USER_AUTH_ORDER = "File" > > The description from config.ini is: > File: Store username:crypted-passwords in .htaccess like files. > Use Apache's htpasswd to manage this file. > > This implies to me that is an ".htaccess like file" and not .htaccess > itself. What is the name of this file, and where is it located? I could > then use htpasswd on it to allow users to edit the wiki. > > 2. People appear to be attempting to break into the system by attempting > to access pages that do not exist. Each one of these attempted access > creates a new file. For example, here is one of several new files this > morning: > > /home/harold/BhWikiData/page_data/http%3A%2F%2Fejdarc.venissieux.free.fr%2Fa_virer_joomla%2Fimages%2Ffbfiles%2Fimages%2Fcache.txt%3F > > I have tried making the files read only until I am updating the wiki, but > this gives those reading the wiki errors since the access of the page > cannot be recorded in the page file. > > To deal with this so far, I have done a dump of all pages, move all the > existing files to a backup directory, then do a restore. If it looks good, > I then delete the backup directory. > > Is there a way to prevent this file creation when someone tries to access > a page that does not exist? > > THANKS! > > Harold > http://bh.hallikainen.org/ > > > > > > >> Hello Harold, >> The .htaccess file is a file used by Apache to protect a directory and > its >> subdirectories. >> For PhpWIki, you find find an .htaccess file in the root directory and > in >> some of the subdirectories. >> You should adapt their content to your needs. >> Best regards, >> Marc-Etienne >> -----Original Message----- >> From: Harold Hallikainen [mailto:ha...@ha...] >> Sent: Tuesday, May 15, 2018 11:41 PM >> To: Discussion on PhpWiki features, bugs, development. >> <php...@li...> >> Subject: [Phpwiki-talk] User Authorization - resend from different >> email > I'm using the File method for user authorization. >> USER_AUTH_ORDER = "File" >> The description from config.ini is: >> File: Store username:crypted-passwords in .htaccess like > files. >> ; Use Apache's htpasswd to manage this file. >> What is the name of this file, and where is it located? >> THANKS! >> Harold >> -- >> FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an > iPhone. >> ---------------------------------------------------------------------- >> -------- > Check out the vibrant tech community on one of the world's most engaging > tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > > -- > FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an > iPhone. > > > > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2021-02-08 18:21:15
|
Hi Harold, Unfortunately, I have never tested Phpwiki with DATABASE_TYPE: file I have only tested with an SQL database. I will need some time to test your issue. Best regards, Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Thursday, February 4, 2021 5:53 PM To: php...@li... Subject: [Phpwiki-talk] User Authorization and Page File Creation for non-existent pages Good Morning! A follow-up and a new question: 1. I'm still having trouble determining how to grant write access to authorized users. I'm using the File method for user authorization. USER_AUTH_ORDER = "File" The description from config.ini is: File: Store username:crypted-passwords in .htaccess like files. Use Apache's htpasswd to manage this file. This implies to me that is an ".htaccess like file" and not .htaccess itself. What is the name of this file, and where is it located? I could then use htpasswd on it to allow users to edit the wiki. 2. People appear to be attempting to break into the system by attempting to access pages that do not exist. Each one of these attempted access creates a new file. For example, here is one of several new files this morning: /home/harold/BhWikiData/page_data/http%3A%2F%2Fejdarc.venissieux.free.fr%2Fa_virer_joomla%2Fimages%2Ffbfiles%2Fimages%2Fcache.txt%3F I have tried making the files read only until I am updating the wiki, but this gives those reading the wiki errors since the access of the page cannot be recorded in the page file. To deal with this so far, I have done a dump of all pages, move all the existing files to a backup directory, then do a restore. If it looks good, I then delete the backup directory. Is there a way to prevent this file creation when someone tries to access a page that does not exist? THANKS! Harold http://bh.hallikainen.org/ > Hello Harold, > The .htaccess file is a file used by Apache to protect a directory and its > subdirectories. > For PhpWIki, you find find an .htaccess file in the root directory and in > some of the subdirectories. > You should adapt their content to your needs. > Best regards, > Marc-Etienne > -----Original Message----- > From: Harold Hallikainen [mailto:ha...@ha...] > Sent: Tuesday, May 15, 2018 11:41 PM > To: Discussion on PhpWiki features, bugs, development. > <php...@li...> > Subject: [Phpwiki-talk] User Authorization - resend from different > email I'm using the File method for user authorization. > USER_AUTH_ORDER = "File" > The description from config.ini is: > File: Store username:crypted-passwords in .htaccess like files. > ; Use Apache's htpasswd to manage this file. > What is the name of this file, and where is it located? > THANKS! > Harold > -- > FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. > ---------------------------------------------------------------------- > -------- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
From: Harold H. <ha...@ha...> - 2021-02-04 17:18:45
|
Good Morning! A follow-up and a new question: 1. I'm still having trouble determining how to grant write access to authorized users. I'm using the File method for user authorization. USER_AUTH_ORDER = "File" The description from config.ini is: File: Store username:crypted-passwords in .htaccess like files. Use Apache's htpasswd to manage this file. This implies to me that is an ".htaccess like file" and not .htaccess itself. What is the name of this file, and where is it located? I could then use htpasswd on it to allow users to edit the wiki. 2. People appear to be attempting to break into the system by attempting to access pages that do not exist. Each one of these attempted access creates a new file. For example, here is one of several new files this morning: /home/harold/BhWikiData/page_data/http%3A%2F%2Fejdarc.venissieux.free.fr%2Fa_virer_joomla%2Fimages%2Ffbfiles%2Fimages%2Fcache.txt%3F I have tried making the files read only until I am updating the wiki, but this gives those reading the wiki errors since the access of the page cannot be recorded in the page file. To deal with this so far, I have done a dump of all pages, move all the existing files to a backup directory, then do a restore. If it looks good, I then delete the backup directory. Is there a way to prevent this file creation when someone tries to access a page that does not exist? THANKS! Harold http://bh.hallikainen.org/ > Hello Harold, > The .htaccess file is a file used by Apache to protect a directory and its > subdirectories. > For PhpWIki, you find find an .htaccess file in the root directory and in > some of the subdirectories. > You should adapt their content to your needs. > Best regards, > Marc-Etienne > -----Original Message----- > From: Harold Hallikainen [mailto:ha...@ha...] > Sent: Tuesday, May 15, 2018 11:41 PM > To: Discussion on PhpWiki features, bugs, development. > <php...@li...> > Subject: [Phpwiki-talk] User Authorization - resend from different email I'm using the File method for user authorization. > USER_AUTH_ORDER = "File" > The description from config.ini is: > File: Store username:crypted-passwords in .htaccess like files. > ; Use Apache's htpasswd to manage this file. > What is the name of this file, and where is it located? > THANKS! > Harold > -- > FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2020-07-21 16:28:23
|
Hi Harold, Good news! Thank you for supporting Phpwiki. Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Tuesday, July 21, 2020 6:10 PM To: Harold Hallikainen <ha...@ha...> Cc: Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay) <mar...@no...>; Discussion on PhpWiki features, bugs, development. <php...@li...>; Harold Hallikainen <ha...@ha...> Subject: RE: [Phpwiki-talk] Edit page stopped working OK, it fixed itself! I was going to start looking at the PHP error messages and code this morning, but now I can edit pages fine. Nice to avoid some work! THANKS for being there! Harold > Yes, I'm using a flat file. A while back, the wiki got spammed and > there were a bunch of pages created with /etc/passwd or database > commands. I've been removing those files in the page_data directory. > I'd first copy them to a backup directory, make sure the page was > still visible (these were generally a bunch of stuff tacked on to a > page name), then, if the page seemed to still be good, I deleted the > file. Now, however, I discover that I can't edit the pages. > > What is the links directory? I thought pretty much everything was > contained in the page_data for each page (but perhaps links holds > backlinks?). > > I thought the httpd error log would show the php errors, but I'm not > finding them there (I find other PHP errors). > > It is, of course, true that /home/harold/BhWikiData/links/ is a > directory, but why is it trying to be opened? Should it instead be > opening a file within that directory? > > I guess I'll dig into the code some once I can find some indication as > to what line of what PHP file is causing the issue. > > THANKS for the quick response! > > Harold > > > > >> Hi Harold, >> >> The error message seems to imply that you are using file of flatfile >> as storage backend. >> Is it so? >> >> In that case, I am not sure I can help, I am always testing Phpwiki >> with a database. >> >> Best regards, >> >> Marc-Etienne >> >> -----Original Message----- >> From: Harold Hallikainen <ha...@ha...> >> Sent: Monday, July 20, 2020 2:30 AM >> To: php...@li... >> Subject: [Phpwiki-talk] Edit page stopped working >> >> I've recently been deleting spam pages and appear to have broken >> something. All my pages still seem to be there, but now when I try to >> edit any page, I get this: >> >> Warning: "fopen(/home/harold/BhWikiData/links/): failed to open stream: >> Is >> a directory" >> >> Fatal PhpWiki Error: Error while writing page '' >> >> Ideas? >> >> Thanks! >> >> Harold >> >> >> >> >> -- >> FCC Rules Updated Daily at http://www.hallikainen.com Not sent from >> an iPhone. >> >> >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk >> >> > > > -- > FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an > iPhone. > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Harold H. <ha...@ha...> - 2020-07-21 16:10:50
|
OK, it fixed itself! I was going to start looking at the PHP error messages and code this morning, but now I can edit pages fine. Nice to avoid some work! THANKS for being there! Harold > Yes, I'm using a flat file. A while back, the wiki got spammed and there > were a bunch of pages created with /etc/passwd or database commands. I've > been removing those files in the page_data directory. I'd first copy them > to a backup directory, make sure the page was still visible (these were > generally a bunch of stuff tacked on to a page name), then, if the page > seemed to still be good, I deleted the file. Now, however, I discover that > I can't edit the pages. > > What is the links directory? I thought pretty much everything was > contained in the page_data for each page (but perhaps links holds > backlinks?). > > I thought the httpd error log would show the php errors, but I'm not > finding them there (I find other PHP errors). > > It is, of course, true that /home/harold/BhWikiData/links/ is a directory, > but why is it trying to be opened? Should it instead be opening a file > within that directory? > > I guess I'll dig into the code some once I can find some indication as to > what line of what PHP file is causing the issue. > > THANKS for the quick response! > > Harold > > > > >> Hi Harold, >> >> The error message seems to imply that you are using file of flatfile as >> storage backend. >> Is it so? >> >> In that case, I am not sure I can help, I am always testing Phpwiki with >> a >> database. >> >> Best regards, >> >> Marc-Etienne >> >> -----Original Message----- >> From: Harold Hallikainen <ha...@ha...> >> Sent: Monday, July 20, 2020 2:30 AM >> To: php...@li... >> Subject: [Phpwiki-talk] Edit page stopped working >> >> I've recently been deleting spam pages and appear to have broken >> something. All my pages still seem to be there, but now when I try to >> edit >> any page, I get this: >> >> Warning: "fopen(/home/harold/BhWikiData/links/): failed to open stream: >> Is >> a directory" >> >> Fatal PhpWiki Error: Error while writing page '' >> >> Ideas? >> >> Thanks! >> >> Harold >> >> >> >> >> -- >> FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an >> iPhone. >> >> >> _______________________________________________ >> Phpwiki-talk mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk >> >> > > > -- > FCC Rules Updated Daily at http://www.hallikainen.com > Not sent from an iPhone. > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2020-07-20 19:25:28
|
Hi Harold, The error message seems to imply that you are using file of flatfile as storage backend. Is it so? In that case, I am not sure I can help, I am always testing Phpwiki with a database. Best regards, Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Monday, July 20, 2020 2:30 AM To: php...@li... Subject: [Phpwiki-talk] Edit page stopped working I've recently been deleting spam pages and appear to have broken something. All my pages still seem to be there, but now when I try to edit any page, I get this: Warning: "fopen(/home/harold/BhWikiData/links/): failed to open stream: Is a directory" Fatal PhpWiki Error: Error while writing page '' Ideas? Thanks! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
From: Harold H. <ha...@ha...> - 2020-07-20 17:54:26
|
Yes, I'm using a flat file. A while back, the wiki got spammed and there were a bunch of pages created with /etc/passwd or database commands. I've been removing those files in the page_data directory. I'd first copy them to a backup directory, make sure the page was still visible (these were generally a bunch of stuff tacked on to a page name), then, if the page seemed to still be good, I deleted the file. Now, however, I discover that I can't edit the pages. What is the links directory? I thought pretty much everything was contained in the page_data for each page (but perhaps links holds backlinks?). I thought the httpd error log would show the php errors, but I'm not finding them there (I find other PHP errors). It is, of course, true that /home/harold/BhWikiData/links/ is a directory, but why is it trying to be opened? Should it instead be opening a file within that directory? I guess I'll dig into the code some once I can find some indication as to what line of what PHP file is causing the issue. THANKS for the quick response! Harold > Hi Harold, > > The error message seems to imply that you are using file of flatfile as > storage backend. > Is it so? > > In that case, I am not sure I can help, I am always testing Phpwiki with a > database. > > Best regards, > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Monday, July 20, 2020 2:30 AM > To: php...@li... > Subject: [Phpwiki-talk] Edit page stopped working > > I've recently been deleting spam pages and appear to have broken > something. All my pages still seem to be there, but now when I try to edit > any page, I get this: > > Warning: "fopen(/home/harold/BhWikiData/links/): failed to open stream: Is > a directory" > > Fatal PhpWiki Error: Error while writing page '' > > Ideas? > > Thanks! > > Harold > > > > > -- > FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an > iPhone. > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |