phpwiki-talk

[Phpwiki-talk] Greetings: pnPhpWiki

[electron <ele...@mg...>]

Hello!


My name is Jason. I run phpWiki as a postnuke module @ =
http://www.gs4.org.

I am in the process of updating lakka's PN module to 1.3.8pre.  Devel:
http://www.gs4.org/dev . I'll eventually add it to noc.postnuke.com if =
they
get their Gforge software in order. Maybe this can be a subproject of
PhpWiki?

Gripes:=20

1.) diff.php and diff3.php do not use the template system. This causes =
me to
have to make some dirty hacks to those files. I may fix it as soon as I =
move
pnPhpWiki to a post-alpha stage.

2.) WikiUserNew.php gives me a real headache. Can this be better =
documented
about who/what/when stuff gets called. For now I hacked WikiUser.php to =
use
postnuke permissions. It works, but I figure WikiUserNew is the future?

Squish:

1.) Added a patch to SourceForge to add a default limit for adodb and
recentchanges. If limit isn't set it was just returning one item which =
is
hardly useful.


I'll lurk on SourceForge forums for a while and watch this list as well. =
I'm
a big fan of adodb (what postnuke uses as well) and I'll see what we can =
do
to migrate phpWiki off FETCH_ASSOC. Another note: The SourceForge
pages/forums/etc. need cleaning, do you need a volunteer?

-Jason Potkanski/Electrawn




I've stopped 7,338 spam messages. You can too!
One month FREE spam protection at www.cloudmark.com

Re: [Phpwiki-talk] Greetings: pnPhpWiki

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

electron schrieb:
> My name is Jason. I run phpWiki as a postnuke module @ http://www.gs4.org.
> 
> I am in the process of updating lakka's PN module to 1.3.8pre.  Devel:
> http://www.gs4.org/dev . I'll eventually add it to noc.postnuke.com if they
> get their Gforge software in order. Maybe this can be a subproject of
> PhpWiki?

Fine, I tried this yesterday, but didn't finish it. (phpnuke-7.0, 
postnuke is much better, but i wanted to start with the worst)
I did the guiki-phpnuke module instead. much easier and looks better.

Note that with &frame=body argument hack you can display just the body 
(or any other template) and not the head, or better fix the head.tmpl.

> 1.) diff.php and diff3.php do not use the template system. This causes me to
> have to make some dirty hacks to those files. I may fix it as soon as I move
> pnPhpWiki to a post-alpha stage.

thanks.

> 2.) WikiUserNew.php gives me a real headache. Can this be better documented
> about who/what/when stuff gets called. For now I hacked WikiUser.php to use
> postnuke permissions. It works, but I figure WikiUserNew is the future?

Hmm, what's the problem? It doesn't do any output.
The real problem are the template and WikiLink and WikiUrl fixes.

For strict db auth against the nuke db set USER_AUTH_POLICY to "first-only"
and the $USER_AUTH_ORDER array to "Db" only.

> Squish:
> 1.) Added a patch to SourceForge to add a default limit for adodb and
> recentchanges. If limit isn't set it was just returning one item which is
> hardly useful.

haven't I fixed this adodb limit bug recently in CVS?
anyway I added it, since it makes sense.

> I'll lurk on SourceForge forums for a while and watch this list as well. I'm
> a big fan of adodb (what postnuke uses as well) and I'll see what we can do
> to migrate phpWiki off FETCH_ASSOC. Another note: The SourceForge
> pages/forums/etc. need cleaning, do you need a volunteer?

Agreed, FETCH_ASSOC is really annoying for the auth_sql staements.
I'd prefer MYSQL_NUM. Or do you need FETCH_BOTH?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Greetings: pnPhpWiki

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

Reini Urban schrieb:
> haven't I fixed this adodb limit bug recently in CVS?
> anyway I added it, since it makes sense.

I didn't add it since it makes no sense. my adodb fix from last months 
fixed the limit problem.

RE: [Phpwiki-talk] Greetings: pnPhpWiki

[electron <ele...@mg...>]

Reini Urban schrieb:
> haven't I fixed this adodb limit bug recently in CVS?
> anyway I added it, since it makes sense.

I didn't add it since it makes no sense. my adodb fix from last months=20
fixed the limit problem.


----

I still get it inside pnPhpWiki. I'm on Version 1.12 of adodb.php. Error
still pops up using either ADODB backend or pnADODB backend (custom =
backend
that uses postnuke calls to adodb)

I made an alpha release at http://noc.postnuke.com/projects/pnphpwiki/ =
which
will reproduce the behavior if the patch isn't used.

On a separate note: All you postnuke folks can d/l an alpha version of
pnPhpWiki @ the above url.

Divergent path:

In playing with pnPhpWiki, PageHistory caused some intresting behavior =
with
the way it uses urls.

Proposal: in stdlib, a useForm() or WikiForm() function be created that =
acts
as a wrapper to HTML::<form>? I suggest this because of the need that =
all
pages when phpwiki is run as a module need additional arguments (op,
modload, etc) and when HTML::form is called in PageHistory, those =
postnuke
required args should be hidden input elements, but are not.

The dirty solution is to hack PageHistory.php, the clean one is to
encapsulate.

Also: in stdlib, a getDefaultArg() function that is called by WikiUrl() =
and
proposed WikiForm()

In standard phpwiki, this would return nothing, hackers like myself can =
dump
my postnuke vars in there and have it work sitewide.

Thoughts?

-Jtp

Re: [Phpwiki-talk] Greetings: pnPhpWiki

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

electron schrieb:
> Reini Urban schrieb:
>>haven't I fixed this adodb limit bug recently in CVS?
>>anyway I added it, since it makes sense.
> 
> I didn't add it since it makes no sense. my adodb fix from last months 
> fixed the limit problem.
--
I fixed it in WikiDB/backend/ADODB.php:600
Id: ADODB.php,v 1.13 2004/02/12 14:11:35 rurban Exp

> I still get it inside pnPhpWiki. I'm on Version 1.12 of adodb.php. Error
> still pops up using either ADODB backend or pnADODB backend (custom backend
> that uses postnuke calls to adodb)

bad, bad, since I cannot reproduce it now. Jeff wanted the RecentChanges 
feature to not enable a limit per default. cannot you fix it elsewhere? 
in the adodb backend?

> I made an alpha release at http://noc.postnuke.com/projects/pnphpwiki/ which
> will reproduce the behavior if the patch isn't used.

ok, I'l try this.

> Divergent path:
> In playing with pnPhpWiki, PageHistory caused some intresting behavior with
> the way it uses urls.
> 
> Proposal: in stdlib, a useForm() or WikiForm() function be created that acts
> as a wrapper to HTML::<form>? I suggest this because of the need that all
> pages when phpwiki is run as a module need additional arguments (op,
> modload, etc) and when HTML::form is called in PageHistory, those postnuke
> required args should be hidden input elements, but are not.

a wrapper just for every form is hard. cannot you add a helper call to 
every POST form?

> The dirty solution is to hack PageHistory.php, the clean one is to
> encapsulate.
> 
> Also: in stdlib, a getDefaultArg() function that is called by WikiUrl() and
> proposed WikiForm()
> In standard phpwiki, this would return nothing, hackers like myself can dump
> my postnuke vars in there and have it work sitewide.

looks okay to me, since I need zend studio start_debug=1 also in all GET 
calls and for POST forms as hidden inputs.
but I think I already added such a url helper to stdlib. just cannot 
find it yet.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/