phpwiki-talk

Re: [Phpwiki-talk] [WikiAdminUtils] create-user function updated

[<tho...@la...>]

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

[Phpwiki-talk] =?ISO-2022-JP?B?WyCIyZOhgZuN546XgsyO4Ymcl2yCqoFFgUWBRSBdkm2CwYLEgumQbIK+gq+Tvg==?= =?ISO-2022-JP?B?gvCCt4LpgUmDR4ONg2yDYoNnj+6V8TE4OjE1OjIy?=

[nznyejj <nzn...@hi...>]

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

Re: [Phpwiki-talk] [WikiAdminUtils] create-user function updated

[<tho...@la...>]

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

Re: [Phpwiki-talk] [WikiAdminUtils] create-user function updated

[<tho...@la...>]

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

Re: [Phpwiki-talk] [WikiAdminUtils] create-user function updated

[<tho...@la...>]

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

Re: [Phpwiki-talk] php 4.4.0 & phpwiki 1.3.0

[Reini U. <rei...@gm...>]

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

Re: [Phpwiki-talk] [WikiAdminUtils] create-user function updated

[<tho...@la...>]

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

Re: [Phpwiki-talk] php 4.4.0 & phpwiki 1.3.0

[Matt B. <ma...@ma...>]

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

[Phpwiki-talk] php 4.4.0 & phpwiki 1.3.0

[John K. <jo...@ke...>]

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...

[Phpwiki-talk] sf.net database update

[Reini U. <rei...@gm...>]

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/

[Phpwiki-talk] Re: CreateToc plugin

[Manuel V. <man...@gm...>]

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.

Re: [Phpwiki-talk] A gripe about SQL coding in phpWiki

[John S. <jst...@gm...>]

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

[Phpwiki-talk] Thursday>PENTHOUSE

[M E T P A R T I E S <ma...@me...>]

To view/unsubscribe newsletter please follow this link: http://www.metparties.com/newsletter/ 

Re: [Phpwiki-talk] A gripe about SQL coding in phpWiki

[Reini U. <rei...@gm...>]

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

Re: [Phpwiki-talk] A gripe about SQL coding in phpWiki

[John S. <jst...@gm...>]

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

[Phpwiki-talk] MLB PLAYOFF PACKAGE!

[chewlocka <che...@lo...>]

 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.

Re: [Phpwiki-talk] [WikiAdminUtils] create-user function updated

[Reini U. <rei...@gm...>]

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

Re: [Phpwiki-talk] memory usage

[Reini U. <rei...@gm...>]

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/

Re: [Phpwiki-talk] A gripe about SQL coding in phpWiki

[Reini U. <rei...@gm...>]

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

[Phpwiki-talk] A gripe about SQL coding in phpWiki

[John S. <jst...@gm...>]

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

[Phpwiki-talk] create-user stuff

[<tho...@la...>]

Hello,
Here is a diff for create-user stuff

Only pear backend is updated.

Greetings,
-- 
Thomas Harding

[Phpwiki-talk] memory usage

[Joel U. <uck...@no...>]

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.

[Phpwiki-talk] Re: create-user stuff

[<tho...@la...>]

There is a problem with precedent file,
here is a good one.

Sorry.

-- 
Thomas Harding

[Phpwiki-talk] [WikiAdminUtils] create-user function updated

[<tho...@la...>]

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

[Phpwiki-talk] temp. email change

[Reini U. <ru...@x-...>]

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