Menu
▾
▴
phpwiki-talk
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
|
|
From: Marc-Etienne V. (Nokia) <mar...@no...> - 2024-03-13 19:51:19
|
Hello, PhpWiki 1.6.4 has been published. You can download it at: https://sourceforge.net/projects/phpwiki/ * Upgrade PEAR to release 1.10.14, PEAR DB to release 1.12.1 * Check for "shell_exec" before using it (Christof Meerwald) * Improve RSS (Christof Meerwald) * Add support for SQLite in PDO, add support for SQLite3 in PEAR (Christof Meerwald) Big thanks to Christof Meerwald for the patches he provided. Best regards, Marc-Etienne -- Marc-Etienne Vargenau mar...@no...<mailto:mar...@no...> Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE Mobile: +33 6 24 49 78 68 Senior Specialist Open Source Planned absence: none |
|
From: Marc-Etienne V. (Nokia) <mar...@no...> - 2024-02-27 12:00:34
|
Thank you Christof. I have implemented your patch in Subversion. Best regards, Marc-Etienne -- Marc-Etienne Vargenau mar...@no...<mailto:mar...@no...> Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE Mobile: +33 6 24 49 78 68<tel:+33624497868> Senior Specialist Open Source Planned absence: none De : Christof Meerwald via Phpwiki-talk <php...@li...> Date : samedi, 17 février 2024 à 17:47 À : php...@li... <php...@li...> Cc : Christof Meerwald <cm...@cm...> Objet : [Phpwiki-talk] Uncaught TypeError: Cannot access offset of type string on string in phpwiki/lib/stdlib.php:172 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. This one can be triggered by going to PageHistory and then clicking on "RSS" (note that "RSS2" or "Atom" don't generate a page-specific history there, but that's another issue). The second argument to WikiURL should definitely be an array and not a string, patch attached. Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Christof M. <cm...@cm...> - 2024-02-17 16:47:02
|
This one can be triggered by going to PageHistory and then clicking on "RSS" (note that "RSS2" or "Atom" don't generate a page-specific history there, but that's another issue). The second argument to WikiURL should definitely be an array and not a string, patch attached. Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Marc-Etienne V. (Nokia) <mar...@no...> - 2024-01-29 19:00:27
|
Hi Christof, Thank you for the report. I have fixed the test, now testing against “array()” instead of “false”. Best regards, Marc-Etienne -- Marc-Etienne Vargenau mar...@no...<mailto:mar...@no...> Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE Mobile: +33 6 24 49 78 68<tel:+33624497868> Senior Specialist Open Source Planned absence: none De : Christof Meerwald via Phpwiki-talk <php...@li...> Date : dimanche, 21 janvier 2024 à 19:57 À : php...@li... <php...@li...> Cc : Christof Meerwald <cm...@cm...> Objet : [Phpwiki-talk] FileFinder.php default path logic CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. I don't think it makes sense to check if the member has already been set in the constructor. And having the default argument "array()", but then comparing against "false" means we never get into the then branch. Patch is attached (so we only use the _get_include_path if FileFinder has been called with no argument specified, which I think is the intention here). Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Christof M. <cm...@cm...> - 2024-01-23 21:07:26
|
"shell_exec" might have been disabled in the PHP configuration, this will result in a hard error when trying to use ` (shell_exec), so check for it. (btw, there is another use in Units.php, but that can be disabled with DISABLE_UNITS=1, so didn't bother to patch that one) Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Christof M. <cm...@cm...> - 2024-01-23 19:23:36
|
There is a _HttpAuthPassUser::_fake_auth in WikiUser.php, so those methods should probably be static, patch attached. Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Christof M. <cm...@cm...> - 2024-01-21 18:57:44
|
I don't think it makes sense to check if the member has already been set in the constructor. And having the default argument "array()", but then comparing against "false" means we never get into the then branch. Patch is attached (so we only use the _get_include_path if FileFinder has been called with no argument specified, which I think is the intention here). Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Christof M. <cm...@cm...> - 2024-01-21 09:59:28
|
Another patch to fix atom feeds:
PHP Fatal error: Uncaught TypeError: Illegal offset type in isset or empty in phpwiki/lib/RssWriter.php:191
Stack trace:
#0 phpwiki/lib/RssWriter.php(175): RssWriter->__uniquify_uri(Array)
#1 phpwiki/lib/RssWriter.php(269): RssWriter->__node('feed', Array, Array)
#2 phpwiki/lib/plugin/RecentChanges.php(1147): AtomFeed->feed(Array)
Christof
--
https://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
|
|
From: Christof M. <cm...@cm...> - 2024-01-12 15:53:22
|
attached a patch to make defaultPerms and accessTypes static so they can be called from (static) dotPerms. Can be triggered by opening a page whose name starts with a "." Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Marc-Etienne V. (Nokia) <mar...@no...> - 2024-01-08 12:47:54
|
Hi Christof, Thank you for your report and patches. I will test them and integrate them. I must say that there are some issues with PDO. “DATABASE_TYPE = SQL” (PEAR DB) has been more tested than PDO, and it is what I use. Best wishes for the new year 2024. Marc-Etienne -- Marc-Etienne Vargenau mar...@no...<mailto:mar...@no...> Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE Mobile: +33 6 24 49 78 68<tel:+33624497868> Senior Specialist Open Source Planned absence: 1-7 January De : Christof Meerwald via Phpwiki-talk <php...@li...> Date : samedi, 30 décembre 2023 à 20:15 À : php...@li... <php...@li...> Cc : Christof Meerwald <cm...@cm...> Objet : [Phpwiki-talk] PDO sqlite backend CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. So far I have been using phpwiki with the dba backend, but web hosters don't always make dba available, so been investigating using SQLite as the backend. Anyway, tried to use PDO, but ran into a few issues - I have attached a patch that makes it work (at least for me). BTW, not really sure what that "$date > 1588437560" check was all about (1588437560 corresponds to "Sat May 2 18:39:20 2020"). Also not entirely sure what that "else" branch in PDO.php was trying to do with the database dsn - I am just passing the DATABASE_DSN to PDO there now (e.g. DATABASE_DSN = "sqlite:/path/to/file.db") Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Christof M. <cm...@cm...> - 2023-12-30 19:15:23
|
So far I have been using phpwiki with the dba backend, but web hosters don't always make dba available, so been investigating using SQLite as the backend. Anyway, tried to use PDO, but ran into a few issues - I have attached a patch that makes it work (at least for me). BTW, not really sure what that "$date > 1588437560" check was all about (1588437560 corresponds to "Sat May 2 18:39:20 2020"). Also not entirely sure what that "else" branch in PDO.php was trying to do with the database dsn - I am just passing the DATABASE_DSN to PDO there now (e.g. DATABASE_DSN = "sqlite:/path/to/file.db") Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Marc-Etienne V. (Nokia) <mar...@no...> - 2023-12-27 21:47:37
|
Hello Harold, >From the wiki itself, you can check the SystemInfo page. For example: http://phpwiki.demo.free.fr/index.php/SystemInfo In the source code, you have it in file ./lib/prepend.php:define('PHPWIKI_VERSION', '1.6.3'); Best regards, Marc-Etienne -- Marc-Etienne Vargenau mar...@no...<mailto:mar...@no...> Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE Mobile: +33 6 24 49 78 68<tel:+33624497868> Senior Specialist Open Source Planned absence: none De : Harold Hallikainen <ha...@ha...> Date : dimanche, 24 décembre 2023 à 19:46 À : php...@li... <php...@li...> Objet : [Phpwiki-talk] How to determine installed PhpWiki version? CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Is there an easy way to determine what version I have installed? Thanks! Harold _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
|
From: Harold H. <ha...@ha...> - 2023-12-24 18:46:05
|
Is there an easy way to determine what version I have installed? Thanks! Harold |
|
From: Thom J. <tho...@pr...> - 2023-11-18 15:49:07
|
Hi Marc-Etienne - I've installed 1.6.3 and confirm it's working. Thanks a lot, Thom. On Thursday, 16 November 2023 at 15:57, Marc-Etienne Vargenau (Nokia) <mar...@no...> wrote: > Hi Thom, > > I have just published PhpWiki 1.6.3 with a fix for your issue. > > You can download it at: https://sourceforge.net/projects/phpwiki/ > > Thank you again for your bug report. > > Best regards, > > Marc-Etienne > > -- > Marc-Etienne Vargenau mar...@no... > Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE > Mobile: [+33 6 24 49 78 68](tel:+33624497868) > > Senior Specialist Open Source > Planned absence: none > > De : Marc-Etienne Vargenau (Nokia) <mar...@no...> > Date : mercredi, 8 novembre 2023 à 19:55 > À : Discussion on PhpWiki features, bugs, development. <php...@li...> > Cc : Thom Jeera <tho...@pr...> > Objet : Re: [Phpwiki-talk] TypeError in ExternalReferrer under php8 > > Hi Thom, > > Thank you for the report. > > I will test and provide a fix. > > Is your Phpwiki internal or available on the Internet? > > Best regards, > > Marc-Etienne > > -- > Marc-Etienne Vargenau mar...@no... > Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE > Mobile: [+33 6 24 49 78 68](tel:+33624497868) > > Senior Specialist Open Source > Planned absence: none > > De : Thom Jeera via Phpwiki-talk <php...@li...> > Date : mardi, 24 octobre 2023 à 21:35 > À : php...@li... <php...@li...> > Cc : Thom Jeera <tho...@pr...> > Objet : [Phpwiki-talk] TypeError in ExternalReferrer under php8 > > CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. > > Hi - I'm running phpwiki-1.6.2 on php 8.2.11. > > I saw an error when someone clicked a phpwiki link from within a gmail app - see bottom of email. The 'google.' in the referer triggers the external referrer code, which breaks under php8 (seems ok in php5 - I couldn't recreate it against phpwiki.demo.free.fr for instance). > > Something like this would trigger it under php8: > > curl -H 'referer: android-app://com.google.android.gm/' http://phpwiki.demo.free.fr/index.php/SandBox > > The code here in ExternalReferrer.php looks inconsistent - if there is no query string (ie the tested value IS empty), then $url is still an array when it gets passed into stristr, hence the error. > > if (!empty($url["query"])) { > $url = $url["query"]; > } > > if ($query1 and @stristr($url, $query1)) { > > The behaviour is present but the error gets suppressed under earlier versions of php. > > Suggested fix: add "else return false;" after the !empty test ? > > Reported error: > > Got error 'PHP message: PHP Fatal error: Uncaught TypeError: stristr(): > Argument #1 ($haystack) must be of type string, array given in /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php:129 > Stack trace: > #0 /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php(129): stristr() > #1 /syshome/webchris/html/phpwiki-1.6.1/lib/stdlib.php(1890): SearchEngines->parseSearchQuery() > #2 /syshome/webchris/html/phpwiki-1.6.1/lib/display.php(324): isExternalReferrer() > #3 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1069): displayPage() > #4 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(816): WikiRequest->action_browse() > #5 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1451): WikiRequest->handleAction() > #6 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1475): main() > #7 /syshome/webchris/html/phpwiki-1.6.1/index.php(60): include('...') > #8 {main} > thrown in /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php on line 129', referer: android-app://com.google.android.gm/ > > Regards, > Thom. > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
|
From: Marc-Etienne V. (Nokia) <mar...@no...> - 2023-11-16 17:30:42
|
Hi Thom, I have just published PhpWiki 1.6.3 with a fix for your issue. You can download it at: https://sourceforge.net/projects/phpwiki/ Thank you again for your bug report. Best regards, Marc-Etienne -- Marc-Etienne Vargenau mar...@no...<mailto:mar...@no...> Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE Mobile: +33 6 24 49 78 68<tel:+33624497868> Senior Specialist Open Source Planned absence: none De : Marc-Etienne Vargenau (Nokia) <mar...@no...> Date : mercredi, 8 novembre 2023 à 19:55 À : Discussion on PhpWiki features, bugs, development. <php...@li...> Cc : Thom Jeera <tho...@pr...> Objet : Re: [Phpwiki-talk] TypeError in ExternalReferrer under php8 Hi Thom, Thank you for the report. I will test and provide a fix. Is your Phpwiki internal or available on the Internet? Best regards, Marc-Etienne -- Marc-Etienne Vargenau mar...@no...<mailto:mar...@no...> Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE Mobile: +33 6 24 49 78 68<tel:+33624497868> Senior Specialist Open Source Planned absence: none De : Thom Jeera via Phpwiki-talk <php...@li...> Date : mardi, 24 octobre 2023 à 21:35 À : php...@li... <php...@li...> Cc : Thom Jeera <tho...@pr...> Objet : [Phpwiki-talk] TypeError in ExternalReferrer under php8 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi - I'm running phpwiki-1.6.2 on php 8.2.11. I saw an error when someone clicked a phpwiki link from within a gmail app - see bottom of email. The 'google.' in the referer triggers the external referrer code, which breaks under php8 (seems ok in php5 - I couldn't recreate it against phpwiki.demo.free.fr for instance). Something like this would trigger it under php8: curl -H 'referer: android-app://com.google.android.gm/' http://phpwiki.demo.free.fr/index.php/SandBox The code here in ExternalReferrer.php looks inconsistent - if there is no query string (ie the tested value IS empty), then $url is still an array when it gets passed into stristr, hence the error. if (!empty($url["query"])) { $url = $url["query"]; } if ($query1 and @stristr($url, $query1)) { The behaviour is present but the error gets suppressed under earlier versions of php. Suggested fix: add "else return false;" after the !empty test ? Reported error: Got error 'PHP message: PHP Fatal error: Uncaught TypeError: stristr(): Argument #1 ($haystack) must be of type string, array given in /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php:129 Stack trace: #0 /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php(129): stristr() #1 /syshome/webchris/html/phpwiki-1.6.1/lib/stdlib.php(1890): SearchEngines->parseSearchQuery() #2 /syshome/webchris/html/phpwiki-1.6.1/lib/display.php(324): isExternalReferrer() #3 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1069): displayPage() #4 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(816): WikiRequest->action_browse() #5 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1451): WikiRequest->handleAction() #6 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1475): main() #7 /syshome/webchris/html/phpwiki-1.6.1/index.php(60): include('...') #8 {main} thrown in /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php on line 129', referer: android-app://com.google.android.gm/ Regards, Thom. _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
|
From: Marc-Etienne V. (Nokia) <mar...@no...> - 2023-11-08 19:29:32
|
Hi Thom, Thank you for the report. I will test and provide a fix. Is your Phpwiki internal or available on the Internet? Best regards, Marc-Etienne -- Marc-Etienne Vargenau mar...@no...<mailto:mar...@no...> Nokia, 12, rue Jean-Bart, 91300 Massy, FRANCE Mobile: +33 6 24 49 78 68<tel:+33624497868> Senior Specialist Open Source Planned absence: none De : Thom Jeera via Phpwiki-talk <php...@li...> Date : mardi, 24 octobre 2023 à 21:35 À : php...@li... <php...@li...> Cc : Thom Jeera <tho...@pr...> Objet : [Phpwiki-talk] TypeError in ExternalReferrer under php8 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi - I'm running phpwiki-1.6.2 on php 8.2.11. I saw an error when someone clicked a phpwiki link from within a gmail app - see bottom of email. The 'google.' in the referer triggers the external referrer code, which breaks under php8 (seems ok in php5 - I couldn't recreate it against phpwiki.demo.free.fr for instance). Something like this would trigger it under php8: curl -H 'referer: android-app://com.google.android.gm/' http://phpwiki.demo.free.fr/index.php/SandBox The code here in ExternalReferrer.php looks inconsistent - if there is no query string (ie the tested value IS empty), then $url is still an array when it gets passed into stristr, hence the error. if (!empty($url["query"])) { $url = $url["query"]; } if ($query1 and @stristr($url, $query1)) { The behaviour is present but the error gets suppressed under earlier versions of php. Suggested fix: add "else return false;" after the !empty test ? Reported error: Got error 'PHP message: PHP Fatal error: Uncaught TypeError: stristr(): Argument #1 ($haystack) must be of type string, array given in /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php:129 Stack trace: #0 /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php(129): stristr() #1 /syshome/webchris/html/phpwiki-1.6.1/lib/stdlib.php(1890): SearchEngines->parseSearchQuery() #2 /syshome/webchris/html/phpwiki-1.6.1/lib/display.php(324): isExternalReferrer() #3 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1069): displayPage() #4 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(816): WikiRequest->action_browse() #5 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1451): WikiRequest->handleAction() #6 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1475): main() #7 /syshome/webchris/html/phpwiki-1.6.1/index.php(60): include('...') #8 {main} thrown in /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php on line 129', referer: android-app://com.google.android.gm/ Regards, Thom. _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
|
From: Thom J. <tho...@pr...> - 2023-10-24 19:34:57
|
Hi - I'm running phpwiki-1.6.2 on php 8.2.11. I saw an error when someone clicked a phpwiki link from within a gmail app - see bottom of email. The 'google.' in the referer triggers the external referrer code, which breaks under php8 (seems ok in php5 - I couldn't recreate it against phpwiki.demo.free.fr for instance). Something like this would trigger it under php8: curl -H 'referer: android-app://com.google.android.gm/' http://phpwiki.demo.free.fr/index.php/SandBox The code here in ExternalReferrer.php looks inconsistent - if there is no query string (ie the tested value IS empty), then $url is still an array when it gets passed into stristr, hence the error. if (!empty($url["query"])) { $url = $url["query"]; } if ($query1 and @stristr($url, $query1)) { The behaviour is present but the error gets suppressed under earlier versions of php. Suggested fix: add "else return false;" after the !empty test ? Reported error: Got error 'PHP message: PHP Fatal error: Uncaught TypeError: stristr(): Argument #1 ($haystack) must be of type string, array given in /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php:129 Stack trace: #0 /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php(129): stristr() #1 /syshome/webchris/html/phpwiki-1.6.1/lib/stdlib.php(1890): SearchEngines->parseSearchQuery() #2 /syshome/webchris/html/phpwiki-1.6.1/lib/display.php(324): isExternalReferrer() #3 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1069): displayPage() #4 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(816): WikiRequest->action_browse() #5 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1451): WikiRequest->handleAction() #6 /syshome/webchris/html/phpwiki-1.6.1/lib/main.php(1475): main() #7 /syshome/webchris/html/phpwiki-1.6.1/index.php(60): include('...') #8 {main} thrown in /syshome/webchris/html/phpwiki-1.6.1/lib/ExternalReferrer.php on line 129', referer: android-app://com.google.android.gm/ Regards, Thom. |
|
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2022-02-14 15:46:44
|
Hi Christof, Thank you for your report. I will include your patch in the next release. Best regards, Marc-Etienne -----Original Message----- From: Christof Meerwald <cm...@cm...> Sent: Wednesday, February 9, 2022 7:08 PM To: php...@li... Subject: [Phpwiki-talk] Calendar and CalendarList plugins return incorrect links array Hi, just noticed that both the Calendar and CalendarList plugins return incorrect links array from "getWikiPageLinks". Attached is a patch for this, although removing the whole getWikiPageLinks from those plugins might be the better option (as the comment says "static only as of action=edit") as it's not really useful that way. Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Christof M. <cm...@cm...> - 2022-02-09 18:25:46
|
Hi, just noticed that both the Calendar and CalendarList plugins return incorrect links array from "getWikiPageLinks". Attached is a patch for this, although removing the whole getWikiPageLinks from those plugins might be the better option (as the comment says "static only as of action=edit") as it's not really useful that way. Christof -- https://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org |
|
From: Vargenau, Marc-E. (N. - FR/Paris-Saclay)
<mar...@no...> - 2022-01-19 16:57:05
|
Hi Harold, Yes, the uploads are not included in a wiki dump. I need to check if this is easily doable. Best regards, Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Tuesday, January 18, 2022 8:37 PM To: php...@li... Subject: Re: [Phpwiki-talk] Upload URL has double slash between host and path Perfect! Just installed phpwiki-code-r10908-trunk.zip, and that fixed the upload URL issue. I note that uploads are not included in a wiki dump and need to be copied separately. Any chance of including uploads in the dump? THANKS! Harold On Tue, January 18, 2022 7:12 am, Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay) wrote: > Hi Harold, > > This was happening when DATA_PATH is empty. > Fixed in Subversion 10905. > > Best regards, > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Tuesday, January 18, 2022 6:09 AM > To: php...@li... > Subject: [Phpwiki-talk] Upload URL has double slash between host and > path > > This doesn't seem to cause an issue with browsers, but I am seeing a > double slash between the hostname and the path. > > For example, > > https://bh.hallikainen.org//uploads/harold/Drc190Data.pdf > > In config.ini, neither UPLOAD_FILE_PATH nor UPLOAD_DATA_PATH are > overridden. > > 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. _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
|
From: Harold H. <ha...@ha...> - 2022-01-18 19:36:42
|
Perfect! Just installed phpwiki-code-r10908-trunk.zip, and that fixed the upload URL issue. I note that uploads are not included in a wiki dump and need to be copied separately. Any chance of including uploads in the dump? THANKS! Harold On Tue, January 18, 2022 7:12 am, Vargenau, Marc-Etienne (Nokia - FR/Paris-Saclay) wrote: > Hi Harold, > > This was happening when DATA_PATH is empty. > Fixed in Subversion 10905. > > Best regards, > > Marc-Etienne > > -----Original Message----- > From: Harold Hallikainen <ha...@ha...> > Sent: Tuesday, January 18, 2022 6:09 AM > To: php...@li... > Subject: [Phpwiki-talk] Upload URL has double slash between host and path > > This doesn't seem to cause an issue with browsers, but I am seeing a > double slash between the hostname and the path. > > For example, > > https://bh.hallikainen.org//uploads/harold/Drc190Data.pdf > > In config.ini, neither UPLOAD_FILE_PATH nor UPLOAD_DATA_PATH are > overridden. > > 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...> - 2022-01-18 14:26:45
|
Hi Harold, This was happening when DATA_PATH is empty. Fixed in Subversion 10905. Best regards, Marc-Etienne -----Original Message----- From: Harold Hallikainen <ha...@ha...> Sent: Tuesday, January 18, 2022 6:09 AM To: php...@li... Subject: [Phpwiki-talk] Upload URL has double slash between host and path This doesn't seem to cause an issue with browsers, but I am seeing a double slash between the hostname and the path. For example, https://bh.hallikainen.org//uploads/harold/Drc190Data.pdf In config.ini, neither UPLOAD_FILE_PATH nor UPLOAD_DATA_PATH are overridden. 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...> - 2022-01-18 05:09:34
|
This doesn't seem to cause an issue with browsers, but I am seeing a double slash between the hostname and the path. For example, https://bh.hallikainen.org//uploads/harold/Drc190Data.pdf In config.ini, neither UPLOAD_FILE_PATH nor UPLOAD_DATA_PATH are overridden. Harold -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. |
|
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 |
207 messages has been excluded from this view by a project administrator.