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: <tho...@la...> - 2005-10-09 20:39:02
|
On Sun, Oct 09, 2005 at 08:18:24AM +0200, Thomas Harding wrote: > On Sun, Oct 09, 2005 at 08:16:23AM +0200, Thomas Harding wrote: > > There is now a basic check on existing users (hasHomePage), and you can > > either create user or update his passwd. > > > > I think other auth methods than homepage and prefs are out of the scope > > of this tool (external db, pop and others), so it is probably the last > > version. > > > > Note: the template file is on previous message. > > and the diff in this one :/ Well, It worked... sometimes. Don't know how it passed through. Last version for the week-end follows. Regards, -- Thomas Harding |
From: nznyejj <nzn...@hi...> - 2005-10-09 10:15:22
|
DQqBn4SqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE qoGfDQqBQIFAgUCBQIFAiMmToYGbjeeOl4LMjuGJnJdsgqqVc5fPkcyMsYtMgvCMg5SSDQqBn4Sq hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoGfDQph Y3QuMYGZg4GBW4OLgsWDWoNig06DWA0KYWN0LjKBmZNkmGKCxYNag2KDToNYDQphY3QuM4GZie+C wYLEg1qDYoNOg1gNCoLggsGCxo/agrWCrYGEgYSBhCBodHRwOi8vd3d3LnRvdWtvdS5iaXovDQoN CoGhYWN0LjEgg4GBW4OLgsWDWoNig06DWIFAgXWJmIKijL6XdILFjoSC8JDTgt+CxIFJgXYNCoSq hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE qoSqhKqEqoSqhKoNCoGliMmToYGbjeeOl4LMjuGJnJdsgs2SypTMgsWDUoNig1yDio13k/yCtYK9 g3ODk4NOg42BW4NegVuV0I7ogskNCoFAkF6Si4rUgqmC549vie+Cooxug1SDQ4NngsmDQYNOg1qD WIK1gtyCt4FCDQqBQIKojN2CooLMi0OOnYK/gqqNgpdngreC6oLOg4GBW4OLgs2Ct4LFgsmDYIOD g2KDZ4/zkdSBQg0KDQqO4Ymcl2yBdYKigtyBQYONgVuDXoFbgvCDToOKgr+C4YLxgsmJn4K1k5aC xILEgtyCt4FFgUWBRYF2DQoNCpJqkKuBQIF1kmqC3YK9gqKCyZZ1i06CtYLEgumC8YK2guGCyIKi gqmBSIyDgrWCrYKzguqC6YLGg0ODQ4Lxgr6C64KkgUmBSIF2DQoNCo7hiZyXbIF1gruCpILFgreB QZP7jvGC4ILCgtyC8YLFg06DioK/guGC8YLwlMaCtYLEl36CtYKigqGCoYFJgUmBdg0KDQoNCjwx OIvWPpVzl8+ShoLMkGyNyIKqgrGCzInEgsySv1uDYIOTXZHMjLGC8IyDlJKBSQ0KaHR0cDovL3d3 dy50b3Vrb3UuYml6Lw0KDQqBoWFjdC4yIJNkmGKCxYNag2KDToNYgUCBdYLggqSBQYzjlt+C6ILF gquCyIKigvGCxYK3gXYNCoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE qoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKoNCoGljcWPiYLNjHiJ+oK1gsSCooK9juGJnJds guCBQY6plaqCzJKGgsyBeYm9gqmBeoKqibmC8JengsSCxJX2guqOboLfgUENCoFAjMiCzJd+ll2C yY+ZgViCyY54lHqCs4LqgsSCooKrgtyCt4FFgUWBRQ0KgUCTZJhilNSNhoLwkmqQq4LJk2CCpoFB g2WDjIN6g5ODWoNig06DWILJlr6Cr5XpguqC6ZaIk/qBQg0KDQqO4Ymcl2yBdYLggqSDX4OBgsWC t4FBlnuVqILMgUGWe5WogsyDSYGbg5ODYIOTgvCCrYK+grOCooF2DQoNCpJqkKuBQIF1graC4YKg gruCzJFPgsmMZ5HRgvCDfYGbg1KCyYN1g2CNnoLxgsWC3YLrgUmDgYNYk9iBSYFJgXYNCg0KjuGJ nJdsgXWCoIKfgp+Cn4LBgsGCw4FFgUWBRYLNgqKCwYK9gUWBRYFFg0yDZINDgqGCoYFJgUmBdg0K DQoNCjwxOIvWPo7hiZyXbILMkcyMsZJrgqqWno3agsWCtw0KaHR0cDovL3d3dy50b3Vrb3UuYml6 Lw0KDQqBoWFjdC4zIInvgsGCxINag2KDToNYgUCBdY7lkGyCzILmguiBQYNDg0OBSYFJgXYNCoSq hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE qoSqhKqEqoSqhKoNCoGlgsKCooLJkmqQq4LGj2+J74LBgr2IyZOhgZuN546XgsyO4Ymcl2yBQg0K gUCCooLCguCCzONZl+2CyIrnl6eCv4KqiVKCzILmgqSCyYFBjPuC8IpKgq+CxIOIg1+DjILwkIKC 54K1gsSCooLcgreBQg0KgUCCu4LqguCCu4LMgs2CuIFBgqKCqYLCgq2WdYtOgrWCvYNggZuDUoKq k8uCq45ogrOCwYLEgqKC6YKpgueBRYFFgUWBSQ0KDQqO4Ymcl2yBdYK1guOBQY7lkGyCzILmguiC 4INDg0OCxYK3gUmC4IKkibqUvJBngsmXzYKqk/yC54LIgqKBRYFFgUWBdg0KDQqSapCrgUCBdYNJ g4mBQYK7guuCu4Lrj2+Ct4K8gUExj1SK1Jetgt+CxILigsGCvYKpgueCyIFJgXYNCg0KjuGJnJds gXWUWoKigsyCrYK+grOCooFBkoaCyYKigsGCz4Kiko2CooLFgq2CvoKzgqKCwYFJgUmBdg0KDQoN CjwxOIvWPojJk6GBm43njpeCzI7hiZyXbIKql5iXcIK1gr2P6o+Kgs2BRYFFgUUNCmh0dHA6Ly93 d3cudG91a291LmJpei8NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPJBsjciVc5fPTmV3cyBUb3BpY3M+DQqB RZFTjZGO4ZBsjciCs4LxMTAwkGyCzCKI+iKU6ZangsyQq5C2ioiR5Yz2ikqBSQ0KgUWDbINig2eC xYypgsKCr4K9lXOXz5KGkGyNyILMjIOUkg0KgUWSbojmlcqQbI3IlK2MqY/qj4qBdYKmgUmCooKi gsyBSYFIgXaVc5fPkoaQbI3Ij1cNCg0KkN+TeILwjp2CwYLEkeWQbILMitaMV4LwgqiKeYK1gt2C rYK+grOCog0KaHR0cDovL3d3dy50b3Vrb3UuYml6Lw0KhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSq hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqg0KMjU0MjMNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBodHRwOi8vZXRpZGUuNTEubmV0LyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0NCtLUyc/E2sjd08lWb2xsZXlNYWlsw+K30cjtvP63osvNo6y1q8TayN3T61ZvbGxl eU1haWzO3rnYo6zM2LTLyfnD96Oh |
From: <tho...@la...> - 2005-10-09 06:13:21
|
On Sun, Oct 09, 2005 at 08:16:23AM +0200, Thomas Harding wrote: > There is now a basic check on existing users (hasHomePage), and you can > either create user or update his passwd. > > I think other auth methods than homepage and prefs are out of the scope > of this tool (external db, pop and others), so it is probably the last > version. > > Note: the template file is on previous message. and the diff in this one :/ -- Thomas Harding |
From: <tho...@la...> - 2005-10-09 06:11:43
|
On Sat, Oct 08, 2005 at 11:59:08PM +0200, Thomas Harding wrote: > On Fri, Oct 07, 2005 at 11:28:20PM +0200, Thomas Harding wrote: > > On Mon, Oct 03, 2005 at 04:12:26PM +0100, Reini Urban wrote: > > > Sorry, I don't like to have pref code in WikiDB. > > > > > One way is to store it into WikiDB (meta-data attached to the UserPage) > > > [...] > > OK, > This patch touch only WikiUserNew, IniConfig, config-default.ini, > WikiUser/PearDb.php and plugin/WikiAdminUtils.php. There is now a basic check on existing users (hasHomePage), and you can either create user or update his passwd. I think other auth methods than homepage and prefs are out of the scope of this tool (external db, pop and others), so it is probably the last version. Note: the template file is on previous message. Regards, -- Thomas Harding |
From: <tho...@la...> - 2005-10-08 21:54:10
|
On Fri, Oct 07, 2005 at 11:28:20PM +0200, Thomas Harding wrote: > On Mon, Oct 03, 2005 at 04:12:26PM +0100, Reini Urban wrote: > > Sorry, I don't like to have pref code in WikiDB. > > > One way is to store it into WikiDB (meta-data attached to the UserPage) > [...] OK, This patch touch only WikiUserNew, IniConfig, config-default.ini, WikiUser/PearDb.php and plugin/WikiAdminUtils.php. It works only with ENABLE_USER_NEW. It works at least with pref stored in Db (I didn't find the way to store prefs in homepage metadata. Maybe I have to turn off some options in config-default.ini). Q: Why in config-default.ini there is a REPLACE statement, which is Mysql specific? Regards, -- Thomas Harding |
From: Reini U. <rei...@gm...> - 2005-10-08 06:54:33
|
You have to add some flags to error_reporting (in lib/prepend.php) or turn off DEBUG in config.ini. for php4 e.g.: error_reporting(E_ALL & ~E_NOTICE); http://cvs.sourceforge.net/viewcvs.py/phpwiki/phpwiki/lib/prepend.php?view= =3Dauto On 10/6/05, John Kershaw <jo...@ke...> wrote: > I installed a wiki for someone ages ago (2 years?) and it's worked > fine ever since. > > Two days ago their admininstrator upgraded to php 4.4.0 and their > wiki started spewing 50+ 'Notice' error messages at the bottom of > every page! > > Is there a way to fix this? I don't want to upgrade him to the latest > & greatest phpwiki cos he's got an installed user-base of aged > professors who took 2 years to learn wiki syntax and will hit the > roof if he tells them they have to learn it all again! He's happy > with the system he has - is there a quick fix? > > They've reverted back to the previous version of php for now, but his > sysadmin wants to stay current. -- Reini Urban |
From: <tho...@la...> - 2005-10-07 21:24:09
|
On Mon, Oct 03, 2005 at 04:12:26PM +0100, Reini Urban wrote: > Sorry, I don't like to have pref code in WikiDB. > One way is to store it into WikiDB (meta-data attached to the UserPage) OK. Where is exactly stored meta-data 'prefs' ? Users are logged as bogouser when I try the following code : /*************/ require_once ('lib/loadsave.php'); $prefs = array ('userid' => $username,'passwd' => $passwd); $prefs = serialize ($prefs); $template = Template('homepage_byadmin', $request); $text = $template->getExpansion(); $pageinfo = array('prefs' => $prefs, 'versiondata' => array('author' => $username), 'pagedata' => '', 'pagename' => $username, 'content' => $text); SavePage ($request, $pageinfo, false, false); $message = _('User created'); /**************/ -- Thomas Harding |
From: Matt B. <ma...@ma...> - 2005-10-06 20:48:21
|
On Thu, 2005-10-06 at 19:51 +0100, John Kershaw wrote: > Is there a way to fix this? I don't want to upgrade him to the latest > & greatest phpwiki cos he's got an installed user-base of aged > professors who took 2 years to learn wiki syntax and will hit the > roof if he tells them they have to learn it all again! He's happy > with the system he has - is there a quick fix? It is due to a change in how PHP handles reference variables. 1.3.11p1 fixes *most* of these errors, but as you say you don't want to upgrade yet. I use the attached patch in the Debian package for 1.3.10 to suppress these error messages. Use at your own risk as it may also hide other legitimate errors, but in my experience the chance of that is low. I can't guarantee that the patch will apply to anything other than 1.3.10 but it should give you an idea of how to hack around this problem. HTH Regards -- Matt Brown ma...@ma... Mob +64 275 611 544 www.mattb.net.nz |
From: John K. <jo...@ke...> - 2005-10-06 18:52:13
|
Hi, I installed a wiki for someone ages ago (2 years?) and it's worked fine ever since. Two days ago their admininstrator upgraded to php 4.4.0 and their wiki started spewing 50+ 'Notice' error messages at the bottom of every page! Is there a way to fix this? I don't want to upgrade him to the latest & greatest phpwiki cos he's got an installed user-base of aged professors who took 2 years to learn wiki syntax and will hit the roof if he tells them they have to learn it all again! He's happy with the system he has - is there a quick fix? They've reverted back to the previous version of php for now, but his sysadmin wants to stay current. Any ideas? John. -- ------------------------------------------------------------------- T:01274 581519 / M:07944 755613 www.kershaw.org jo...@ke... skype:johnmkershaw AIM:johnkershaw MSN:joh...@ho... |
From: Reini U. <rei...@gm...> - 2005-10-06 17:29:42
|
The sf.net site for phpwiki was upgraded to the new mysql 4.1 database serv= ices. For the start we keep everything as latin1_bin, but a new database for utf8 was also created and I'll try to switch the demo wiki to utf-8 soo= n. Edit's in the last hour will be lost. -- Reini Urban http://phpwiki.org/ |
From: Manuel V. <man...@gm...> - 2005-10-06 08:58:39
|
2005/9/29, Manuel Vacelet <man...@gm...>: > Hello, > > I modified the CreateToc wiki again because it was produsing lot's of > errors (with double quote, with wiki text, ...). I made a patch against v 1.3.11-p1 (I guess it's the same than CVS): http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1314668&group_= id=3D6121&atid=3D306121 Some examples of toc issues are viewable here: http://phpwiki.sourceforge.net/phpwiki/CreateTocIssuesExample One problem remain with 'http' addresses and I have -yet- no ideas to fix i= t. |
From: John S. <jst...@gm...> - 2005-10-04 23:54:13
|
Hi Reini and all, > > Well, I wouldn't disqualifying the search library as lazy, more as > overkill. Firstly, I apologise for (in hindsight) using a derogatory term. I did not mean any personal slights to anyone involved in the phpwiki development. However, there is a LOT of SQL in the coding that is in the backends that uses WHERE 1=3D1/NULL=3DNULL/1/TRUE, and it just shouldn't exist. It usuall= y exists because the programmer thinks the can start a string variable with "WHERE TRUE" and then add to it by appending to it " AND fieldn=3D$variable= " without any bounds checking on the variable, or even seeing if there are an= y variables that need to be included in a WHERE clause. See the bottom of the JohnStevens page of the phpwiki. This is Disastrous for an abstraction layer. People are developing SQL implementation specific SQL lower down tha= n the abstraction layer where it should be, but not within a particular implementation specific module. As I found out, most things work, but other stuff doesn't and causes problems. I re-iterate, there should NEVER be a WHERE TRUE clause. There should only ever be a WHERE field=3DTRUE. If an implementation of SQL requires there always be a WHERE clause, and at a minimum it must be WHERE TRUE, then it should be a part of that implementations interface module, NOT part of an abstraction layer. Unfortunately we need such a beast. Absoultely! But it should be a true abstraction layer, not reliant on any backend code or DB implementation specific coding, nor should it generate any. That should be done totally by the backend modules. They should also b= e as cross compliant as possible with only really implementation specific stuff in them. The problem you have is with the optimizer step, which folds TRUE to > 1=3D1 and doesn't eliminate unnecessary statements. See above. If there are no conditionals the optimiser needs to add to a WHERE clause, then it shouldn't produce one, unless the backend implementation requires it (doubtful). Leaving a WHERE TRUE clause on the end of a SQL is a waste and totally unecessary. The optimiser should remove all unnecessary SQL code before passing it on the the backend. BTW: Now I do have oracle, but didn't set it up yet. We are basically SOE oracle 9i and moving to clustered RAC 10 (I am not the DBA so I think that is spelled right ;)). We have a full 9i/apache/php dev environment that I am currently running our internal wiki on. If you need help with testing, let me know. I can easily set up an instance of any new wiki for testing. Others can easily follow. Rapid involvement is not easy, but there are > lot of people who can write plugins or contribute to various parts, > based on the code and comments. Again this wasn't meant as a personal criticism. I have been in development and adminstration of operating systems and software for 25+years. Comments in code should give a clear idea of what is going on. There are some really well commented modules, and others that are less then well commented, which often happens in collaborative projects. I have always run by the principle= , that whatever I develop, I will have to return to it in 5-10 years cold, so I better be able to understand what is going on. That way, anyone coming in cold can do the same. Yes, these days people do not run by the same principle, but they should. Particularly in Open Source development projects. Also, a good overview of what you are building and how it all fit= s together is the foundation of any engineering project, software or otherwise. It sure would help anyone wanting to contribute time and effort to this project get up to speed and ensure that what they develop will work without upsetting the applecart by creating implementation specific code in a place where it shouldn't be. ;) It would have saved me some days of trawling through modules figuring out where exactly problems lie with me getting Oracle working well. ;)) http://phpwiki.org/ should be the central place, besides the basic > docs in pgsrc/ > > Any advice on how to make the dump to XHTML exclude unwanted pages etc? > > exclude=3D<commasep-pagename-list> is a standard argument for all > actions and plugins using pagelists. > > e.g. ?action=3Ddumphtml&exclude=3DNotThese/*,*Private > action=3Ddumphtml also accepts pages=3D[] to dump only a set of certain p= ages. > > Thanks for this. I will check these out and try them. Again, aside form the initial frustrated rant, which was actually meant to improve an already good open source project, I am very happy with what you all have accomplished so far. My frustration comes from wanting it to be better, and wanting to be a part of the solution rather than the problem. phpwiki is suffering a little from people thinking in isolation, and not being able to test against all likely or documented configurations prior to release. I would like to see these areas improved. I am not on a crusade or attack;) If I have come across that way, I sincerely apologise. Regards |
From: M E T P A R T I E S <ma...@me...> - 2005-10-04 08:53:07
|
To view/unsubscribe newsletter please follow this link: http://www.metparties.com/newsletter/ |
From: Reini U. <rei...@gm...> - 2005-10-04 06:37:15
|
On 10/4/05, John Stevens <jst...@gm...> wrote: > On 10/3/05, Reini Urban <rei...@gm...> wrote: > > Interesting. Never heard of a system where setlocale("C") fails. > > Please post details to the phpwiki bug tracker. C is the mother of all > locales. > > I'll send this to the bugtracker later, but for now, here are the detail= s > of the error we see. > Fatal Error: lib/FileFinder.php (In template 'body' < 'htmldump'):191: > Error: locale/C/LC_MESSAGES/phpwiki.php: ???????????? > > Not exatly a helpful message. It is looking for the file > [wikihome]locale/C/LC_MESSAGES/phpwiki.php. Problem is > there is no locale/C or any subdirectories, either on my machine or in th= e > 1.3.11p1 archive. This is a useful error message. Thanks. I'll fix it ASAP. > > If you dig into the sources, you will see that those TRUE statements (a= lso > 1=3D1) > > come from the search library, which is a pretty good library IMHO. > > I must disagree with this assessment. There should be no reason to do a > TRUE statement like 1 or 1=3D1 or NULL=3DNULL in any SQL. It is simply a= way of > preformatting a WHERE clause so you can just keep tacking AND condition > statments to it, if there is a reason to. It is lazy programming. You > should only create a WHERE clause if there are conditions that you need t= o > limit a query to. If you dont, then SELECT column1,column2 FROM tablex; = is > all you need. Not SELECT column1,column2 FROM tablex WHERE 1=3D1; > That is just lazy programming. Well, I wouldn't disqualifying the search library as lazy, more as overkill. Unfortunately we need such a beast. It's a search string string expression parser and compiler. It compiles to either pcre expressions or SQL statements. On the SQL side dependend on the backend supported syntax. In style similar to a perl (not-yet existing) SQL::Search library which would use the great SQL::Abstract. The problem you have is with the optimizer step, which folds TRUE to 1=3D1 and doesn't eliminate unnecessary statements. We thought that this is not necessary since the SQL parser eliminates these in his side. I didn't think of oracle, since I couldn't test it (yet). ("Premature optimization is evil") BTW: Now I do have oracle, but didn't set it up yet. > > You miss coding documentation? I cannot agree. > > I am willing to be proven wrong ;) Can you point me in a direction to f= ind > it? Thanks. Comments in the code are insufficient for someone not > intimately invovled in the development to get a rapid handle on how it al= l > hangs together. Others can easily follow. Rapid involvement is not easy, but there are lot of people who can write plugins or contribute to various parts, based on the code and comments. > > I would agree that you miss updated user documentation for such feature= s. > > Is there are place I can find this also? http://phpwiki.org/ should be the central place, besides the basic docs in pgsrc/ > Any advice on how to make the dump to XHTML exclude unwanted pages etc? exclude=3D<commasep-pagename-list> is a standard argument for all actions and plugins using pagelists. e.g. ?action=3Ddumphtml&exclude=3DNotThese/*,*Private action=3Ddumphtml also accepts pages=3D[] to dump only a set of certain pag= es. -- Reini Urban |
From: John S. <jst...@gm...> - 2005-10-03 23:14:34
|
Hi Reini and All, On 10/3/05, Reini Urban <rei...@gm...> wrote: > > > I like rants. Thanks! So do I, they usually provide useful information;) > > Interesting. Never heard of a system where setlocale("C") fails. > Please post details to the phpwiki bug tracker. C is the mother of all > locales. I'll send this to the bugtracker later, but for now, here are the details o= f the error we see. Fatal Error: lib/FileFinder.php (In template 'body' < 'htmldump'):191: Error: locale/C/LC_MESSAGES/phpwiki.php: ???????????? Not exatly a helpful message. It is looking for the file [wikihome]locale/C/LC_MESSAGES/phpwiki.php. Problem is there is no locale/C or any subdirectories, either on my machine or in the 1.3.11p1 archive. If you dig into the sources, you will see that those TRUE statements (also > 1=3D1) > come from the search library, which is a pretty good library IMHO. I must disagree with this assessment. There should be no reason to do a TRU= E statement like 1 or 1=3D1 or NULL=3DNULL in any SQL. It is simply a way of preformatting a WHERE clause so you can just keep tacking AND condition statments to it, if there is a reason to. It is lazy programming. You shoul= d only create a WHERE clause if there are conditions that you need to limit a query to. If you dont, then SELECT column1,column2 FROM tablex; is all you need. Not SELECT column1,column2 FROM tablex WHERE 1=3D1; That is just lazy programming. We can easily set another SQL TRUE statement for this branch, and we > haven't wrote a branch optimizer yet. > Recommendations welcome. > I'm just improving the postgresql interface, and oracle is not very far > away. > (foreign keys and text search improvements) While I cannot work out where I can contribute to this, I am looking forwar= d to a much better Oracle implementation and will be keen to try it out. You miss coding documentation? I cannot agree. I am willing to be proven wrong ;) Can you point me in a direction to find it? Thanks. Comments in the code are insufficient for someone not intimatel= y invovled in the development to get a rapid handle on how it all hangs together. I would agree that you miss updated user documentation for such features. Is there are place I can find this also? I'll look these up. Thanks for your patches. Find them on the JohnStevens page. http://www.phpwiki.org/JohnStevens For the future: > Patches go to patches, bugs to bugs, feature enhancements to RFE. > ("Requested Feature Enhancements") > All at the sf.net <http://sf.net> projects page. Thanks. Will remember that next time.;) $ cd my-oracle-wiki > $ patch -N -b -p1 < ../official-wiki.patch > $ find -name \*.rej | xargs emacs > > looks not much of an overhead to me. > I have about 5 different wiki's to sync, with various features to test, > and it's very painless. Painless if I haven't made a lot of changes to your source. I need to remak= e my changes by hand once I have your code patched or have an updated release= . If my changes are part of the release.......... Anyway, thanks for the response and guidance. Hope we can work on this together. A great project that can be improved just a little. Any advice on how to make the dump to XHTML exclude unwanted pages etc? Regards |
From: chewlocka <che...@lo...> - 2005-10-03 17:23:48
|
The baseball playoffs are here and at Lock and Win that means BIG MONEY! As our loyal fans know from past years we give out MLB playoff plays as our DAILY LOCK throughout the playoffs here and there but thats only for one game, if you want every pick from every game we can give it to you all here with one LOW PRICE! Thats right you get one pick from every MLB Playoff game that is played throughout the WORLD SERIES! The only people who have access to these plays are our yearly members as they get every play we release all year long! But don't worry you can get these plays too for one low price if you buy our MLB PLAYOFF PACKAGE! Sign up today and let the winning starts on Tuesday and continue all through October! www.lockandwin.com DISCLAIMER: This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message immediately. |
From: Reini U. <rei...@gm...> - 2005-10-03 15:12:35
|
Sorry, I don't like to have pref code in WikiDB. WikiDB is for pages and revisions only, user prefs and account data can be stored in various ways. One way is to store it into WikiDB (meta-data attached to the UserPage) Other ways are: storing it into seperate SQL tables, external databases and so on. The correct way to implement the create_user backend, would be a method in WikiUserNew.php and it's backends and NOT in WikiDB and its backends. From 1.3.12 on the user table will be deprecated, pref and member for wiki is enough. (schemas already in CVS) user is confusing, the user table should be used as example how to access external databases to synch phpwiki user account info to other packages. On 10/2/05, Thomas Harding <tho...@la...> wrote: > For those who have already applied the precedent patch, find files in > attachment. > for others, there is the cvs diff (diff_02_09). -- Reini Urban |
From: Reini U. <rei...@gm...> - 2005-10-03 07:14:28
|
Oops, sorry. In the meantime I've added caching of these memory intensive plugin, pages, templates and category popups (not yet committed), but I really want this to use the new xml-rpc interface on-the-fly, only when requested. As in hyperwiki applet in the Sidebar theme. Please turn off the various TOOLBAR_*_PULLDOWN options in config.ini On 10/1/05, Joel Uckelman <uck...@no...> wrote: > As of the the recent changes to EditToolbar.php, the memory requirements > for the edit page have increased significantly, at least on my system: I > used to be able to do everything but load a virgin wiki using under 8MB, > but now the edit page won't load for me without the memory limit set to > 13MB. > > It worries me that basic functionality no longer works under the default > memory limit for PHP (which is 8MB). -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Reini U. <rei...@gm...> - 2005-10-03 07:05:11
|
On 10/3/05, John Stevens <jst...@gm...> wrote: > <RANT> I like rants. Thanks! > I hate to be a pain about this, and I know I am limited by an enterprise > decision to use Oracle for all SQL backends, but I find the SQL coding an= d > the lack of any real developer documentation a HUGE downside to this wiki= . > I decided to implement it at my employer as I am a great advocate of Wiki > for all types of collaborative documentation, and it suits the PHP/Oracle > SOE here. The basic Wiki runs fine, and people are beginning to use it a= nd > take it up. > > The problem nows becomes, how do we make this stuff available off-line? > Well, just dump out to html right? Wrong. Firstly there are errors wher= e > the FileFinder.php where it sets the locale to C, and no such locale exis= ts. Interesting. Never heard of a system where setlocale("C") fails. Please post details to the phpwiki bug tracker. C is the mother of all loca= les. > This occurs for a lot of "plugin" pages. Then if you are are able to ge= t > around that one, there is the small problem really bad SQL programming. = I > mean "WHERE NULL =3D NULL" and "WHERE 1" which causes Oracle to barf. Pr= etty > bad programming style when these are used to simply let a lazy programmer > append " AND something=3D$somvariable" to a conditional clause, rather th= an do > some testing of variables and processing them accordingly. And if you ar= e > going to do it the lazy way, shouldn't you be doing it in a non SQL > implementation specific way? Come on! If you dig into the sources, you will see that those TRUE statements (also = 1=3D1) come from the search library, which is a pretty good library IMHO. We can easily set another SQL TRUE statement for this branch, and we haven't wrote a branch optimizer yet. Recommendations welcome. I'm just improving the postgresql interface, and oracle is not very far awa= y. (foreign keys and text search improvements) > And searching throuth the code, there seems to be ways to include a list= of > "excluded pages" but since the coding documentation is basically > non-existent this is impossible to fathom. And the lack of documentation > explaining an easy way to do it would also be helpful. I mean, isn't thi= s > really what wiki is about? You miss coding documentation? I cannot agree. I would agree that you miss updated user documentation for such features. > Oracle did not work out of the box, and I posted my changes on the phpWi= ki > Wiki. Have these been included in the latest releases and patches? No. = Is > there any easy way to find out how to contribute to this project? I'll look these up. Thanks for your patches. For the future: Patches go to patches, bugs to bugs, feature enhancements to RFE. ("Requested Feature Enhancements") All at the sf.net projects page. > Well, I must be blind 'cause I haven't found much detail on that either. = So what > happens if you guys release patches? I have to trawl through the code ea= ch > time and make the same changes to make my oracle implementation work. A > real pain for me, but if I want a Wiki at work (and god knows we need one= ) > this is what I have to do. Such an overhead will ensure that Wiki will d= ie > here. $ cd my-oracle-wiki $ patch -N -b -p1 < ../official-wiki.patch $ find -name \*.rej | xargs emacs looks not much of an overhead to me. I have about 5 different wiki's to sync, with various features to test, and it's very painless. > I am more than willing to contribute to the development of the Oracle pa= rt > of the wiki. We have resources to run testing here. But I need a wiki t= hat > will work and will be well maintained, with cross backend code and non-la= zy > programming and documentation, particularly in the code. This lack is > probably limiting the development, debugging and maintainability of this > project and it should be rectified. > </RANT> -- Reini Urban http://phpwiki.org |
From: John S. <jst...@gm...> - 2005-10-03 03:44:35
|
Hi All, <RANT> I hate to be a pain about this, and I know I am limited by an enterprise decision to use Oracle for all SQL backends, but I find the SQL coding and the lack of any real developer documentation a HUGE downside to this wiki. = I decided to implement it at my employer as I am a great advocate of Wiki for all types of collaborative documentation, and it suits the PHP/Oracle SOE here. The basic Wiki runs fine, and people are beginning to use it and take it up. The problem nows becomes, how do we make this stuff available off-line? Well, just dump out to html right? Wrong. Firstly there are errors where th= e FileFinder.php where it sets the locale to C, and no such locale exists. This occurs for a lot of "plugin" pages. Then if you are are able to get around that one, there is the small problem really bad SQL programming. I mean "WHERE NULL =3D NULL" and "WHERE 1" which causes Oracle to barf. Prett= y bad programming style when these are used to simply let a lazy programmer append " AND something=3D$somvariable" to a conditional clause, rather than= do some testing of variables and processing them accordingly. And if you are going to do it the lazy way, shouldn't you be doing it in a non SQL implementation specific way? Come on! And searching throuth the code, there seems to be ways to include a list of "excluded pages" but since the coding documentation is basically non-existent this is impossible to fathom. And the lack of documentation explaining an easy way to do it would also be helpful. I mean, isn't this really what wiki is about? Oracle did not work out of the box, and I posted my changes on the phpWiki Wiki. Have these been included in the latest releases and patches? No. Is there any easy way to find out how to contribute to this project? Well, I must be blind 'cause I haven't found much detail on that either. So what happens if you guys release patches? I have to trawl through the code each time and make the same changes to make my oracle implementation work. A rea= l pain for me, but if I want a Wiki at work (and god knows we need one) this is what I have to do. Such an overhead will ensure that Wiki will die here. I am more than willing to contribute to the development of the Oracle part of the wiki. We have resources to run testing here. But I need a wiki that will work and will be well maintained, with cross backend code and non-lazy programming and documentation, particularly in the code. This lack is probably limiting the development, debugging and maintainability of this project and it should be rectified. </RANT> Regards John |
From: <tho...@la...> - 2005-10-02 23:25:27
|
Hello, Here is a diff for create-user stuff Only pear backend is updated. Greetings, -- Thomas Harding |
From: Joel U. <uck...@no...> - 2005-10-02 22:48:19
|
As of the the recent changes to EditToolbar.php, the memory requirements for the edit page have increased significantly, at least on my system: I used to be able to do everything but load a virgin wiki using under 8MB, but now the edit page won't load for me without the memory limit set to 13MB. It worries me that basic functionality no longer works under the default memory limit for PHP (which is 8MB). -- J. |
From: <tho...@la...> - 2005-10-02 21:37:51
|
There is a problem with precedent file, here is a good one. Sorry. -- Thomas Harding |
From: <tho...@la...> - 2005-10-02 19:10:24
|
For those who have already applied the precedent patch, find files in attachment. for others, there is the cvs diff (diff_02_09). Greetings, -- Thomas Harding |
From: Reini U. <ru...@x-...> - 2005-09-29 19:39:53
|
The nameserver of my main domain x-ray.at was shutdown, and my domain does not response so far, so please use my temp. email <rei...@gm...> until this is fixed. My list subscriptions are already fixed. PS: I was the responsible person at this provider for nameserver administration some years ago, and I would have never done done such a stupid mistake. -- Reini Urban |