ZWiki supports a hierarchical view where pages have a parent page. Sometimes this breaks and pages disappear from such listing, in which case you should visit FrontPage/updatecontents ; or (last resort) remove the 'outline' cache file in the ZMI (Zope Management Interface).
The basic protection ZWiki offers is the have users set a username (via a cookie).
Properties on the wiki folder:
- edits_need_username = true - cf. http://zwiki.org/LinkSpam
- max_anonymous_links = 10
- mail_replyto = INVALID.NOREPLY@gnu.org - cf. http://zwiki.org/HowToSetUpMailOut
- mailout_policy = edits
sm from #zwiki suggest the following workflow:
My usual policy is: anonymous can edit, though I lock down key pages occasionally; edits need username; I and others subscribe to the wiki "all edits" so we'll notice spam; if I get a spammer using a username, I'll revert it manually with revertEditsEverywhereBy; if they persist I'll block their ip address with apache (and unblock some time later).
That's been working pretty well for a while.. I haven't had a really persistent hostile attack for some time, if I did I would make the whole thing read only for a while and consider next steps.
Also, I try hard not to let spam links get a foothold in the wiki, or they will attract more.
Reviewing the all-edits mails once in a while is important.
A "revert" URL looks like: .../maintenance/FrontPage/expungeEditsEverywhereBy?username=Xyz Beware, there's no confirmation. One can add &batch=50 if it ever has trouble completing due to conflicts. This command is restricted to Managers. It currently doesn't work for renames, though this should be fixed soon.