phpwiki-talk

[Phpwiki-talk] phpwiki.sf.net/phpwiki switched to 1.3.11_rc3

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

I've switched our default wiki to the new codebase.
   http://phpwiki.sourceforge.net/phpwiki/
aliased under http://phpwiki.sourceforge.net/phpwiki11/

The old is under
   http://phpwiki.sourceforge.net/phpwiki10/

The automatic demo update cronjob is working again.
They switched the CVS servernames from "cvs1" back to "cvs", that's why 
it failed.
Just the nightly snapshot is missing now.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

Re: [Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

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

Philip J. Hollenback schrieb:

> Hi guys,
> 
> Just a note to say that I have upgraded www.hollenback.net to 1.3.11_rc3
> (previously 1.3.1 cvs November 2004) and it seems to be coming along
> nicely.  A few notes:
> 
> 1. When I initially attempted the upgrade with
> 
> http://www.hollenback.net/index.php?action=upgrade
> 
> it failed with trhis message:
> 
>  Cannot redeclare _http_user() (previously declared in
>  /home/phil/public_html/configurator.php:71) in
>  /home/phil/public_html/configurator.php on line 70
> 
> Once I removed configurator.php it worked fine.  Maybe add that to the
> upgrade notes or something?

I thought I've already fixed that. Sorry.

> 2.  Thanks a bunch for the 'overwrite all' in the upgrade page.  Makes
> the process much easier.  However, maybe that should be explained a bit
> more?  Right now it doesn't exactly pop up off the page.

Hmm. You got an idea?

> 3. Crao nav bar is messed up in Forefox/Mac OS X.  Specifically, the
> 'prefs / admin / search' buttons and box on the right side are stacked
> vertically instead of spread in a horizontal line like they should be.
> I don't see this behavior with Safari.
> 
> 4. I could be imagining things, but the floating ttolbar on the bottom
> of the Crao theme now slows down page scrolling significantly.  I don't
> think it used to.

That's entirely a browser issue. Unfortunately the developer of this 
theme cannot check against MSIE.

> Basically everything else looks good so far.  I will be posting bur
> reports on sourceforge for the problems I listed above and for a few
> others.  I just wanted to let the developers know that at least one
> person is trying these rc releases for 1.3.11.
> 
> The fun part will be re-enabling edits on my page and seeing how the
> spam prevention stuff works.

Thanks for all your reports at the sf.net tracker.
This will need some time to be fixed.

Schorni had also some more issues with the RichTable plugin in the last 
cell.
And a third user, Likai Liu, reported some php5 issues, which are easy 
to fix.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

[Phpwiki-talk] I've upgraded www.hollenback.net to 1.3.11-rc3 and it looks good

[Philip J. H. <ph...@po...>]

Hi guys,

Just a note to say that I have upgraded www.hollenback.net to 1.3.11_rc3
(previously 1.3.1 cvs November 2004) and it seems to be coming along
nicely.  A few notes:

1. When I initially attempted the upgrade with

http://www.hollenback.net/index.php?action=upgrade

it failed with trhis message:

 Cannot redeclare _http_user() (previously declared in
 /home/phil/public_html/configurator.php:71) in
 /home/phil/public_html/configurator.php on line 70

Once I removed configurator.php it worked fine.  Maybe add that to the
upgrade notes or something?

2.  Thanks a bunch for the 'overwrite all' in the upgrade page.  Makes
the process much easier.  However, maybe that should be explained a bit
more?  Right now it doesn't exactly pop up off the page.

3. Crao nav bar is messed up in Forefox/Mac OS X.  Specifically, the
'prefs / admin / search' buttons and box on the right side are stacked
vertically instead of spread in a horizontal line like they should be.
I don't see this behavior with Safari.

4. I could be imagining things, but the floating ttolbar on the bottom
of the Crao theme now slows down page scrolling significantly.  I don't
think it used to.

Basically everything else looks good so far.  I will be posting bur
reports on sourceforge for the problems I listed above and for a few
others.  I just wanted to let the developers know that at least one
person is trying these rc releases for 1.3.11.

The fun part will be re-enabling edits on my page and seeing how the
spam prevention stuff works.

Thanks,
P.

-- 
Philip J. Hollenback
www.hollenback.net

[Phpwiki-talk] Release Candidate 3 available

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

http://sourceforge.net/project/shownotes.php?release_id=319077

Fixes since rc2:
   recursive PageList azhead+cols listing
   RichTablePlugin embedded plugin invocation and more formatting issues
   empty SESSION_SAVE_PATH
   Template("theme/name") inclusion
   "smaller" theme IE aesthetics
   postgresql schema, thanks to Marius Andreiana
   add _SERVER[REMOTE_USER] check for pubcookie et al
   add ENABLE_DISCUSSION_LINK dependency (to turn it off for 1.3.11)
   fix WIKIDB_NOCACHE_MARKUP (bug #1175761)
   fix email regex for RFC822 addresses (Joel Uckelman)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

Re: [Phpwiki-talk] ENCRYPTED_PASSWORD default, bug 1175782

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

Dan Frankowski schrieb:

> Joel Uckelman wrote:
> 
>> Thus spake Reini Urban:
>>  
>>
>>> Joel Uckelman schrieb:
>>>   
>>>
>>>> The comment which describes ENCRYPTED_PASSWD in 
>>>> config/config-dist.ini is
>>>> at variance with the actual setting:
>>>>
>>>> ; It is recommended that you use the passencrypt.php utility to 
>>>> encode the
>>>> ; admin password, in the event that someone gains ftp or ssh access 
>>>> to the
>>>> ; server and directory containing phpwiki. Once you have pasted the
>>>> ; encrypted password into ADMIN_PASSWD, uncomment this next line.
>>>> ENCRYPTED_PASSWD = true
>>>>
>>>> 1) The last line isn't commented by default, contrary to the comment.
>>>> 2) It wouldn't matter if it were commented, since ENCRYPTED_PASSWD = 
>>>> true
>>>> in config/config-default.ini anyway.
>>>>
>>>> What's the correct behavior here? Do we want it to work as described 
>>>> in the comment (in which case the last line should read
>>>>
>>>>   ENCRYPTED_PASSWD = false
>>>>
>>>> and the comment should say to set it to true) or do we want encrypted
>>>> passwords to be on by default, as the setting in 
>>>> config/config-default.ini
>>>> would indicate?
>>>>     
>>>
>>> I would say leave encrypted as default and change the wording in 
>>> config/config-dist.ini.
>>> The configurator creates encrypted passwords per default.
>>>   
>>
>>
>> Yeah, that's how I was leaning as well. We don't want people using 
>> plain-text passwords unless they have some good reason for it.
>>  
>>
> 
> If that is the case, why have a configurable option for it? Better to 
> have a single path that is well documented, accepted by all, easy to 
> use, than multiple paths which need to be explained and understood.

Legacy. Unencrypted was default until 1.3.11

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

Re: [Phpwiki-talk] ENCRYPTED_PASSWORD default, bug 1175782

[Dan F. <dfr...@cs...>]

Joel Uckelman wrote:

>Thus spake Reini Urban:
>  
>
>>Joel Uckelman schrieb:
>>    
>>
>>>The comment which describes ENCRYPTED_PASSWD in config/config-dist.ini is
>>>at variance with the actual setting:
>>>
>>>; It is recommended that you use the passencrypt.php utility to encode the
>>>; admin password, in the event that someone gains ftp or ssh access to the
>>>; server and directory containing phpwiki. Once you have pasted the
>>>; encrypted password into ADMIN_PASSWD, uncomment this next line.
>>>ENCRYPTED_PASSWD = true
>>>
>>>1) The last line isn't commented by default, contrary to the comment.
>>>2) It wouldn't matter if it were commented, since ENCRYPTED_PASSWD = true
>>>in config/config-default.ini anyway.
>>>
>>>What's the correct behavior here? Do we want it to work as described in 
>>>the comment (in which case the last line should read
>>>
>>>   ENCRYPTED_PASSWD = false
>>>
>>>and the comment should say to set it to true) or do we want encrypted
>>>passwords to be on by default, as the setting in config/config-default.ini
>>>would indicate?
>>>      
>>>
>>I would say leave encrypted as default and change the wording in 
>>config/config-dist.ini.
>>The configurator creates encrypted passwords per default.
>>    
>>
>
>Yeah, that's how I was leaning as well. We don't want people using 
>plain-text passwords unless they have some good reason for it.
>  
>

If that is the case, why have a configurable option for it? Better to 
have a single path that is well documented, accepted by all, easy to 
use, than multiple paths which need to be explained and understood.

Dan

[Phpwiki-talk] Re: [ phpwiki-Bugs-1044149 ] Edit Button Toolbar doesn't work with Safari

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

SourceForge.net schrieb:
> Bugs item #1044149, was opened at 2004-10-10 13:19
> Message generated for change (Comment added) made by uckelman
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=106121&aid=1044149&group_id=6121
> 
> Category: version 1.3.x (experimental)
> Group: Rendering
> Status: Open
> 
>>Resolution: None
> 
> Priority: 5
> Submitted By: Philip J. Hollenback (philiph)
> Assigned to: Reini Urban (rurban)
> Summary: Edit Button Toolbar doesn't work with Safari
> 
> Initial Comment:
> The edit button toolbar (toolbar right above page edit area) does 
> not function correctly under Safari 1.2.3 on Mac OS X 10.3.5.  The 
> Save and Preview buttons do work.  However, all other buttons 
> (which all call insertTags) produce no result.
> 
> ----------------------------------------------------------------------
> 
> 
>>Comment By: Joel Uckelman (uckelman)
> Date: 2005-04-04 12:16
> 
> I'm using Safari 1.2.3 on MacOS X 10.3.5 right now, and all
> of the buttons in the edit toolbar work for me on my test
> wiki, which is current CVS.

Great to hear!
I did nothing special for Safari or MacOSX so far.

> Check against current CVS (or 1.3.11-rc2) to see if this
> works for you now.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

Re: [Phpwiki-talk] phpWiki and postnuke at Daimonin

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

Hi Lawrence,

Lawrence Akka schrieb:
> On 4 Apr 2005, at 15:02, Daniel Sutcliffe wrote:
...
>> It seems that there's quite a few of us interested in using phpwiki
>> within postnuke, and yet all the ports seem pretty abandoned...  it
>> is good to hear the Reini has done work on making it "native" - I'm
>> sure with the obvious interest we can volunteer some time to keep
>> this updated with a the current phpwiki once 1.3.11 is stable and
>> released.  I know I'm willing to give it some time - I ought to at
>> least drop my findings into the phpwiki Wiki...
> 
> I am sure that there is scope for making phpwiki amenable to being 
> incorporated into other software.  One thing that I recall thinking 
> would help a great deal is if the wiki transform engine was more 
> free-standing so that text could be passed in to a function, wikified, 
> and returned to the calling application without invoking the whole 
> phpwiki machinery.  This was not to easy last time I looked, which 
> admittedly was some time ago.

I thought about functional interfaces for foreign apps.
But in fact phpwiki needs all configs and helpers, so the only entry 
point is the one we are using now, which is fair enough.
Our TransformText() - "the machinery" - depends on most underlying files.

The real problem with phpwiki as module is the amount of our global vars 
and configs which might clash with the other apps.
That's why I started to work on phpnuke, postnuke, xoops and gforge 
modules, to check for possible conflicts. Besides the auth problematic, 
sharing and overtaking already registered users.

So far only $Theme clashed, that's why I renamed it to $WikiTheme.
The rest should really go into a global $WikiCfg[] somewhen, but not for 
1.3.x, so I thought.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

Re: [Phpwiki-talk] phpWiki and postnuke at Daimonin

[Daniel S. <da...@Op...>]

Lawrence Akka wrote:
> OK - you've dragged me out of retirement!  Hello everyone.
> 
> Any "old timers" on this list may remember that I wrote the 
> postnuke/phpwiki module several years ago.  I really cannot
> remember a huge amount about it, I'm afraid.  It was based on
> phpWiki 1.3.2 updated to about the end of December 2001 from cvs,
> and written to work (just about) with postnuke 0.7

Thanks - I'm sure this background info will help, even though it is
probably in this lists archives.  I love the SF search engine :-X

> I gave up supporting it partly because people seemed to expect that 
> they were entitled to make huge demands on my time (grump grump),
> but mostly because I didn't much like the direction in which
> postnuke was headed.  Also, with some exceptions, there wasn't at
> the time much enthusiasm in the PN project team for wikis in
> general.  I expect that has changed now.

I have a love/hate relationship with PostNuke - I'm not sure what
their project team thinks as I find their resources an absolute
nightmare to navigate...

I can also relate to users expecting huge amounts of time ;-)

> > I've recently updated PostNuke to 0.750a and although this port
> > mostly seems to work fine, it has broken one thing: the author
> > used to get set up to be the PN username if the user was logged
> > in, now it is always the IP address.  I'm trying to track this
> > down but if anyone has already worked this out then please save
> > me some time and drop me a hint.
> 
> No idea, sorry.

Found it.  The PN getusrinfo() call only does anything useful after
"Enable support for legacy modules" is checked in the PN settings.
With this enabled I'm back to the functionality I had before the
upgrade.  I'm not sure what this call should be replaced with and
after some searching can't find any docs on updating legacy modules
up to the current PN API... if anyone else finds anything then please
post.

> > I also found this more recent post of phpwiki for postnuke:
> >   http://noc.postnuke.com/projects/pnphpwiki/
> > based on phpwiki 1.3.8.  I haven't tried it but am interested to
> > hear any reports of success or otherwise with its use.
> 
> I was in contact with Jason Potkanski, who was responsible for this 
> module (also based on mine), about a year ago.  He too has given up
> on postnuke, and had moved over (I think) to xoops.

As your module is working fine for me now - it is probably best to
concentrate any future efforts on any work that Reini may have
already done using the current CVS phpwiki codebase.  That is unless
anyone has positive things to say about Jason's module.

> I am sure that there is scope for making phpwiki amenable to being 
> incorporated into other software.  One thing that I recall thinking 
> would help a great deal is if the wiki transform engine was more 
> free-standing so that text could be passed in to a function,
> wikified, and returned to the calling application without invoking
> the whole phpwiki machinery.  This was not to easy last time I
> looked, which admittedly was some time ago.

I'm not sure about specifics but I do know that I have a couple of
uses in mind for phpwiki where I'd like to see it working hand in
hand with other PHP apps (Gallery and phpBB).  I don't think that
any Web application can afford to view itself as working in a vacuum
and being very flexible as to how you interoperate only broadens your
audience and appeal.  Not that OpenSTA is any example of these ideals
:rolleyes:

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

Re: [Phpwiki-talk] phpWiki and postnuke at Daimonin

[Lawrence A. <la...@us...>]

On 4 Apr 2005, at 15:02, Daniel Sutcliffe wrote:

>
> Daimonin MMORPG wrote:
>> Hm, i thought the postnuke phpwiki port is known?
>>
>> http://stuff.kling.nu/
>
> This site just describes some patches to the postnuke port of phpwiki
> at:
>   http://sourceforge.net/projects/pn-modules/
> And this seems to be a patched version of phpwiki 1.3.x - where x is
> something <4 .  I've not identified what actual version it is yet,
> the text in the version would seem to suggest it is x = 0 or 1 but I
> suspect it is later.  Has anyone worked out what actual version this
> is...
>


OK - you've dragged me out of retirement!  Hello everyone.

Any "old timers" on this list may remember that I wrote the 
postnuke/phpwiki module several years ago.  I really cannot remember a 
huge amount about it, I'm afraid.  It was based on phpWiki 1.3.2 
updated to about the end of December 2001 from cvs, and written to work 
(just about) with postnuke 0.7

I gave up supporting it partly because people seemed to expect that 
they were entitled to make huge demands on my time (grump grump), but 
mostly because I didn't much like the direction in which postnuke was 
headed.  Also, with some exceptions, there wasn't at the time much 
enthusiasm in the PN project team for wikis in general.  I expect that 
has changed now.


> I've recently updated PostNuke to 0.750a and although this port
> mostly seems to work fine, it has broken one thing: the author used
> to get set up to be the PN username if the user was logged in, now
> it is always the IP address.  I'm trying to track this down but if
> anyone has already worked this out then please save me some time and
> drop me a hint.
>

No idea, sorry.



> I also found this more recent post of phpwiki for postnuke:
>   http://noc.postnuke.com/projects/pnphpwiki/
> based on phpwiki 1.3.8.  I haven't tried it but am interested to hear
> any reports of success or otherwise with its use.

I was in contact with Jason Potkanski, who was responsible for this 
module (also based on mine), about a year ago.  He too has given up on 
postnuke, and had moved over (I think) to xoops.


>
> It seems that there's quite a few of us interested in using phpwiki
> within postnuke, and yet all the ports seem pretty abandoned...  it
> is good to hear the Reini has done work on making it "native" - I'm
> sure with the obvious interest we can volunteer some time to keep
> this updated with a the current phpwiki once 1.3.11 is stable and
> released.  I know I'm willing to give it some time - I ought to at
> least drop my findings into the phpwiki Wiki...


I am sure that there is scope for making phpwiki amenable to being 
incorporated into other software.  One thing that I recall thinking 
would help a great deal is if the wiki transform engine was more 
free-standing so that text could be passed in to a function, wikified, 
and returned to the calling application without invoking the whole 
phpwiki machinery.  This was not to easy last time I looked, which 
admittedly was some time ago.

Lawrence

AW: [Phpwiki-talk] phpWiki and postnuke at Daimonin

[Daimonin M. <in...@da...>]

> 
> I also use phpwiki embedded in PostNuke:
>   http://portal.opensta.org/faq.php
> Although I didn't initially set it up and have had to do a 
> bit of investigation to try to work out what it is.
> 
> Daimonin MMORPG wrote:
> > Hm, i thought the postnuke phpwiki port is known?
> > 
> > http://stuff.kling.nu/
> 
> This site just describes some patches to the postnuke port of phpwiki
> at:
>   http://sourceforge.net/projects/pn-modules/
> And this seems to be a patched version of phpwiki 1.3.x - 
> where x is something <4 .  I've not identified what actual 
> version it is yet, the text in the version would seem to 
> suggest it is x = 0 or 1 but I suspect it is later.  Has 
> anyone worked out what actual version this is...
> 
> I've recently updated PostNuke to 0.750a and although this 
> port mostly seems to work fine, it has broken one thing: the 
> author used to get set up to be the PN username if the user 
> was logged in, now it is always the IP address.  I'm trying 
> to track this down but if anyone has already worked this out 
> then please save me some time and drop me a hint.
> 
> I also found this more recent post of phpwiki for postnuke:
>   http://noc.postnuke.com/projects/pnphpwiki/
> based on phpwiki 1.3.8.  I haven't tried it but am interested 
> to hear any reports of success or otherwise with its use.
> 
> It seems that there's quite a few of us interested in using 
> phpwiki within postnuke, and yet all the ports seem pretty 
> abandoned...  it is good to hear the Reini has done work on 
> making it "native" - I'm sure with the obvious interest we 
> can volunteer some time to keep this updated with a the 
> current phpwiki once 1.3.11 is stable and released.  I know 
> I'm willing to give it some time - I ought to at least drop 
> my findings into the phpwiki Wiki...
> 
> Cheers
> /dan

I strongly agree to it.

What i can promise is, that people will get alot response from us
and the whole postnuke community. And the phpnuke people, because
there are easy interfaces for post->nuke stuff (even i don't care
about that CMS). Whatever you say about the CMS - the community 
is very big and demands a wiki since 2 years.

phpWiki is our core documentation and content generation core on our 
site and we got a 4000+ members in 8 weeks, constantly around 75-80
per day in the middle. 

That will increase heavily after we release (after half a year) the
new beta and we got ALOT questions around documentation and writing.

That *will* be generate some response and interest people want and
need here. ATM we can't give it - the hacked phpwiki is not usable for it.

All what i can say: The synergy effect will be a win to win situation for
both and that not just a empty phrase.

Michael Toennies
Daimonin MMORPG
http://www.daimonin.net

Re: [Phpwiki-talk] phpWiki and postnuke at Daimonin

[Daniel S. <da...@Op...>]

I also use phpwiki embedded in PostNuke:
  http://portal.opensta.org/faq.php
Although I didn't initially set it up and have had to do a bit of
investigation to try to work out what it is.

Daimonin MMORPG wrote:
> Hm, i thought the postnuke phpwiki port is known?
> 
> http://stuff.kling.nu/

This site just describes some patches to the postnuke port of phpwiki
at:
  http://sourceforge.net/projects/pn-modules/
And this seems to be a patched version of phpwiki 1.3.x - where x is
something <4 .  I've not identified what actual version it is yet,
the text in the version would seem to suggest it is x = 0 or 1 but I
suspect it is later.  Has anyone worked out what actual version this
is...

I've recently updated PostNuke to 0.750a and although this port
mostly seems to work fine, it has broken one thing: the author used
to get set up to be the PN username if the user was logged in, now
it is always the IP address.  I'm trying to track this down but if
anyone has already worked this out then please save me some time and
drop me a hint.

I also found this more recent post of phpwiki for postnuke:
  http://noc.postnuke.com/projects/pnphpwiki/
based on phpwiki 1.3.8.  I haven't tried it but am interested to hear
any reports of success or otherwise with its use.

It seems that there's quite a few of us interested in using phpwiki
within postnuke, and yet all the ports seem pretty abandoned...  it
is good to hear the Reini has done work on making it "native" - I'm
sure with the obvious interest we can volunteer some time to keep
this updated with a the current phpwiki once 1.3.11 is stable and
released.  I know I'm willing to give it some time - I ought to at 
least drop my findings into the phpwiki Wiki...

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

AW: [Phpwiki-talk] Re: Wiki spam and the future of phpwiki

[Daimonin M. <in...@da...>]

> -----Urspr=FCngliche Nachricht-----
> Von: php...@li...=20
> [mailto:php...@li...] Im Auftrag=20
> von Matthew Palmer
> Gesendet: Sonntag, 3. April 2005 19:01
> An: php...@li...
> Betreff: [Phpwiki-talk] Re: Wiki spam and the future of phpwiki
>=20
> On Fri, Apr 01, 2005 at 10:17:16AM +0200, Manuel VACELET wrote:
> > Arnaud Fontaine wrote:
> > >I think we must find a different dev/commit model to attract more=20
> > >developpers and ... keep us working on phpwiki ... Should we have=20
> > >several cvs/svn trees and decide on a process to merge=20
> them every ...
> > >week ? Or have several cvs branches ? Should Reini or Steve give=20
> > >write access to any/more contributors ?
> >=20
> > I think opening a svn repository for phpwiki is a good thing. With=20
> > https access everyone can access to source code (even if=20
> you are barbarian proxy).
>=20
> /me does a little dance and sings "arch, arch, arch arch!"
>=20
> If you're truly and deeply engrossed with SVN, at least run=20
> svk and give people half a chance.

As now a OS project leader for some 3 years i think you guys just =
steping
here
in a very dangerous trap.

The problem is of course not the dev/commit model. If so, why then most =
of
the
other projects using it have no problems? I come from a mmorpg game and =
we
commit
code, art, content and even music. Adding patches & doing bug hunting. =
And
it works.

With more and more complex system like svn, gnu arch or whatever you =
will
fix nothing.
Beside the fact, that without a base like sourceforge with it resources =
all
this stuff
is useless. The work to maintain it by yourself will eat up every =
positiv
effect easily.
Any system, even source safe would be good enough. It has absolut no =
impact
on the issues
you mentioned before. Sorry.

Your arguments are really the arguments of computer specialist and =
freaks.
I mean that in a absolut friendly way, iam itself one.

All the problems you described here has a simple source:
You lake the stable enduser base. Using the phpwiki in one, broad base.

The problems seems the feedback loop between you (the project) and your
users.

Sorry to say but: You can add as many features like you want, or =
backends or
whatever.
There are tons of wiki systems out and many of them are good and kick in =
new
features all the time. You can't overcome them. In this way you can only
swim with the
rest of the swarm, one under many.

If you don't find a your own unique way what makes you atractive for =
your
users and=20
others, then you has a problem.

I mentioned to focus on a (easy to do) flawless interface for postnuke
(phpnuke should
work then too because they are very common in some ways). That would =
open a
door which
gives the whole project a new position without changing it really. You =
will
just allow
people to come to the project (the *many* people demanding and searching =
a
working wiki
for their CMS).=20

They will come with new ideas, patches and code. It always works in that
way, thats=20
the way open source projects works like.

[Phpwiki-talk] Re: Wiki spam and the future of phpwiki

[Matthew P. <mp...@he...>]

On Mon, Apr 04, 2005 at 08:09:40AM +0200, Reini Urban wrote:
> Matthew Palmer schrieb:
> >I've got experience deploying Arch in an OSS project similar to PHPWiki
> >(IRM; http://www.sf.net/projects/irm), and while it hasn't been as
> >straightforward as I would have liked, I think it's been a success, and
> >if the PHPWiki developers (and the rest of the PHPWiki community) are
> >keen, I'd be willing to sit down and help PHPWiki transition to using
> >GNU Arch for revision control.
>=20
> We will not transition to something else, even if it would be "better",=
=20
> because sf.net doesn't support it. We need our infrastructure there.

When did sf.net stop supporting sftp and/or HTTP?  I must have missed
the announcement.

The other benefit of a distributed system is that people with the
resources available wouldn't be beholden to sf.net's levels of support.
Oh, and Arch supports disconnected operation nicely, too, which I
love...

- Matt

[Phpwiki-talk] Re: Wiki spam and the future of phpwiki

[Matthew P. <mp...@he...>]

On Sun, Apr 03, 2005 at 08:22:19PM +0200, Arnaud Fontaine wrote:
> Matthew Palmer a =E9crit :
> > You're crying out for a distributed development model.  GNU Arch
> > (unpleasant UI notwithstanding) can provide all of the features you're
> > after.  Basically, one (or more!) people maintains a blessed "releases"
> > branch, which merges bits and pieces from other contributors as they
> > write and test them.  Other people can cherry-pick changes from people
> > as they like.  It's an incredibly powerful model for development;
> > unfortunately, it has the downside of tending to melt peoples' brains a
> > bit at first, especially if they've been suckling from the CVS teat for
> > too long (I speak from experience; my brain got melted).
>=20
> OMG !!! I love learning new things on sunday afternoon !!
> Thank's a lot, Matthew ! I've been looking for this for years (not
> actively, I admit ... still using some ugly homebrew script to rsync cvs
> trees) and it was just there, sitting on my gnu linux box !
>=20
> I found 2 deb packages implementing GNU Arch : tla and bazaar. Any
> experience with them ?

Yes, with both.  tla is the "original" implementation, while bazaar is a
branch of tla (from Canonical, the people behind Ubuntu) to improve the user
experience of Arch for the common user.  I'd recommend bazaar, it's just th=
at
much nicer to work with.  A lot of the documentation out there is
tla-specific, though, so it's a bit of a tradeoff in that respect.

- Matt

Re: [Phpwiki-talk] Re: Wiki spam and the future of phpwiki

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

Matthew Palmer schrieb:
> I've got experience deploying Arch in an OSS project similar to PHPWiki
> (IRM; http://www.sf.net/projects/irm), and while it hasn't been as
> straightforward as I would have liked, I think it's been a success, and
> if the PHPWiki developers (and the rest of the PHPWiki community) are
> keen, I'd be willing to sit down and help PHPWiki transition to using
> GNU Arch for revision control.

We will not transition to something else, even if it would be "better", 
because sf.net doesn't support it. We need our infrastructure there.

But anybody can host his private arch or svn repo if properly synced.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

Re: Many backends (WAS: Re: [Phpwiki-talk] Wiki spam and the future of phpwiki)

[Jim C. <ji...@in...>]

Matthew Palmer wrote:
> On Fri, Apr 01, 2005 at 08:51:41AM -0600, Joel Uckelman wrote:
>>There's a huge performance hit if we force everyone not using an SQL server
>>to use flatfile; nor do I think that we want to force everyone to use an SQL
>>server. That's why I think we should keep both dba and flatfile.
> 
> *cough*sqlite*cough*  If you're going to go with a DB out-of-the-box, (and I'm
> not saying that's a good or bad thing), I can't imagine an easier type to
> support than SQLite.  It's built-in for PHP5, the PECL module for php4
> is simple to install... it's all easy.

I'd second sqlite - it's used in as a backend for the Trac svn-aware, 
ticketing wiki (http://edgewall.com/trac/).

It's very easy to be able to run up a SQL monitor from the command-line, 
and grab table schemas, run queries, all that jazz, without having to 
have a server process as the dbm.

-jim

Re: [Phpwiki-talk] ENCRYPTED_PASSWORD default, bug 1175782

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

Thus spake Reini Urban:
> Joel Uckelman schrieb:
> > The comment which describes ENCRYPTED_PASSWD in config/config-dist.ini is
> > at variance with the actual setting:
> > 
> > ; It is recommended that you use the passencrypt.php utility to encode the
> > ; admin password, in the event that someone gains ftp or ssh access to the
> > ; server and directory containing phpwiki. Once you have pasted the
> > ; encrypted password into ADMIN_PASSWD, uncomment this next line.
> > ENCRYPTED_PASSWD = true
> > 
> > 1) The last line isn't commented by default, contrary to the comment.
> > 2) It wouldn't matter if it were commented, since ENCRYPTED_PASSWD = true
> > in config/config-default.ini anyway.
> > 
> > What's the correct behavior here? Do we want it to work as described in 
> > the comment (in which case the last line should read
> > 
> >    ENCRYPTED_PASSWD = false
> > 
> > and the comment should say to set it to true) or do we want encrypted
> > passwords to be on by default, as the setting in config/config-default.ini
> > would indicate?
> 
> I would say leave encrypted as default and change the wording in 
> config/config-dist.ini.
> The configurator creates encrypted passwords per default.

Yeah, that's how I was leaning as well. We don't want people using 
plain-text passwords unless they have some good reason for it.

-- 
J.

Re: [Phpwiki-talk] Re: Wiki spam and the future of phpwiki

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

Thus spake Arnaud Fontaine:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> =

> Matthew Palmer a =C3=A9crit :
> =

> > You're crying out for a distributed development model.  GNU Arch
> > (unpleasant UI notwithstanding) can provide all of the features you'r=
e
> > after.  Basically, one (or more!) people maintains a blessed "release=
s"
> > branch, which merges bits and pieces from other contributors as they
> > write and test them.  Other people can cherry-pick changes from peopl=
e
> > as they like.  It's an incredibly powerful model for development;
> > unfortunately, it has the downside of tending to melt peoples' brains=
 a
> > bit at first, especially if they've been suckling from the CVS teat f=
or
> > too long (I speak from experience; my brain got melted).
> =

> OMG !!! I love learning new things on sunday afternoon !!
> Thank's a lot, Matthew ! I've been looking for this for years (not
> actively, I admit ... still using some ugly homebrew script to rsync cv=
s
> trees) and it was just there, sitting on my gnu linux box !
> =

> I found 2 deb packages implementing GNU Arch : tla and bazaar. Any
> experience with them ?

This does sound neat; however, it doesn't do us much good unless there ar=
e =

more people contributing. <nudge, nudge>. There are lots of bugs listed o=
n =

our project page. I'll be a lot more enthused about development model =

changes if I see more people adopting and fixing bugs first...

-- =

J.

Re: [Phpwiki-talk] Re: Wiki spam and the future of phpwiki

[Arnaud F. <ar...@cr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Palmer a écrit :

> You're crying out for a distributed development model.  GNU Arch
> (unpleasant UI notwithstanding) can provide all of the features you're
> after.  Basically, one (or more!) people maintains a blessed "releases"
> branch, which merges bits and pieces from other contributors as they
> write and test them.  Other people can cherry-pick changes from people
> as they like.  It's an incredibly powerful model for development;
> unfortunately, it has the downside of tending to melt peoples' brains a
> bit at first, especially if they've been suckling from the CVS teat for
> too long (I speak from experience; my brain got melted).

OMG !!! I love learning new things on sunday afternoon !!
Thank's a lot, Matthew ! I've been looking for this for years (not
actively, I admit ... still using some ugly homebrew script to rsync cvs
trees) and it was just there, sitting on my gnu linux box !

I found 2 deb packages implementing GNU Arch : tla and bazaar. Any
experience with them ?


- --
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCUDRbyAf3wgFyy1ARAgG1AKDzMZbPKfXKQ+Jyju8XDvq0p+UJMgCeKik4
cACrXIiaoqnwmOieDgE+FXE=
=Q14c
-----END PGP SIGNATURE-----

[Phpwiki-talk] Re: Wiki spam and the future of phpwiki

[Matthew P. <mp...@he...>]

On Thu, Mar 31, 2005 at 06:27:24PM +0200, Arnaud Fontaine wrote:
> "Release early, release often" .. That's one of the main bazaar rules.
> It's really important for the developpement to go nicely.

It's not quite as easy as that, from experience.  Throwing releases out
there willy-nilly tends to piss people off, and if people are ticked off
they're not about to run out and install whatever you put out next time,
which kinda screws your tester base.  However, running from CVS isn't
something anyone should contemplate, really -- you don't know what
ickyness is running around in there, and supporting people running CVS
snapshots is hell -- how do you realistically answer the question "so
which version did you encounter the bug in?".  A date range is less than
pleasant to deal with.

> I think we must find a different dev/commit model to attract more
> developpers and ... keep us working on phpwiki ... Should we have
> several cvs/svn trees and decide on a process to merge them every ...
> week ? Or have several cvs branches ? Should Reini or Steve give write
> access to any/more contributors ?

You're crying out for a distributed development model.  GNU Arch
(unpleasant UI notwithstanding) can provide all of the features you're
after.  Basically, one (or more!) people maintains a blessed "releases"
branch, which merges bits and pieces from other contributors as they
write and test them.  Other people can cherry-pick changes from people
as they like.  It's an incredibly powerful model for development;
unfortunately, it has the downside of tending to melt peoples' brains a
bit at first, especially if they've been suckling from the CVS teat for
too long (I speak from experience; my brain got melted).

I've got experience deploying Arch in an OSS project similar to PHPWiki
(IRM; http://www.sf.net/projects/irm), and while it hasn't been as
straightforward as I would have liked, I think it's been a success, and
if the PHPWiki developers (and the rest of the PHPWiki community) are
keen, I'd be willing to sit down and help PHPWiki transition to using
GNU Arch for revision control.

- Matt

[Phpwiki-talk] Re: Wiki spam and the future of phpwiki

[Matthew P. <mp...@he...>]

On Fri, Apr 01, 2005 at 10:17:16AM +0200, Manuel VACELET wrote:
> Arnaud Fontaine wrote:
> >I think we must find a different dev/commit model to attract more
> >developpers and ... keep us working on phpwiki ... Should we have
> >several cvs/svn trees and decide on a process to merge them every ...
> >week ? Or have several cvs branches ? Should Reini or Steve give write
> >access to any/more contributors ?
>=20
> I think opening a svn repository for phpwiki is a good thing. With https=
=20
> access everyone can access to source code (even if you are barbarian prox=
y).

/me does a little dance and sings "arch, arch, arch arch!"

If you're truly and deeply engrossed with SVN, at least run svk and give
people half a chance.

- Matt

Re: Many backends (WAS: Re: [Phpwiki-talk] Wiki spam and the future of phpwiki)

[Matthew P. <mp...@he...>]

On Fri, Apr 01, 2005 at 08:51:41AM -0600, Joel Uckelman wrote:
> There's a huge performance hit if we force everyone not using an SQL server
> to use flatfile; nor do I think that we want to force everyone to use an SQL
> server. That's why I think we should keep both dba and flatfile.

*cough*sqlite*cough*  If you're going to go with a DB out-of-the-box, (and I'm
not saying that's a good or bad thing), I can't imagine an easier type to
support than SQLite.  It's built-in for PHP5, the PECL module for php4
is simple to install... it's all easy.

dba is dying, we should leave it to it's quiet death.  There's big,
stinky bugs in the dba implementations in newer versions of PHP which many
people apparently just don't want to deal with.

- Matt

Re: [Phpwiki-talk] ENCRYPTED_PASSWORD default, bug 1175782

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

Joel Uckelman schrieb:
> The comment which describes ENCRYPTED_PASSWD in config/config-dist.ini is
> at variance with the actual setting:
> 
> ; It is recommended that you use the passencrypt.php utility to encode the
> ; admin password, in the event that someone gains ftp or ssh access to the
> ; server and directory containing phpwiki. Once you have pasted the
> ; encrypted password into ADMIN_PASSWD, uncomment this next line.
> ENCRYPTED_PASSWD = true
> 
> 1) The last line isn't commented by default, contrary to the comment.
> 2) It wouldn't matter if it were commented, since ENCRYPTED_PASSWD = true
> in config/config-default.ini anyway.
> 
> What's the correct behavior here? Do we want it to work as described in 
> the comment (in which case the last line should read
> 
>    ENCRYPTED_PASSWD = false
> 
> and the comment should say to set it to true) or do we want encrypted
> passwords to be on by default, as the setting in config/config-default.ini
> would indicate?

I would say leave encrypted as default and change the wording in 
config/config-dist.ini.
The configurator creates encrypted passwords per default.


; Encrypted passwords are default. It is recommended that you use
; the passencrypt.php or the configurator.php utility to encode
; the admin password, in the event that someone gains ftp or shell
; access to the server and directory containing phpwiki. To use plain
; text passwords, esp. the ADMIN_PASSWD set ENCRYPTED_PASSWD to false.
; ENCRYPTED_PASSWD = true

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

[Phpwiki-talk] ENCRYPTED_PASSWORD default, bug 1175782

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

The comment which describes ENCRYPTED_PASSWD in config/config-dist.ini is
at variance with the actual setting:

; It is recommended that you use the passencrypt.php utility to encode the
; admin password, in the event that someone gains ftp or ssh access to the
; server and directory containing phpwiki. Once you have pasted the
; encrypted password into ADMIN_PASSWD, uncomment this next line.
ENCRYPTED_PASSWD = true

1) The last line isn't commented by default, contrary to the comment.
2) It wouldn't matter if it were commented, since ENCRYPTED_PASSWD = true
in config/config-default.ini anyway.

What's the correct behavior here? Do we want it to work as described in 
the comment (in which case the last line should read

   ENCRYPTED_PASSWD = false

and the comment should say to set it to true) or do we want encrypted
passwords to be on by default, as the setting in config/config-default.ini
would indicate?