phpwiki-talk

[Phpwiki-talk] Re: [ phpwiki-Bugs-1153483 ] crao theme breaks installation

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

Joel Uckelman schrieb:
> Thus spake Reini Urban:
>>That memory hunger started with 1.3.4 when output buffering for our 
>>templates was introduced.
>>Before we preg_replace'd the vars and did some simple logic with magic 
>>### markers. This was fast and needed no memory at all, but lead to 
>>dirty template syntax.
>>The big thing is really a php bug, the various Load/SavePages loop, 
>>which doesn't free its internal memory after rendering each page.
> 
> I wonder whether strategic placement of a few unset()'s would mitigate the
> problem? I thought that data was garbage-collected when the ref count dropped
> to zero. Is it possible that we have a circular reference somewhere?

I actually unset every possible var, and also checked the destructors 
with possible external ressources (mysql handles and query results).

It could be a circular ref left over.
But I searched for almost one year for such a beast and found nothing.
So I rather suspect it's php itself, which I didn't compile for memory 
tracing, yet.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

Re: [Phpwiki-talk] Global_Data

[(YOD) <yo...@pn...>]

On Sat, 2 Apr 2005, Reini Urban wrote:

> (YOD) schrieb:
> > What is global_data? I was cleaning up my database and accidentally 
> > deleted this. It was the first item in the base and I didn't recognize it. 
> > Another Wiki I have also has global_data (and I did not remove it (g)).. 
> > Should that be something I should be concerned about?
> 
> global_data is the one and only special page PhpWiki keeps around to 
> store/restore its system-wide, not page-specific state.
> It should not be deleted, but it causes no critical errors if you 
> already did.
> It could be any other pagename also. (See lib/WikiDB.php:538)
> PhpWiki uses the special metatag "__global" in global_data for its 
> special data.
> Every WikiDB::get() - WikiDB::set() call uses this area.
> Currently we use it for non-critical values,
> the DB _timestamp, plus some global stats.

Reini: I tried to reinsert global_data and this is what I got:

Error

SQL-query : 

UPDATE `page` SET `pagename` = 'global_data',
`pagedata` = 
'a:1:{s:8:"__global";a:1:{s:10:"_timestamp";a:2:{i:0;i:1112395452;i:1;i:98;}}}' 
WHERE `id` = '2892' LIMIT 1 ;

MySQL said:
#1062 - Duplicate entry 'global_data' for key 2

Re: [Phpwiki-talk] Re: secure phpwiki: request for example

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

Stan Berka schrieb:
> Thanks!  It works.  I did it ... with your help!
> It does behave funny when I'm signing-out, but it doesn't stop me.  
> Should I report all the problems I have mentioned before as bugs 
> together with the "'Db''" artifact by the configurator and signing-out 
> funnies into bugzilla of phpwiki project?  Or Reini and other know about 
> it from this list, can I assume?

I know it, but I'm not sure yet if those problems will get fixed for 
1.3.11, since the whole new configurator is considered experimental, 
which still requires manual examination by some human.

It would be good to submit those artifacts into our tracker for others 
who might have the same problems later.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

Re: [Phpwiki-talk] Release Candiidate 2 (almost)

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

Reini Urban schrieb:
> Reini Urban schrieb:
> rc2 is ready but upload.sf.net has issues not taking my upload.
> See 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1174903&group_id=1&atid=200001 

This is solved. rc2 is out.

The pending 1.2.8 release from the old-stable branch from
January 30, 2005 is also out now.

> I'll wait until tommorrow morning. (That's today night for the US folks :)
> 
> The problem is that a broken upload forbids uploading again with the 
> same filename until the upload is deleted manually (a release) or 
> automatically (some cron job).
> 
> This should be the release notes.
> 
> Changes since 1.3.11_rc1:
> * fixed mysql unicode-latin1 issues (> 4.1)
> * fixed several WikiAdminRename issues,
>   added the icase and regex feature.
>   subpage problem not yet found.
> * fixed rename with dba
> * fixed diff printing &nbsp; before <HTML>
> * fixed RecentCanges plugins defaults
>   (e.g. PageHistory with unknown pagename)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

[Phpwiki-talk] Re: Many backends

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

Joel Uckelman schrieb:
> Thus spake Dan Frankowski:
> 
>>See, I completely disagree. Why keep flatfile and cvs and dba? I've seen 
>>Reini wasting time answering people who email the list, "Probably dba is 
>>not installed on your system" etc. Why not just keep ONE of flatfile, 
>>cvs and dba? Why keep all 3? You have not made a strong case.

It's not my primaray goal to answer such support questions.
If I do so, because I don't have nothing better to do. So I wouldn't 
drop database backends just because it needs some of my time for 
answering support questions.
If I don't answer I have more important things to do. As in the last weeks.

> The primary problem with dba is that some Linux distros' default builds of
> PHP no longer come with dba support compiled in. That problem could mostly
> be solved by including a note on how to rebuild PHP with dba support. (It's
> really really easy, if you have a distro with package management.)
> 
> 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.

flatfile is not that slow. it's almost as fast as SQL, if not faster. 
The real problem is the lack of true OS filelocking, which has similar 
problems with certain dba backends (gdbm e.g.) and with pearDB and 
stupid SQL databases (mysql e.g.).
berkeley db is really fine.
gdbm would be theoretically the best, but has a lot of bugs with older 
php's.

> As for the cvs backend, do we have a documented case of anyone using it?
> I wouldn't object to dropping that one if we don't.

I know of nobody using cvs.
It's no major problem keeping it for a while as now, effectively 
unsupported. I don#t really care.
In fact I have almost ported the new php5 cvsclient pecl library as 
WikiDB backend, which is independent of the external cvs binaries.

Much more important is the new PDO backend for PHP5, which is much 
cleaner as PearDB and adodb.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

[Phpwiki-talk] Re: [ phpwiki-Bugs-1153483 ] crao theme breaks installation

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

SourceForge.net schrieb:
> Bugs item #1153483, was opened at 2005-02-28 08:01
> Message generated for change (Comment added) made by uckelman
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=106121&aid=1153483&group_id=6121
> 
> Category: version 1.3.x (experimental)
> Group: Installation
> Status: Open
> Resolution: Later
> Priority: 5
> Submitted By: Peter Lundqvist (p3l)
> Assigned to: Reini Urban (rurban)
> Summary: crao theme breaks installation
> 
> Initial Comment:
> It seems (tried a few times with fresh database) that
> the virgin wiki won't load using the crao theme. It
> stops after
> 
>   Loading Virgin Wiki
>   %BODY%
> 
> Switching to the default theme, loading the virgin wiki
> and then switching back solves the problem if you want
> to use the crao theme.
> 
> ----------------------------------------------------------------------
> 
> 
>>Comment By: Joel Uckelman (uckelman)
> 
> Date: 2005-04-01 20:18
> 
> Message:
> Logged In: YES 
> user_id=245140
> 
> Ok, what I'm seeing is clearly due to hitting a memory
> limit, not to any peculiar properties of the pages being loaded:
> 
> [client 128.104.60.232] PHP Fatal error:  Allowed memory
> size of 8388608 bytes exhausted (tried to allocate 9749
> bytes) in /home/uckelman/projects/phpwiki/lib/ziplib.php on
> line 829
> 
> Why does loading a fresh wiki take such an enormous amount
> of memory? Are all the pages kept in memory simultaneously
> prior to being written to the DB? Hmm.

That memory hunger started with 1.3.4 when output buffering for our 
templates was introduced.
Before we preg_replace'd the vars and did some simple logic with magic 
### markers. This was fast and needed no memory at all, but lead to 
dirty template syntax.
The big thing is really a php bug, the various Load/SavePages loop, 
which doesn't free its internal memory after rendering each page.

Either
a) we go back to the previous template solution without output buffering 
inside our template expansion, or
b) we introduce a 3rd party template lib (Smarty).

a) Will not work with a few templates anymore. We are not allowed to 
assign vars anymore in php (no major problem) and we may not loop
(just a problem for non-critical plugins).
We do have some IF. Some FOR may be easily introduced also, if really 
needed.

b) Smarty will introduce another major 3rd party lib dependency
(as adodb, pear DB, ...), but would solve all these problems.
Other templating systems in php5 pecl are in sight also.
wikilens already introduced Smarty, but not as general template system, 
just for their user-editable templates.
With Smarty we could go this step also and allow users edit the 
templates. But this will be a big step.

I delayed this decision for middle of this year.

> ----------------------------------------------------------------------
> 
> Comment By: Joel Uckelman (uckelman)
> Date: 2005-04-01 20:01
> 
> Message:
> Logged In: YES 
> user_id=245140
> 
> I've investigated this problem a bit and found the following:
> 
> When loading a virgin wiki (using every theme I've tried),
> it stops while loading ReleaseNotes. Refreshing the page
> causes the remainder of the pages to be loaded.
> 
> I'm not sure yet whether something about the ReleaseNotes
> page is causing the problem, or if some memory or process
> limit is being hit. If I delete ReleaseNotes from pgsrc,
> loading continues up to PhpWikiPoll, and stops there.
> Deleting PhpWikiPoll lets the initial load progress a bit
> farther. I repeated this through several iterations, but
> didn't reach the end of the load process without reloading
> the page first.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

Re: [Phpwiki-talk] Global_Data

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

(YOD) schrieb:
> What is global_data? I was cleaning up my database and accidentally 
> deleted this. It was the first item in the base and I didn't recognize it. 
> Another Wiki I have also has global_data (and I did not remove it (g)).. 
> Should that be something I should be concerned about?

global_data is the one and only special page PhpWiki keeps around to 
store/restore its system-wide, not page-specific state.
It should not be deleted, but it causes no critical errors if you 
already did.
It could be any other pagename also. (See lib/WikiDB.php:538)
PhpWiki uses the special metatag "__global" in global_data for its 
special data.
Every WikiDB::get() - WikiDB::set() call uses this area.
Currently we use it for non-critical values,
the DB _timestamp, plus some global stats.

See http://mywiki/global_data?action=DebugInfo
or http://mywiki/global_data?action=EditMetaData

> When I clean the DB of superfluous items which are not really pages in the 
> Wiki it seems to speed up retrieval. That and closing any htppd processes 
> which increase load will make the Wiki seem or appear to fly. 

I doubt that the pages you deleted which are just id's of links affect 
system performance. But closing stale httpd and mysql processes may 
drastically increase performance.

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

Re: [Phpwiki-talk] Release Candidate 1

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

Thus spake Reini Urban:
> I've made available a release candidate 1, which should fix most of the
> problems.
> 
> Known problems to be done:
> 
> * accept email with + #1166336

I have a solution for this one, which I'll commit soon. It's similar to 
(but not quite exactly like) the patch I attached to the bug this evening.

-- 
J.

[Phpwiki-talk] memory usage on loading a virgin wiki

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

Whenever I load a virgin wiki, it always takes a refresh of the page 
because on the first shot php dies from lack of memory just as ReleaseNotes 
is loading. I finally decided to investigate this, and discovered that 
memory_get_usage() reports increased memory usage after each successive 
page is loaded from pgsrc. Does anyone know why that is? Why isn't the page 
data being deleted from memory after it's pushed into the DB?

-- 
J.

[Phpwiki-talk] Global_Data

[(YOD) <yo...@pn...>]

What is global_data? I was cleaning up my database and accidentally 
deleted this. It was the first item in the base and I didn't recognize it. 
Another Wiki I have also has global_data (and I did not remove it (g)).. 
Should that be something I should be concerned about?

When I clean the DB of superfluous items which are not really pages in the 
Wiki it seems to speed up retrieval. That and closing any htppd processes 
which increase load will make the Wiki seem or appear to fly. 

Hank

[Phpwiki-talk] Re: secure phpwiki: request for example

[Stan B. <sb...@po...>]

Thanks!  It works.  I did it ... with your help! 

It does behave funny when I'm signing-out, but it doesn't stop me.  
Should I report all the problems I have mentioned before as bugs 
together with the "'Db''" artifact by the configurator and signing-out 
funnies into bugzilla of phpwiki project?  Or Reini and other know about 
it from this list, can I assume?

-- 
Best regards,
Stan Berka
Senior Programmer Analyst
Pope & Talbot, Inc.
Portland, OR
503 552-4315

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

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

Philip J. Hollenback schrieb:
> On Wed, 30 Mar 2005 08:56:02 -0600, "Dan Frankowski"
> <dfr...@cs...> said:
...
>>Might not be a bad idea to also have IP filtering, but this can also
>>be done at the .htaccess file in your dir .. IF your Apache allows
>>overrides.
> 
> Those sound like very positive steps.  At the same time, they highlight
> the brokenness of the phpwiki development model.  I had no idea these
> features were being integrated.  If we had some more regular releases,
> then these things would show up in the release notes (hopefully) instead
> of being buried in cvs commit messages, etc.

They ARE in the ReleaseNotes, to try out at the demo site and described 
at the sf doc pages, but because there are so many changes you will 
probably overread them.

http://phpwiki.sf.net/demo/en/ReleaseNotes
http://phpwiki.org/WikiSpam
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban
http://phpwiki.org

Re: [Phpwiki-talk] Re: [SECUNIA] PhpWiki

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

Reini Urban schrieb:
> Thomas Kristensen schrieb:
>> In the recent changelog for PhpWiki you describe two security issues.
>> http://sourceforge.net/project/shownotes.php?release_id=315974
>>
>> I would like some details about who and how this could be exploited,
>> also I would like to know if any mitigating factors apply.
> 
> 
> problem from 1.3.10 - 1.3.11
> * security fix for create ACL: action=edit is now checked for create"
> 
> If someone edits the ACL to let someone edit but not create a page, and 
> if someone creates a page by using the edit button, the create ACL was 
> not ignored.

oops:
=> ... the create ACL was ignored.

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

[Phpwiki-talk] Release Candiidate 2 (almost)

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

Reini Urban schrieb:
>>Manuel VACELET wrote:
>>>I haven't downloaded 1.3.11 beta because I don't have CVS access
>>>and I  currently don't have many time for this job.
>>
>>Charles said to me in private that coresponding tarball is available in
>>File Releases on Sf.
>>I only read phpwiki HomePage (where each release are announced), it
>>could be a good idea to add a link on this page isn't it ?
> 
> RC1 is only for developers,
> to gather some constructive feedback about remaining issues.
> 
> But since it's officially published via the sf.net release system,
> the link is be automatically there.
> 
> http://sf.net/projects/phpwiki/
> =>
> PhpWiki 1.3 (current) phpwiki-1.3.11_rc1 March 27, 2005  -   Download

rc2 is ready but upload.sf.net has issues not taking my upload.
See 
http://sourceforge.net/tracker/index.php?func=detail&aid=1174903&group_id=1&atid=200001
I'll wait until tommorrow morning. (That's today night for the US folks :)

The problem is that a broken upload forbids uploading again with the 
same filename until the upload is deleted manually (a release) or 
automatically (some cron job).

This should be the release notes.

Changes since 1.3.11_rc1:
* fixed mysql unicode-latin1 issues (> 4.1)
* fixed several WikiAdminRename issues,
   added the icase and regex feature.
   subpage problem not yet found.
* fixed rename with dba
* fixed diff printing &nbsp; before <HTML>
* fixed RecentCanges plugins defaults
   (e.g. PageHistory with unknown pagename)

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

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

[(YOD) <yo...@pn...>]

On Wed, 30 Mar 2005, Dan Frankowski wrote:
> 
> 1. Don't allow saving a page that has more than 20 external ("http://") 
> links. In our code, I modified "20" to be a configurable parameter 
> SPAM_MAX_EXTERNAL_LINKS. We've been completely spammed as well, and I 
> believe this will help us a lot. We have a wiki where each legitimate 
> page only contains a few external links, but spam pages contain tons 
> (>50 for sure) external links.

I'd like to implement this modification. Would you be kind enough to send
it to me? 

I have three working PhpWikis but two (with a progressive
political orientation) of them I have only open blogging but otherwise
editing is now turned off due to excessive spamming. I just installed a
third Wiki to play with and haven't decided yet what to do with it.

I am just waiting to see how long it takes for spam to find the new open 
Wiki and I suspect it won't be long (g). 

I also want to explore other methods for securing Wiki from spambots 
(intentional spammers are much easier to deal with) so I have been 
following these discussions with much interest.

Hank Roth

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

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

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

Dan Frankowski wrote:
| See, I completely disagree. Why keep flatfile and cvs and dba? I've see=
n
| Reini wasting time answering people who email the list, "Probably dba i=
s
| not installed on your system" etc. Why not just keep ONE of flatfile,
| cvs and dba? Why keep all 3? You have not made a strong case.
|
| All the back-ends cost a TON in support, both development and even more
| on the mailing lists and in user frustration. This contradicts your
| "release early and often" above. Rather, make one or two back-ends work
| really well.

H=E9h=E9 :)
I completly ... agree :) we should keep at least one non sql dependent
backend. DB files are great because hash files are quite fast for the
wiki purpose, you only have 1 file to backup, it's trivial to install
... but yes, you need dba and a dba backend installed on your system.
CVS ... great ... but you need CVS installed.
Flatfile ... good too, no dependency ... fast on common operations, slow
on some.
Which one to keep ??
And can't we have a plugin approch to storage so it will be easier to
maintain and any one can make a special backend if he wants to ...
Same for the wiki syntax and the output format ... you drop a plugin
where it needs to be dropped and ... you have a new syntax, output
format, storage system ...

| We should first reduce the support load and focus on what PhpWiki does
| best, whatever that is.

Agree.

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

iD8DBQFCTWJKyAf3wgFyy1ARAuasAJ4hT01+eiuJljzT7Km3qjmtK6XRewCgpsO2
Jtq2GRpPW/xD8ljsWDJxxIY=3D
=3DLx/d
-----END PGP SIGNATURE-----

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

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

Thus spake Dan Frankowski:
> 
> See, I completely disagree. Why keep flatfile and cvs and dba? I've seen 
> Reini wasting time answering people who email the list, "Probably dba is 
> not installed on your system" etc. Why not just keep ONE of flatfile, 
> cvs and dba? Why keep all 3? You have not made a strong case.

The primary problem with dba is that some Linux distros' default builds of
PHP no longer come with dba support compiled in. That problem could mostly
be solved by including a note on how to rebuild PHP with dba support. (It's
really really easy, if you have a distro with package management.)

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.

As for the cvs backend, do we have a documented case of anyone using it?
I wouldn't object to dropping that one if we don't.
 

Re: [Phpwiki-talk] PhpWiki process

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

Charles Corrigan wrote:

>There are lots of people discussing the current state of PhpWiki, the features, test coverage and the development process.
>
>Unfortunately, I do not see many positive contributions.
>- I do not see many contributors sending in patches.
>- I do not see many contributors sending in test results.
>
>How many people have downloaded the 1.3.11-rc/beta and tested it?
>
>Projects like PhpWiki do not progress by people emailing in complaints about process, state or features (unless they are bug
>reports). Work gets done by people working on it. Reini has done a huge amount and few others have done even a fraction of that.
>  
>

I agree completely. Reini has done a great job, and is doing the 
majority of work by FAR.

I even have CVS access. The first thing I'd do is go and rip out as much 
code as I could! Most of the back-ends, half the user authentication 
options. Whatever things people email the list with questions about all 
the time. Doing a few things well is much more important than doing a 
lot of things.

However, I don't think Reini wants me to do that, and I certainly don't 
want to ruin his project. Thus, since I disagree fundamentally on the 
goals of PhpWiki, I am not motivated to contribute. I don't want to fix 
bugs in the tons of features, because I think their very number 
guarantees more bugs in future, and the project will get weaker and 
weaker and fade away.

Thus, I sit back and "complain", hoping the style will change to one I 
can more enthusiastically support and work on.

Dan

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

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

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.


Yep.

> | Finally, I believe this goal would be aided if there were much less 
> code
> | to maintain. For example, support only one backend.


> About backend, I really like the "large" choice of backends. But maybe
> the persistence abstraction layer is not that good ... that means too
> much work in the backend layer ...
> Maybe we should keep only one SQL library (ADODB ? PEAR ?) ... but we
> shouldn't drop flatfile, cvs, dba, etc ... they are very important, make
> the install process very simple in most cases ...


See, I completely disagree. Why keep flatfile and cvs and dba? I've seen 
Reini wasting time answering people who email the list, "Probably dba is 
not installed on your system" etc. Why not just keep ONE of flatfile, 
cvs and dba? Why keep all 3? You have not made a strong case.

All the back-ends cost a TON in support, both development and even more 
on the mailing lists and in user frustration. This contradicts your 
"release early and often" above. Rather, make one or two back-ends work 
really well.


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


We should first reduce the support load and focus on what PhpWiki does 
best, whatever that is.

Dan

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

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

Thus spake "Reini Urban":
> >
> > About backend, I really like the "large" choice of backends. But maybe
> > the persistence abstraction layer is not that good ... that means too
> > much work in the backend layer ...
> > Maybe we should keep only one SQL library (ADODB ? PEAR ?) ... but we
> > shouldn't drop flatfile, cvs, dba, etc ... they are very important, make
> > the install process very simple in most cases ...
> 
> IMHO that's not the problem.

I agree. In the past six months, how many commits have there been to
the database backends? Hardly any, proportionally. The bugs are elsewhere.
 
> > 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 ?
> 
> We have 4 admins!
> A lot of people have write access!
> But almost nobody helps out.

Speaking for myself, I work on things here as a break from my other work;
that usually confines me to working sporadically on small things. One thing
that would make me more productive is if I had a better idea of what others
are working on, so as not to duplicate effort. There's a page for that in the
wiki on SF, but it's not kept up to date; same story with the task list.

As soon as I get time again, I'll probably make another attack on the bug
list. If someone gave me a prioritized list of bugs to squash, that too
would help me in directing my efforts.

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

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

> I've lately completed a CAPTCHA, which is extremely easy to integrate
> even if you don't have years of PHP experience.
>    http://freshmeat.net/p/captchaphp
> While allowing you to keep your Wiki open, it's still a bit anti-Wiki to
> use captchas; but as last resort I would recommend it.

I'll look into that after 1.3.11
Thanks for the recommendation.

It would fit into the new email correspondation scheme I wanted to
integrate, but didn't finish yet.
  ModeratedPage, PageChangeNotification refactoring.
-- 
Reini Urban
http://phpwiki.org/   http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] PhpWiki process

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

> Manuel VACELET wrote:
>> I haven't downloaded 1.3.11 beta because I don't have CVS access
>> and I  currently don't have many time for this job.
>
> Charles said to me in private that coresponding tarball is available in
> File Releases on Sf.
> I only read phpwiki HomePage (where each release are announced), it
> could be a good idea to add a link on this page isn't it ?

RC1 is only for developers,
to gather some constructive feedback about remaining issues.

But since it's officially published via the sf.net release system,
the link is be automatically there.

http://sf.net/projects/phpwiki/
=>
PhpWiki 1.3 (current) phpwiki-1.3.11_rc1 March 27, 2005  -   Download
-- 
Reini Urban
http://phpwiki.org/   http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] PhpWiki process

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

Manuel VACELET wrote:
> I haven't downloaded 1.3.11 beta because I don't have CVS access and I 
> currently don't have many time for this job.

Charles said to me in private that coresponding tarball is available in 
File Releases on Sf.
I only read phpwiki HomePage (where each release are announced), it 
could be a good idea to add a link on this page isn't it ?

manuel

-- 
# VACELET Manuel     manuel.vacelet-abecedaire(at)st(dot)com #
# Tel:  042 6089                          +33 (0)476 92 6089 #
# STMicroelectronics - HPC/STS                               #
# 850, rue Jean Monet - 38926 CROLLES CEDEX - FRANCE         #

Re: [Phpwiki-talk] PhpWiki process

[Stefan <son...@ba...>]

Hello Manuel,

i use your TocPlugin and it works much better than the CVS Version. 
Thanks for that.

I've tried nearly every cvs version since 1.3.x and had a lot of 
problems with newer versions to get them run again. I told some time 
before there should be a stop with new features until the old features 
do work at all. We do have plugins over plugins but on every end 
something did'nt work.  I'am always looking for workarrounds to do the 
things my users need. Now i use 1.3.10 and some plugins from 1.3.11 some 
handmade changes etc. not really a version out of the box :-)

But i have to say i've tried some other wikis also and phpwiki is fast 
and it works. You can make changes you like (if you understand the code) 
and now it's the system of my choice. Thx to the devoloppers for the 
time they spend to make it work ...

Our wiki now has about 11.000 Pages with a lot of tables, pictures etc. 
and no other wiki made it possible like phpwiki do.

here are some page examples:
http://www.mineralienatlas.de/phpwiki/index.php/Elemente
http://www.mineralienatlas.de/phpwiki/index.php/Achat
http://www.mineralienatlas.de/phpwiki/index.php/Uranocircit

i like this wiki!

Regards Stefan

Manuel VACELET schrieb:

> Hello Charles,
>
> Charles Corrigan wrote:
>
>> There are lots of people discussing the current state of PhpWiki, the 
>> features, test coverage and the development process.
>>
>> Unfortunately, I do not see many positive contributions.
>> - I do not see many contributors sending in patches.
>> - I do not see many contributors sending in test results.
>
>
> I read this list since July 2004 because I integrated phpwiki in a 
> "forge" (comparable to GForge).
> We choose PhpWiki against MediaWiki for many reasons (modular design, 
> syntax, ...) and after 4 month in production we are very happy with 
> our initial choice: it works _really_ fine.
> I make few patch in phpwiki code (mainly on database backend) and I 
> contributed to CreateToc plugin but my patch was not integrated.
>
>> How many people have downloaded the 1.3.11-rc/beta and tested it?
>
>
> I haven't downloaded 1.3.11 beta because I don't have CVS access and I 
> currently don't have many time for this job.
>
> Again, we founded phpwiki very easy to adapt to our environnement.
> Next developments planned are:
> * migration to 1.3.11 (stable !!)
> * clean our source code
> * contribute to Gforge PhpWiki plugin
>
> My 2 cents,
> Manuel
>

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

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

> 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 ?
>
> I think opening a svn repository for phpwiki is a good thing. With https
>  access everyone can access to source code (even if you are barbarian
> proxy).

sf.net does not support svn and I doubt that svn is easier than cvs.
(for starters)
if some patchset orientated RCS, than arch and not svn IMHO.

but anybody can open another repo (maybe gforge based) with synced
versions of the src tree. but dont underestimate the hardware power of
sourceforge. (re software we all probably agree the gforge is much better)
-- 
Reini Urban
http://phpwiki.org/   http://xarch.tu-graz.ac.at/home/rurban/