From: Philip J. H. <ph...@po...> - 2005-03-30 14:34:04
|
I've been running phpwiki for several years on my site http://www.hollenback.net. I started with the 1.2 phpwiki and have upgraded several times. Currently I'm running a cvs version from some time after the 1.3.10 release. I've always been a big supporter of phpwiki and have always appreciated the work everyone has put in to it. But now, I'm at a crossroads: I'm pretty seriously considering migrating my whole site (600+ pages) to PmWiki. Here's why: 1. The phpwiki development model is broken. Particularly over the last year, I have seen a tremendous amount of new, potentially cool features added to phpwiki. However, many of these features are broken in various ways, and some just don't work at all. Based on my use of phpwiki, the buginess of the code base has increased significantly. To phpwiki's credit, I've never really seen a data corruption bug. Instead, most of the problems I see are things like plugins that don't work with certain themes, random odd error messages on pages, etc. I think new features are fantastic. However, the lack of a stable phpwiki release is really, really hurting phpwiki. I know that a 1.3.11 release is very close and that is a good step in the right direction. However, the problem of all these new, not very well tested features will remain. 2. Wiki spam is a major problem. I finally had to turn off editing of my site last week. The reason: large amounts of wiki spam. For the last year, I've been getting perhaps one or two spam attacks a week on my site. I managed that by removing or reverting pages manually, not a big deal. However, last week someone created 500 spam pages on my site. I was able to remove them via the admin interface, but it was a very slow process. Clearly manually removing pages is not an effective answer for that level of wiki spam. I realize that the spam problem is not unique to phpwiki. However, I'm not seeing anything being done to address it. For example, ip address blocking is not implemented in the phpwiki version I am running. Obviously that's not a particularly effective way to deal with spam, but it is a start. What about blacklists such as the ones from chongqed.org or Movable Type? Captchas? Typekey? I'm guessing that if I'm having these problems, lots of other people are too. What is being done in phpwiki to deal with the spam problem? These issues bring me to the point of considering changing over from phpwiki to pmwiki. I'm not saying that pmwiki is necessarily better than phpwiki, but I think it is more on-track than phpwiki. I've set up several wikis based on pmwiki and I've found it to be reliable and relatively bug-free. However, it definitely does not support the range of features that phpwiki does. I'm not writing this to bash on phpwiki. It's a great tool, and I really appreciate the work people have done on it. All I'm trying to say here is that the problems with phpwiki are making me consider moving to a different wiki. This change will not be easy, as I will have to write up a parser to convert all my existing pages and deal with lots of little details. At this point, I don't see a lot of other options. Thanks, P. -- Philip J. Hollenback ph...@po... www.hollenback.net |
From: Dan F. <dfr...@cs...> - 2005-03-30 14:56:45
|
Philip J. Hollenback wrote: >I've been running phpwiki for several years on my site >http://www.hollenback.net. I started with the 1.2 phpwiki and have >upgraded several times. Currently I'm running a cvs version from some >time after the 1.3.10 release. > >I've always been a big supporter of phpwiki and have always appreciated >the work everyone has put in to it. But now, I'm at a crossroads: I'm >pretty seriously considering migrating my whole site (600+ pages) to >PmWiki. Here's why: > >1. The phpwiki development model is broken. Particularly over the last >year, I have seen a tremendous amount of new, potentially cool features >added to phpwiki. However, many of these features are broken in various >ways, and some just don't work at all. Based on my use of phpwiki, the >buginess of the code base has increased significantly. To phpwiki's >credit, I've never really seen a data corruption bug. Instead, most of >the problems I see are things like plugins that don't work with certain >themes, random odd error messages on pages, etc. > >I think new features are fantastic. However, the lack of a stable >phpwiki release is really, really hurting phpwiki. I know that a 1.3.11 >release is very close and that is a good step in the right direction. >However, the problem of all these new, not very well tested features >will remain. > > I agree with all of this. Stability, fully functional, easy to use, well-documented features are very important, more important than most new features. It is a lot of work to take a feature from "a good first shot" to easy to use and obviously great. Releasing more often is probably also important. Finally, I believe this goal would be aided if there were much less code to maintain. For example, support only one backend. I see so much work going into different database ports, needlessly. I vote for MySQL, since that is what I am using. However, I might even go with a CVS backend (*shudder*) if that were the community's will, as long as it supported query-able relationships between 2 things (exactly like backlinks, or we've expanded also to ratings, categories, and in the future perhaps list items), and multiple instances from the same code base (currently with multiple MySQL DBs). >2. Wiki spam is a major problem. I finally had to turn off editing of >my site last week. The reason: large amounts of wiki spam. For the >last year, I've been getting perhaps one or two spam attacks a week on >my site. I managed that by removing or reverting pages manually, not a >big deal. > >However, last week someone created 500 spam pages on my site. I was >able to remove them via the admin interface, but it was a very slow >process. Clearly manually removing pages is not an effective answer for >that level of wiki spam. > >I realize that the spam problem is not unique to phpwiki. However, I'm >not seeing anything being done to address it. For example, ip address >blocking is not implemented in the phpwiki version I am running. >Obviously that's not a particularly effective way to deal with spam, but >it is a start. What about blacklists such as the ones from chongqed.org >or Movable Type? Captchas? Typekey? I'm guessing that if I'm having >these problems, lots of other people are too. What is being done in >phpwiki to deal with the spam problem? > > To be fair, Reini put in two things, and I believe they are in RC1 (aiming at 1.3.11 if all goes well): 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. 2. Hook up with babyspam, which is a hookup to Spam Assassin. In other words, an evolving tool for detecting spam. 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. >I'm not writing this to bash on phpwiki. > I think you do a service to state the things you really need. Dan |
From: Philip J. H. <ph...@po...> - 2005-03-30 17:13:17
|
On Wed, 30 Mar 2005 08:56:02 -0600, "Dan Frankowski" <dfr...@cs...> said: > Finally, I believe this goal would be aided if there were much less > code to maintain. For example, support only one backend. I see so much > work going into different database ports, needlessly. I vote for > MySQL, since that is what I am using. However, I might even go with a > CVS backend (*shudder*) if that were the community's will, as long as > it supported query-able relationships between 2 things (exactly like > backlinks, or we've expanded also to ratings, categories, and in the > future perhaps list items), and multiple instances from the same code > base (currently with multiple MySQL DBs). I heartily second that. I suspect deciding one one backend might be politcally extremely difficult. It sure seems like something that needs to be done. One thing I really like about PmWiki is it avoids the whole database question entirely by just storing pages as textfiles. Have you ever tried to configure mysql on a hosted system? It can be extremely annoying (or extremely easy, depending on the provider). But there's no doubt that lots of the bug fixes have been for the various database engines. Perhaps the real core of the problem with phpwiki is _too much_ choice. All these choices result in a combinatorial explosion of bugs. For example, I use the Crao theme on my website. It turns out that there are a number of phpwiki functionality bugs (like you can't delete pages) that happen only with that theme. Ugh. > >I realize that the spam problem is not unique to phpwiki. However, > >I'm not seeing anything being done to address it. For example, ip > >address blocking is not implemented in the phpwiki version I am > >running. Obviously that's not a particularly effective way to deal > >with spam, but it is a start. What about blacklists such as the ones > >from chongqed.org or Movable Type? Captchas? Typekey? I'm guessing > >that if I'm having these problems, lots of other people are too. > >What is being done in phpwiki to deal with the spam problem? > > To be fair, Reini put in two things, and I believe they are in RC1 > (aiming at 1.3.11 if all goes well): > > 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. Obviously the spammers will adapt to that by creating lots of pages, each with only a couple of links. Then we will need a mechanism to rate-limit the creation of pages, etc. The never-ending spam battle. Actually, I'd like to see rate-limiting for page creation now. Maybe no more than one page every 30 seconds, by default? > 2. Hook up with babyspam, which is a hookup to Spam Assassin. In other > words, an evolving tool for detecting spam. > > 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. Right now I kind of feel like each upgrade to phpwiki is like Christmas. Lots of exciting presents, but you never have any idea what you are getting. Thanks, P. -- Philip J. Hollenback ph...@po... www.hollenback.net |
From: Reini U. <ru...@x-...> - 2005-04-01 17:25:01
|
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 |
From: Arnaud F. <ar...@cr...> - 2005-03-31 16:27:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Frankowski wrote: | Stability, fully functional, easy to use, well-documented features are | very important, more important than most new features. It is a lot of | work to take a feature from "a good first shot" to easy to use and | obviously great. | | Releasing more often is probably also important. "Release early, release often" .. That's one of the main bazaar rules. It's really important for the developpement to go nicely. | Finally, I believe this goal would be aided if there were much less code | to maintain. For example, support only one backend. I see so much work | going into different database ports, needlessly. I vote for MySQL, since | that is what I am using. However, I might even go with a CVS backend | (*shudder*) if that were the community's will, as long as it supported | query-able relationships between 2 things (exactly like backlinks, or | we've expanded also to ratings, categories, and in the future perhaps | list items), and multiple instances from the same code base (currently | with multiple MySQL DBs). 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 ... 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 ? Arnaud -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCTCTryAf3wgFyy1ARAhYsAKCsjDUUg/XMz/LPjADubXumN8hHrwCgjLKQ bmKHch10qY8HurDDHEpSNOc= =UyPK -----END PGP SIGNATURE----- |
From: Reini U. <ru...@x-...> - 2005-04-01 08:16:27
|
> | Releasing more often is probably also important. > > "Release early, release often" .. That's one of the main bazaar rules. > It's really important for the developpement to go nicely. I don't feel comfortable with releasing bad stuff. And I empathize with the administrators who have to update their wikis. > | Finally, I believe this goal would be aided if there were much less > code | to maintain. For example, support only one backend. I see so much > work | going into different database ports, needlessly. I vote for > MySQL, since | that is what I am using. However, I might even go with a > CVS backend | (*shudder*) if that were the community's will, as long as > it supported | query-able relationships between 2 things (exactly like > backlinks, or | we've expanded also to ratings, categories, and in the > future perhaps | list items), and multiple instances from the same code > base (currently | with multiple MySQL DBs). > > 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 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. -- Reini Urban http://phpwiki.org/ http://xarch.tu-graz.ac.at/home/rurban/ |
From: Manuel V. <man...@st...> - 2005-04-01 08:17:40
|
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). -- # 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 # |
From: Reini U. <ru...@x-...> - 2005-04-01 08:24:48
|
> 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/ |
From: Matthew P. <mp...@he...> - 2005-04-03 17:24:11
|
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 |
From: Daimonin M. <in...@da...> - 2005-04-04 09:03:26
|
> -----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. |
From: Dan F. <dfr...@cs...> - 2005-04-01 14:34:10
|
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 |
From: Joel U. <uck...@no...> - 2005-04-01 14:52:05
|
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. |
From: Reini U. <ru...@x-...> - 2005-04-02 14:48:19
|
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 |
From: Matthew P. <mp...@he...> - 2005-04-03 17:23:00
|
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 |
From: Jim C. <ji...@in...> - 2005-04-04 03:37:12
|
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 |
From: Arnaud F. <ar...@cr...> - 2005-04-01 15:01:51
|
-----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----- |
From: Matthew P. <mp...@he...> - 2005-04-03 17:24:35
|
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 |
From: Arnaud F. <ar...@cr...> - 2005-04-03 18:22:43
|
-----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----- |
From: Matthew P. <mp...@he...> - 2005-04-04 06:54:09
|
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 |
From: Reini U. <ru...@x-...> - 2005-04-04 06:08:37
|
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 |
From: Matthew P. <mp...@he...> - 2005-04-04 07:30:04
|
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 |
From: (YOD) <yo...@pn...> - 2005-04-01 16:04:59
|
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 |
From: Dan F. <dfr...@cs...> - 2005-04-14 14:49:22
Attachments:
patch.txt
|
I tried to send this, and Sourceforge bounced it. Now, a week later, let me try again. Dan YOD, 90% of the code I took from editpage.php in CVS current of PhpWiki, thanks to Reini. The 10% was two changes: 1. Modify the end-user error message to say "Sorry, too many links (more than ##)" instead of "conflicts". 2. Add a configurable parameter SPAM_MAX_EXTERNAL_LINKS. Below is an approximate patch to editpage.php. Since we are almost a year different from Phpwiki, I cannot guarantee that the patch is entirely accurate. Also, I sent this patch to this list awhile ago. Perhaps I should also change it in CVS current? Dan (YOD) wrote: >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 > > > > > > >------------------------------------------------------- >This SF.net email is sponsored by Demarc: >A global provider of Threat Management Solutions. >Download our HomeAdmin security software for free today! >http://www.demarc.com/Info/Sentarus/hamr30 >_______________________________________________ >Phpwiki-talk mailing list >Php...@li... >https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > |
From: Reini U. <ru...@x-...> - 2005-04-14 16:43:50
|
> 90% of the code I took from editpage.php in CVS current of PhpWiki, > thanks to Reini. The 10% was two changes: > > 1. Modify the end-user error message to say "Sorry, too many links (more > than ##)" instead of "conflicts". > 2. Add a configurable parameter SPAM_MAX_EXTERNAL_LINKS. > > Below is an approximate patch to editpage.php. Since we are almost a > year different from Phpwiki, I cannot guarantee that the patch is > entirely accurate. > > Also, I sent this patch to this list awhile ago. Perhaps I should also > change it in CVS current? I'd rather stay with the hardcoded number of 20 maxlinks. This sounds useful to me, after a lot of analysis and I don't want admins to play with that sensible number, unless they know what they are doing. Then they can simply fix the source. And I want to give shorter and exact answers on typical support questions. "Don't do more than 20 links in a new page or you are considered a spammer." sounds better than "Don't do more than SPAM_MAX_EXTERNAL_LINKS links (ask your administrator how much exactly ) in a new page or you are considered a spammer." > (YOD) wrote: >>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. -- Reini Urban http://phpwiki.org/ http://xarch.tu-graz.ac.at/home/rurban/ |
From: Dan F. <dfr...@cs...> - 2005-04-14 18:43:04
|
Reini Urban wrote: >>90% of the code I took from editpage.php in CVS current of PhpWiki, >>thanks to Reini. The 10% was two changes: >> >>1. Modify the end-user error message to say "Sorry, too many links (more >> than ##)" instead of "conflicts". >>2. Add a configurable parameter SPAM_MAX_EXTERNAL_LINKS. >> >>Below is an approximate patch to editpage.php. Since we are almost a >>year different from Phpwiki, I cannot guarantee that the patch is >>entirely accurate. >> >>Also, I sent this patch to this list awhile ago. Perhaps I should also >>change it in CVS current? >> >> > >I'd rather stay with the hardcoded number of 20 maxlinks. >This sounds useful to me, after a lot of analysis >and I don't want admins to play with that sensible number, >unless they know what they are doing. >Then they can simply fix the source. > > Okay. For us, we have internal (password-protected) wikis, and I thought we might want to set the # of links very high. Of course, we could probably just disable spam protection altogether. >And I want to give shorter and exact answers on typical support questions. >"Don't do more than 20 links in a new page or you are considered a spammer." >sounds better than >"Don't do more than SPAM_MAX_EXTERNAL_LINKS links (ask your administrator >how much exactly ) in a new page or you are considered a spammer." > > For sure you are right. In my code, I print out the actual #, not the constant name. Dan |