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
(3) |
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
From: Oliver B. <li...@gm...> - 2010-03-29 12:25:38
|
Thompson, Steve wrote: > I've just installed PhpWiki and I like the simplicity. It's version > 1.2.11 - do I have the most recent? that's the most recent so called "stable" version, but it's outdated afaik. 1.3 is "current". > Is this even a supported application. It's hard to tell from the stuff > I've found on the web. I found this there are better supported Wikis out there. Even the demo site http://phpwiki.sourceforge.net/ is broken since years. I switched to PmWiki for active sites but I have still a PhpWiki running with unmaintained content. I'm just too lazy to convert it, but at least I listen here to learn about upcoming problems (e.g. PHP incompatibilities or security issues). You might have a look at DokuWiki, too. Somewhat different goals than PmWiki's. Oliver -- Oliver Betz, Muenchen |
From: Thompson, S. <S.D...@te...> - 2010-03-22 19:49:15
|
Hi, I've just installed PhpWiki and I like the simplicity. It's version 1.2.11 - do I have the most recent? Is this even a supported application. It's hard to tell from the stuff I've found on the web. I found this http://wiki.bic.mni.mcgill.ca/index.php/PhpWikiDocumentation but it does not seem to refer to the product I have intstalled. It's a phpwiki but looks a lot better than mine. How is that done? Steve T |
From: Marc-Etienne V. <Mar...@al...> - 2010-01-11 14:41:39
|
Hello Reini, I would like to disallow some characters in wiki page names (commas that create many problems, e.g. for backlinks and page renaming, "<" and ">"). I tried in stdlib "function isValid" but it does not seem to work (called too late?). What is the best way to do this? Best regards, Marc-Etienne -- Marc-Etienne Vargenau Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE +33 (0)1 30 77 28 33, Mar...@al... |
From: Reini U. <ru...@x-...> - 2009-11-11 13:29:33
|
2009/11/11 Tom Eicher <ro...@te...>: > Hi, sorry for not getting back to this earlier, > >>> > Do you have any idea what is being zipped or unzipped on every >>> > page request ? >> It's the gzipped pre-prepared page object, which is stored in the >> database. Obviously with a unsupported gzip format. > >>> > Any idea how to fix this ? >> PhpWikiAdministration >> purge-cache > > Yes, that worked, thanks! > After purge, I was able to "un-un-comment" that code and it's > working now. > > Well, "barely working". As I wrote, I'm still on 1.3.12p3. > > I get "lib/Request.php:820: Notice[1024]: The PhpWiki access log file is > not writable. Please ensure that the file > '/var/log/apache2/wiki_access_log' is writable, or redefine ACCESS_LOG > in config/config.ini." > no matter what I configure in config.ini, even "empty to disable" > does not help. Also, on every 10th page request or so, I get the > page as "plain HTML" with no stylesheets... (no, it's not the > apache, that's working well for other stuff...) You can disable the accesslog writer in lib/Request.php class Request { function Request() { ... if (false) { $this->_accesslog = new Request_AccessLog(ACCESS_LOG, ACCESS_LOG_SQL); } ... > > It would really be nice to get a working "official major release"... > > Download on SF is still 1.2... That's a problem with the recent sf.net UI change. You have to get to the 1.3.x series by clicking on "VIEW ALL FILES" and get to "PhpWiki 1.3" (current) and then to "phpwiki-1.3.14" > Link to SF Page http://phpwiki.sourceforge.net/phpwiki-1.2/ from > http://phpwiki.sourceforge.net/ is broken (empty page)... yes. this is disabled now. > I'd really like to help out by documenting stuff like that upgrade > problem you helped solve, or "what to configure on a vanilla Suse > 11.1 to get PHPWiki running", but for that we need a functioning > projekt home wiki, right ? -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Tom E. <ro...@te...> - 2009-11-10 23:37:27
|
Hi, sorry for not getting back to this earlier, >> > Do you have any idea what is being zipped or unzipped on every >> > page request ? > It's the gzipped pre-prepared page object, which is stored in the > database. Obviously with a unsupported gzip format. >> > Any idea how to fix this ? > PhpWikiAdministration > purge-cache Yes, that worked, thanks! After purge, I was able to "un-un-comment" that code and it's working now. Well, "barely working". As I wrote, I'm still on 1.3.12p3. I get "lib/Request.php:820: Notice[1024]: The PhpWiki access log file is not writable. Please ensure that the file '/var/log/apache2/wiki_access_log' is writable, or redefine ACCESS_LOG in config/config.ini." no matter what I configure in config.ini, even "empty to disable" does not help. Also, on every 10th page request or so, I get the page as "plain HTML" with no stylesheets... (no, it's not the apache, that's working well for other stuff...) It would really be nice to get a working "official major release"... Download on SF is still 1.2... Link to SF Page http://phpwiki.sourceforge.net/phpwiki-1.2/ from http://phpwiki.sourceforge.net/ is broken (empty page)... I'd really like to help out by documenting stuff like that upgrade problem you helped solve, or "what to configure on a vanilla Suse 11.1 to get PHPWiki running", but for that we need a functioning projekt home wiki, right ? Cheers, Tom. |
From: Reini U. <ru...@x-...> - 2009-10-14 21:04:47
|
2009/10/13 <var...@us...>: > Revision: 7210 > http://phpwiki.svn.sourceforge.net/phpwiki/?rev=7210&view=rev > Author: vargenau > Date: 2009-10-13 08:32:12 +0000 (Tue, 13 Oct 2009) > > Log Message: > ----------- > Repair UTF-8 characters that were broken by r7208 Oops, sorry. I'm on windows. I have to add the special encoding to my .emacs -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Reini U. <ru...@x-...> - 2009-10-14 21:01:43
|
2009/10/14 Tom Eicher <ro...@te...>: > stuff), I came to a point where every page request would give a >> Fatal PhpWiki Error >> Unsupported ZIP header type: xÚT > > I tracked down that message and found it in ziplib (line 452 in > my version). Now the fun thing is, I just commented the >> ExitWiki(sprintf("Unsupported ZIP header type: %s ", $magic)); > out, and now it seems to run. > > My PHP skills are a bit rusty, so I was unable to find out just > what we're trying to zip or unzip here... > > I tried the ziplib versions from the previous phpwikis I still have > on disk, 1.3.11rc3 and 1.3.10, but they produced the same result. > > Questions: > > Did I do something harmful by commenting it out ? No. > Do you have any idea what is being zipped or unzipped on every > page request ? It's the gzipped pre-prepared page object, which is stored in the database. Obviously with a unsupported gzip format. > Any idea how to fix this ? PhpWikiAdministration purge-cache -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Tom E. <ro...@te...> - 2009-10-14 18:28:00
|
Greetings, as upgrading systems, and especially everything involving php on linux is always very painful (at least in my experience ;-) I always postpone that as long as possible. But now is the time :-) I have (had ;-) a phpwiki 1.3.12p3 running on SuSE Linux 10.2, and moved that installation to a new SuSE 10.1 (latest patches). After fiddling with the usual PHP stuff (register_long_arrays and stuff), I came to a point where every page request would give a > Fatal PhpWiki Error > Unsupported ZIP header type: xÚT I tracked down that message and found it in ziplib (line 452 in my version). Now the fun thing is, I just commented the > ExitWiki(sprintf("Unsupported ZIP header type: %s ", $magic)); out, and now it seems to run. My PHP skills are a bit rusty, so I was unable to find out just what we're trying to zip or unzip here... I tried the ziplib versions from the previous phpwikis I still have on disk, 1.3.11rc3 and 1.3.10, but they produced the same result. Questions: Did I do something harmful by commenting it out ? Do you have any idea what is being zipped or unzipped on every page request ? Any idea how to fix this ? Is it maybe related to the newer linux having different compression algorithms somehwere, or the newer apache2 httpd ? Cheers! Tom. |
From: Reini U. <ru...@x-...> - 2009-10-12 12:05:33
|
2009/10/12 <var...@us...>: > Revision: 7204 > http://phpwiki.svn.sourceforge.net/phpwiki/?rev=7204&view=rev > Author: vargenau > Date: 2009-10-12 11:59:34 +0000 (Mon, 12 Oct 2009) > > Log Message: > ----------- > Specific code for Internet Explorer > > Modified Paths: > -------------- > trunk/lib/plugin/Video.php > > Modified: trunk/lib/plugin/Video.php > =================================================================== > --- trunk/lib/plugin/Video.php 2009-10-12 10:41:27 UTC (rev 7203) > +++ trunk/lib/plugin/Video.php 2009-10-12 11:59:34 UTC (rev 7204) > @@ -89,26 +89,60 @@ > > $html = HTML(); > > - $object = HTML::object(array('data' => SERVER_URL . $WikiTheme->_findData('flowplayer-3.1.3.swf'), > - 'type' => "application/x-shockwave-flash", > - 'width' => $width, > - 'height' => $height)); Please use the function ImgObject() as it does all the browser specific object / embed tags for such objects. Safari also needs special handling. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Reini U. <ru...@x-...> - 2009-09-24 09:24:23
|
Good! I had the same idea for using flowplayer for local videos, but you guys beat me. Log Message: ----------- New plugin to add video in wiki pages Added Paths: ----------- trunk/lib/plugin/Video.php trunk/pgsrc/Help%2FVideoPlugin trunk/themes/default/flowplayer-3.1.3.swf trunk/themes/default/flowplayer.controls-3.1.3.swf -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Stefan <son...@ba...> - 2009-09-18 08:02:14
|
hi there, one tiny question: My server shows a local time 9:02 am phpwiki and recent changes shows after a fresh edit 8:02 am. All other php programs do show the correct time. Where can i change the global settings for phpwiki to use the servertime or correct time offset. there is no special user settings set. cheers Stefan |
From: Antony S. <Ant...@ph...> - 2009-09-10 17:19:58
|
On Thursday 10 September 2009 13:32, Reini Urban wrote: > 2009/9/9 Antony Stone <Ant...@ph...>: > > On Wednesday 09 September 2009 16:35, Reini Urban wrote: > >> 2009/9/9 Antony Stone <Ant...@ph...>: > >> > On Sunday 06 September 2009 14:02, Antony Stone wrote: > >> >> ; True User Authentication: > >> >> ; To require user passwords: > >> >> ; ALLOW_ANON_USER = false > >> >> ; ALLOW_ANON_EDIT = false > >> >> ; ALLOW_BOGO_LOGIN = false, > >> >> ; ALLOW_USER_PASSWORDS = true. > >> >> > >> >> I have set all four variables to the required values and restarted > >> >> Apache, and yet it is still possible to log in with a random username > >> >> and no password (ie: a Bogo login). > > I have not explicitly set USER_AUTH_ORDER (the instructions for getting > > True User Authentication don't tell me I need to) > > Should I select "USER_AUTH_ORDER = Db" instead (since I am using a MySQL > > backend database, I'd quite like all the authentication data to be in > > there as well)? > > Yes, please. "USER_AUTH_ORDER = Db" for Mysql auth Thanks, that has created the "Login required" functionality that I needed (I think it would be good if the docs in the config file said that this is necessary). I put a username / password into the MySQL 'pref' table by hand, and I can log in with those credentials. Now I just need to deal with my other problem - how to allow the Admin user to log in so that s/he can manage the other user accounts. I have set ADMIN_USER = Admin ADMIN_PASSWD = Admin in config.ini, but I can't log in with these credentials. Do I need to manually insert them into the MySQL table as well, so that this Admin User can then add the other normal accounts? The documentation is not too clear on how the accounts are managed, and since I haven't been able to log in as Admin yet, I'm simply assuming that it's done through the /PhpWikiAdministration page... Any helpful guidance would be much appreciated. Thanks, Antony. -- In the Beginning there was nothing, which exploded. - Terry Pratchett Please reply to the list; please don't CC me. |
From: Reini U. <ru...@x-...> - 2009-09-10 12:33:49
|
2009/9/9 Antony Stone <Ant...@ph...>: > On Wednesday 09 September 2009 16:35, Reini Urban wrote: > >> 2009/9/9 Antony Stone <Ant...@ph...>: >> > On Sunday 06 September 2009 14:02, Antony Stone wrote: >> >> ; True User Authentication: >> >> ; To require user passwords: >> >> ; ALLOW_ANON_USER = false >> >> ; ALLOW_ANON_EDIT = false >> >> ; ALLOW_BOGO_LOGIN = false, >> >> ; ALLOW_USER_PASSWORDS = true. >> >> ; Otherwise any anon or bogo user might login without any or a wrong >> >> password. >> >> >> >> I have set all four variables to the required values and restarted >> >> Apache, and yet it is still possible to log in with a random username >> >> and no password (ie: a Bogo login). How do I get the functionality as >> >> documented - True User Authentication? Do I need to reset / reconfigure >> >> / restart something else after changing the config.ini file? > >> Tell us your USER_AUTH_ORDER >> These are effective with ALLOW_USER_PASSWORDS >> >> If you have e.g. USER_AUTH_ORDER = "BogoLogin : PersonalPage" >> BogoLogin is in use as you observed. > > I have not explicitly set USER_AUTH_ORDER (the instructions for getting True > User Authentication don't tell me I need to), therefore I expect the setting > to have the value in /usr/share/phpwiki/config/config-default.ini, which is: > > USER_AUTH_ORDER = PersonalPage > > Should I select "USER_AUTH_ORDER = Db" instead (since I am using a MySQL > backend database, I'd quite like all the authentication data to be in there > as well)? Yes, please. "USER_AUTH_ORDER = Db" for Mysql auth > Thanks for the reply - it's good to see there's someone else around here :) Most of the developers are rather busy -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Antony S. <Ant...@ph...> - 2009-09-09 21:35:40
|
On Wednesday 09 September 2009 16:35, Reini Urban wrote: > 2009/9/9 Antony Stone <Ant...@ph...>: > > On Sunday 06 September 2009 14:02, Antony Stone wrote: > >> ; True User Authentication: > >> ; To require user passwords: > >> ; ALLOW_ANON_USER = false > >> ; ALLOW_ANON_EDIT = false > >> ; ALLOW_BOGO_LOGIN = false, > >> ; ALLOW_USER_PASSWORDS = true. > >> ; Otherwise any anon or bogo user might login without any or a wrong > >> password. > >> > >> I have set all four variables to the required values and restarted > >> Apache, and yet it is still possible to log in with a random username > >> and no password (ie: a Bogo login). How do I get the functionality as > >> documented - True User Authentication? Do I need to reset / reconfigure > >> / restart something else after changing the config.ini file? > Tell us your USER_AUTH_ORDER > These are effective with ALLOW_USER_PASSWORDS > > If you have e.g. USER_AUTH_ORDER = "BogoLogin : PersonalPage" > BogoLogin is in use as you observed. I have not explicitly set USER_AUTH_ORDER (the instructions for getting True User Authentication don't tell me I need to), therefore I expect the setting to have the value in /usr/share/phpwiki/config/config-default.ini, which is: USER_AUTH_ORDER = PersonalPage Should I select "USER_AUTH_ORDER = Db" instead (since I am using a MySQL backend database, I'd quite like all the authentication data to be in there as well)? Thanks for the reply - it's good to see there's someone else around here :) Antony. -- Atheism is a non-prophet-making organisation. Please reply to the list; please don't CC me. |
From: Reini U. <ru...@x-...> - 2009-09-09 15:35:34
|
2009/9/9 Antony Stone <Ant...@ph...>: > On Sunday 06 September 2009 14:02, Antony Stone wrote: >> ; True User Authentication: >> ; To require user passwords: >> ; ALLOW_ANON_USER = false >> ; ALLOW_ANON_EDIT = false >> ; ALLOW_BOGO_LOGIN = false, >> ; ALLOW_USER_PASSWORDS = true. >> ; Otherwise any anon or bogo user might login without any or a wrong >> password. >> >> I have set all four variables to the required values and restarted Apache, >> and yet it is still possible to log in with a random username and no >> password (ie: a Bogo login). How do I get the functionality as documented >> - True User Authentication? Do I need to reset / reconfigure / restart >> something else after changing the config.ini file? > > Is this list really as low-volume as it appears? Since I joined on Sunday > I've seen precisely three postings to it, two of them from me. > > Am I asking in the wrong place? Is there somewhere else I can get help on > using PHPwiki? Probably not. > Any helpful advice gratefully received - I'd really like to be able to use > this software, but in the absence of effective documentation, or somewhere I > can get help when the documentation fails, I'll have to give up and use > something else instead :( Sorry. I was also out ideas, but now I got one. To me it also looked like Massimiliano said, wrong config.ini. Tell us your USER_AUTH_ORDER These are effective with ALLOW_USER_PASSWORDS If you have e.g. USER_AUTH_ORDER = "BogoLogin : PersonalPage" BogoLogin is in use as you observed. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Antony S. <Ant...@ph...> - 2009-09-09 11:35:54
|
On Sunday 06 September 2009 14:02, Antony Stone wrote: > ; True User Authentication: > ; To require user passwords: > ; ALLOW_ANON_USER = false > ; ALLOW_ANON_EDIT = false > ; ALLOW_BOGO_LOGIN = false, > ; ALLOW_USER_PASSWORDS = true. > ; Otherwise any anon or bogo user might login without any or a wrong > password. > > I have set all four variables to the required values and restarted Apache, > and yet it is still possible to log in with a random username and no > password (ie: a Bogo login). How do I get the functionality as documented > - True User Authentication? Do I need to reset / reconfigure / restart > something else after changing the config.ini file? Is this list really as low-volume as it appears? Since I joined on Sunday I've seen precisely three postings to it, two of them from me. Am I asking in the wrong place? Is there somewhere else I can get help on using PHPwiki? Any helpful advice gratefully received - I'd really like to be able to use this software, but in the absence of effective documentation, or somewhere I can get help when the documentation fails, I'll have to give up and use something else instead :( Thanks, Antony. -- I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies, and the other way is to make it so complicated that there are no _obvious_ deficiences. - C A R Hoare Please reply to the list; please don't CC me. |
From: Antony S. <Ant...@ph...> - 2009-09-07 09:03:22
|
On Monday 07 September 2009 08:39, Massimiliano Pagani wrote: > Hi Antony, > I am not an expert, but it seems that you edit a config file while > your phpWiki reads another one. Make sure you are editing (path to > phpWiki)/config/config.ini. That is a symbolic link to /etc/phpwiki/config/ini on this Debian machine. Therefore there is only one file. I can be fairly sure I am editing the correct file because I see the new name I gave the wiki in that config file when I access the web server. > Also, though it doesn't hurt, it shouldn't be needed a complete apache > restart since the config.ini file is read at every HTTP access. Ah, thanks, I wasn't sure what, if anything, I needed to do after changing this file to make it take effect. I must say that reading and parsing a plaintext config file on every single HTTP access seems worryingly inefficient, though... > On Sun, Sep 6, 2009 at 3:02 PM, Antony Stone wrote: > > Hi. > > > > I'm trying to use PHPwiki on a Debian Etch machine and having problems > > with authentication. > > > > It's Debian Etch (which I can't upgrade to Lenny for unrelated hardware > > reasons), which gives me PHPwiki version 1.3.12p3-5etch1. > > > > I'm using Apache 1.3.34, and MySQL 5.0.32 as the backend database, and > > it's a fresh install of the phpwiki package, with only the changes noted > > below. > > > > > > I have two problems: > > > > 1. I want to operate this Wiki so that only authorised users can access > > it (both for reading and for writing) - it's basically a collaborative > > development tool which needs to be on the Internet to allow access for > > diversely located people, but we don't want it to be wide open and > > publicly visible or editable. Therefore I have followed the instructions > > in config.ini to require passwords for login: > > > > ; True User Authentication: > > ; To require user passwords: > > ; ALLOW_ANON_USER = false > > ; ALLOW_ANON_EDIT = false > > ; ALLOW_BOGO_LOGIN = false, > > ; ALLOW_USER_PASSWORDS = true. > > ; Otherwise any anon or bogo user might login without any or a wrong > > password. > > > > I have set all four variable to the required values and restarted Apache, > > and yet it is still possible to log in with a random username and no > > password (ie: a Bogo login). How do I get the functionality as > > documented - True User Authentication? Do I need to reset / reconfigure > > / restart something else after changing the config.ini file? > > > > > > 2. I cannot create an Admin user and log in as such. If I > > edit /etc/phpwiki/config.ini and set: > > > > ADMIN_USER = Admin > > ADMIN_PASSWD = Admin > > > > (and restart Apache afterwards just in case) then when I go to the URL of > > my Wiki site, I now get: > > > > Fatal Error: > > lib/IniConfig.php:601: Error: ADMIN_USER may not be empty. Please update > > your configuration. > > lib/IniConfig.php:221: Notice: missing config setting for ADMIN_USER > > (...repeated 2 times) > > lib/IniConfig.php:601: Error: ADMIN_USER may not be empty. Please update > > your configuration. > > > > So, in config.ini, I have ADMIN_USER set, therefore this error message > > makes no sense. What should I check instead? > > > > > > > > I hope someone can help with either / both of these problems. > > > > Please let me know if further data on the setup would be helpful. > > > > > > Regards, > > > > > > Antony Stone. -- "I estimate there's a world market for about five computers." - Thomas J Watson, Chairman of IBM Please reply to the list; please don't CC me. |
From: Massimiliano P. <ma...@gm...> - 2009-09-07 07:40:07
|
Hi Antony, I am not an expert, but it seems that you edit a config file while your phpWiki reads another one. Make sure you are editing (path to phpWiki)/config/config.ini. Also, though it doesn't hurt, it shouldn't be needed a complete apache restart since the config.ini file is read at every HTTP access. Hope this helps. Bye Massimiliano Pagani http://www.maxpagani.org/ On Sun, Sep 6, 2009 at 3:02 PM, Antony Stone<Ant...@ph...> wrote: > Hi. > > I'm trying to use PHPwiki on a Debian Etch machine and having problems with > authentication. > > It's Debian Etch (which I can't upgrade to Lenny for unrelated hardware > reasons), which gives me PHPwiki version 1.3.12p3-5etch1. > > I'm using Apache 1.3.34, and MySQL 5.0.32 as the backend database, and it's a > fresh install of the phpwiki package, with only the changes noted below. > > > I have two problems: > > 1. I want to operate this Wiki so that only authorised users can access it > (both for reading and for writing) - it's basically a collaborative > development tool which needs to be on the Internet to allow access for > diversely located people, but we don't want it to be wide open and publicly > visible or editable. Therefore I have followed the instructions in > config.ini to require passwords for login: > > ; True User Authentication: > ; To require user passwords: > ; ALLOW_ANON_USER = false > ; ALLOW_ANON_EDIT = false > ; ALLOW_BOGO_LOGIN = false, > ; ALLOW_USER_PASSWORDS = true. > ; Otherwise any anon or bogo user might login without any or a wrong password. > > I have set all four variable to the required values and restarted Apache, and > yet it is still possible to log in with a random username and no password > (ie: a Bogo login). How do I get the functionality as documented - True User > Authentication? Do I need to reset / reconfigure / restart something else > after changing the config.ini file? > > > 2. I cannot create an Admin user and log in as such. If I > edit /etc/phpwiki/config.ini and set: > > ADMIN_USER = Admin > ADMIN_PASSWD = Admin > > (and restart Apache afterwards just in case) then when I go to the URL of my > Wiki site, I now get: > > Fatal Error: > lib/IniConfig.php:601: Error: ADMIN_USER may not be empty. Please update your > configuration. > lib/IniConfig.php:221: Notice: missing config setting for ADMIN_USER > (...repeated 2 times) > lib/IniConfig.php:601: Error: ADMIN_USER may not be empty. Please update your > configuration. > > So, in config.ini, I have ADMIN_USER set, therefore this error message makes > no sense. What should I check instead? > > > > I hope someone can help with either / both of these problems. > > Please let me know if further data on the setup would be helpful. > > > Regards, > > > Antony Stone. > > -- > Most people are aware that the Universe is big. > > - Paul Davies, Professor of Theoretical Physics > > Please reply to the list; > please don't CC me. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > |
From: Antony S. <Ant...@ph...> - 2009-09-06 13:02:35
|
Hi. I'm trying to use PHPwiki on a Debian Etch machine and having problems with authentication. It's Debian Etch (which I can't upgrade to Lenny for unrelated hardware reasons), which gives me PHPwiki version 1.3.12p3-5etch1. I'm using Apache 1.3.34, and MySQL 5.0.32 as the backend database, and it's a fresh install of the phpwiki package, with only the changes noted below. I have two problems: 1. I want to operate this Wiki so that only authorised users can access it (both for reading and for writing) - it's basically a collaborative development tool which needs to be on the Internet to allow access for diversely located people, but we don't want it to be wide open and publicly visible or editable. Therefore I have followed the instructions in config.ini to require passwords for login: ; True User Authentication: ; To require user passwords: ; ALLOW_ANON_USER = false ; ALLOW_ANON_EDIT = false ; ALLOW_BOGO_LOGIN = false, ; ALLOW_USER_PASSWORDS = true. ; Otherwise any anon or bogo user might login without any or a wrong password. I have set all four variable to the required values and restarted Apache, and yet it is still possible to log in with a random username and no password (ie: a Bogo login). How do I get the functionality as documented - True User Authentication? Do I need to reset / reconfigure / restart something else after changing the config.ini file? 2. I cannot create an Admin user and log in as such. If I edit /etc/phpwiki/config.ini and set: ADMIN_USER = Admin ADMIN_PASSWD = Admin (and restart Apache afterwards just in case) then when I go to the URL of my Wiki site, I now get: Fatal Error: lib/IniConfig.php:601: Error: ADMIN_USER may not be empty. Please update your configuration. lib/IniConfig.php:221: Notice: missing config setting for ADMIN_USER (...repeated 2 times) lib/IniConfig.php:601: Error: ADMIN_USER may not be empty. Please update your configuration. So, in config.ini, I have ADMIN_USER set, therefore this error message makes no sense. What should I check instead? I hope someone can help with either / both of these problems. Please let me know if further data on the setup would be helpful. Regards, Antony Stone. -- Most people are aware that the Universe is big. - Paul Davies, Professor of Theoretical Physics Please reply to the list; please don't CC me. |
From: Massimiliano P. <ma...@gm...> - 2009-09-04 08:37:18
|
Hi, I have installed phpwiki 1.3.14 and I want to implement a private wiki where all users need to authenticate before viewing/editing wiki pages. Since I am using flat file as database I would like to employ the "PersonalPage" method for authentication. The relevant part of the config.ini file is: ALLOW_ANON_USER = false ALLOW_ANON_EDIT = false ALLOW_BOGO_LOGIN = false ALLOW_USER_PASSWORDS = true USER_AUTH_ORDER = "PersonalPage" PASSWORD_LENGTH_MINIMUM = 6 USER_AUTH_POLICY = stacked ENABLE_USER_NEW = true Within administration tool I haven't found a "create-user" section, so I create a "Max" page (for user Max) and then chowned it to Max. When I try to login to page "Max" I get the following message: _____ PHP Warning Warning: "PersonalPage login method:" * You stored an empty password in your 'Max' page. * Your access permissions are only for a BogoUser. * Please set a password in UserPreferences. _____ But I cannot access the UserPreferences with user Max. I tried to edit the page metadata and insert the password manually, but the message is the same. What am I doing wrong? You can find my config.ini attached. Php is v5.2.6 on xubuntu. Thank you in advance Massimiliano Pagani http://www.maxpagani.org/ |
From: Reini U. <ru...@x-...> - 2009-08-24 17:53:49
|
2009/8/24 Marc-Etienne Vargenau <Mar...@al...>: > Reini Urban a écrit : >> 2009/8/21 Marc-Etienne Vargenau <Mar...@al...>: >>> As explained, a big change is the implementation of the Wikicreole syntax. >>> >>> Due to this, I would prefer to call the next version 1.4.0 rather than 1.3.15. >>> What do you think? >> >> Hmm, sounds fine to me. The original plans for 1.4 didn't work out. See TODO. >> Full WikiCreole 1.0 support is a big step. > > Great. > >>> The blockers for me are the following: >>> >>> 1) Paging does not work correctly >>> 2) I cannot save preferences in PHP5 >> True, both confirmed. Blockers. > > Reini, can you please look after these blockers? > I tried to solve them, but did not succeeed. I think PHP5 works with the latest commits, but not tested yet. Paging in three days. Tomorrow I took off. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Marc-Etienne V. <Mar...@al...> - 2009-08-24 15:10:09
|
ru...@us... a écrit : > Revision: 7082 > http://phpwiki.svn.sourceforge.net/phpwiki/?rev=7082&view=rev > Author: rurban > Date: 2009-08-24 12:22:05 +0000 (Mon, 24 Aug 2009) > > Log Message: > ----------- > add Markup_mediawikitable_plugin and Markup_wikicreoletable_plugin Hello Reini, I do not agree with this part of the check-in. I do not think it is necessary to put code for Mediawiki and Wikicreole tables in the *inline* parser. It is enough to put them in the *block* parser. I had first implemented the Mediawiki tables in the inline parser but had problems so I moved them into the block parser. I know some entities like plugins have to be in both parsers, but I do not think this is necessary for tables. Best regards, Marc-Etienne Vargenau |
From: Marc-Etienne V. <Mar...@al...> - 2009-08-24 13:07:28
|
Reini Urban a écrit : > 2009/8/21 Marc-Etienne Vargenau <Mar...@al...>: >> As explained, a big change is the implementation of the Wikicreole syntax. >> >> Due to this, I would prefer to call the next version 1.4.0 rather than 1.3.15. >> What do you think? > > Hmm, sounds fine to me. The original plans for 1.4 didn't work out. See TODO. > Full WikiCreole 1.0 support is a big step. Great. >> The blockers for me are the following: >> >> 1) Paging does not work correctly >> 2) I cannot save preferences in PHP5 > True, both confirmed. Blockers. Reini, can you please look after these blockers? I tried to solve them, but did not succeeed. Best regards, Marc-Etienne Vargenau |
From: Reini U. <ru...@x-...> - 2009-08-22 08:37:56
|
2009/8/21 Marc-Etienne Vargenau <Mar...@al...>: > Reini Urban a écrit : >> 2009/8/20 Sabri LABBENE <sab...@st...>: >>> Sabri LABBENE wrote: >>>> Actually we are thinking about possible upgrade of our >>>> phpwiki-1.3.12p2. For sure there is a lot of differences >>>> between the wiki we are running and the one in the repository >>>> today. We need to know what will be changed by doing the >>>> upgrade and whether changes and new features are suitable for >>>> our context or not. >>> If the changelog is not yet ready, maybe it will be useful to list here the main >>> changes that will come with the new version of phpwiki ? >> >> At http://phpwiki.svn.sourceforge.net/viewvc/phpwiki/trunk/pgsrc/ReleaseNotes?view=log >> are the ReleaseNotes, which are pretty accurate. > > Hello, > > I just come back from vacation. > > I have updated the ReleaseNotes file with my latest developments. > > As explained, a big change is the implementation of the Wikicreole syntax. > > Due to this, I would prefer to call the next version 1.4.0 rather than 1.3.15. > What do you think? Hmm, sounds fine to me. The original plans for 1.4 didn't work out. See TODO. Full WikiCreole 1.0 support is a big step. > The blockers for me are the following: > > 1) Paging does not work correctly > > If you do: > <<AllPages info||=mtime,author,hits limit||=10 sortby||=pagename>> > the first page is OK (it lists 10 pages), but clicking on Next > will give an empty page. > > The workaround I use is to put "limit||=10000" but this is ugly. > > 2) I cannot save preferences in PHP5 > > We are still in PHP4, but this will be a big problem when moving > to PHP5. True, both confirmed. Blockers. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Marc-Etienne V. <Mar...@al...> - 2009-08-21 15:31:20
|
Reini Urban a écrit : > 2009/8/20 Sabri LABBENE <sab...@st...>: >> Sabri LABBENE wrote: >>> Actually we are thinking about possible upgrade of our >>> phpwiki-1.3.12p2. For sure there is a lot of differences >>> between the wiki we are running and the one in the repository >>> today. We need to know what will be changed by doing the >>> upgrade and whether changes and new features are suitable for >>> our context or not. >> If the changelog is not yet ready, maybe it will be useful to list here the main >> changes that will come with the new version of phpwiki ? > > At http://phpwiki.svn.sourceforge.net/viewvc/phpwiki/trunk/pgsrc/ReleaseNotes?view=log > are the ReleaseNotes, which are pretty accurate. Hello, I just come back from vacation. I have updated the ReleaseNotes file with my latest developments. As explained, a big change is the implementation of the Wikicreole syntax. Due to this, I would prefer to call the next version 1.4.0 rather than 1.3.15. What do you think? The blockers for me are the following: 1) Paging does not work correctly If you do: <<AllPages info||=mtime,author,hits limit||=10 sortby||=pagename>> the first page is OK (it lists 10 pages), but clicking on Next will give an empty page. The workaround I use is to put "limit||=10000" but this is ugly. 2) I cannot save preferences in PHP5 We are still in PHP4, but this will be a big problem when moving to PHP5. The only files that we have not committed are modifications for Gforge integration, and there are only a few of them. Best regards, Marc-Etienne |