From: Mario S. <ma...@er...> - 2005-03-31 15:14:41
|
Hey Philiph, I can't comment much on PhpWiki development, but I doubt that any eventual bugs couldn't be fixed. As for PmWiki, I think you're trading something robust for spaghetti code and one of the more weird Wiki markups around, if you'd really switch. Link spam is a problem that escalated only this year, so it's clear that we all first need to find "THE solution" to it. IP blocking and whatnot blacklist however seem to be more hassle than they help here. I had best results with blocking posts that contained more than a fixed number of new links. AFAIK there is already such a plugin for PhpWiki, so you should give that a try. (it's called "LimitExternalLinks" elsewhere) 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. Most link spam hits the Wikis only accidentially, and was originally targetted at BBcode- or HTML-enabled blog/comment sections. You'll need something that blocks any "/^<a.+</a>$/" edit form submissions then (also easy to do). In your case (500 edits) it however sounds like you've been attacked targetedly - in such cases no anti-spam plugin will help you and cleaning up the mess afterwards is the only solution. If you're using a SQL database - that's often forgotten - then it's a snap to wipe hundreds of pages at once, depending on a timestamp. Else you only need the right tools - the funny WikiCommander and the "mass revert" tools in the Wiki I'm working on would do. (I'm link spamming here ;) http://erfurtwiki.sf.net/tools/ Our database API is extremely simplistic, and so writing up some glue code for PhpWikis should be trivial (right now we only have a PW plugin without ::DELETE support). Whatever, I just wanted to comment that this is not a problem only PhpWiki faces, and people all around are testing and writing tools to combat link spam. And simple solutions surprisingly seem to work best. http://www.emacswiki.org/cw-de/WikiSpam mario ph...@po... schrieb am 31.03.05 06:01:17: > Unfortunately that's not really what I want. My hope is to block spam > while still allowing anonymous edits. I think that's most in keeping > with the wiki spirit, right? > > Basically I'm ok with removing occasional spam pages, as long as there > are mechanisms to prevent more extreme abuse (such as hundreds and > hundreds of spam pages added all at once). ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 |
From: Joel U. <uck...@no...> - 2005-04-01 14:30:36
|
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. |
From: Reini U. <ru...@x-...> - 2005-04-01 09:38:58
|
> 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/ |