Having the front page(s) read-only saves me some hassle and makes the site more robust for readers... all the rest of the site is writable.. yet - it irks me. Maybe others too ? Does it scare off newcomers ? Does it harm the wiki ambience ? It seems strange that one read-only page could have this effect, and yet I think it can.. or perhaps it's more the uncertainty factor. (Will I still be able to edit this page when I come back next week?). .

Thoughts ?

I'm thinking that if you must restrict write permission on a page, perhaps a reason and a list of who has write access should be displayed, to best preserve transparency and trust.

--SimonMichael


(Raising megaphone) MeatBall:KeptPages! (thank you.)

er yes.. some good options there.

What are your priorities? How much damage are you prepared to deal with? How often have other people made appropriate edits to the front page?

Personally, if the front-page write restrictions were removed I'm not sure I'd ever visit ZWiki from my workplace PC. (Fortunately, the redirected target was not blocked/reported by our corporate filtering-firewall.) I'd also advise others to avoid this site in any situations where pornography could get one in trouble.

Kept pages will not protect against Javascript or some other attacks. While it is simple to eliminate the SCRIPT tag, it is less easy to filter out scripting from other HTML elements.

If you and your users are willing to accept cookies, you could give write access to all pages to almost everyone. The wiki could send a new cookie on one's first edit containing a user-ID number, and store the time and IP address in a table keyed on the uid#. For restricted pages like the front page (and maybe RecentChanges? and the help pages), one would allow full write access to anyone with a cookie that is at least X hours old (X could range from 12 to 72 hours). Newer users could still edit most pages, and would automatically become "trusted" after enough time elapses. In case of abuse, one could remove the DB entry for the user-ID (and possibly others with similar IPs? and times).

Another possibility would be a "submission" process in which one can edit a page, but the edited version must be approved before it becomes public. This would work much better if multiple people could approve submitted edits.

Yet another possibility is password protection, with the password obtainable through email to the administrator. You could even keep a list of highly trusted editors, and email them if the password is changed.

Perhaps write restrictions are against the spirit of a "wiki". In that case, do you really want a wiki? --CliffordAdams (who doesn't consider his future ViewPoint? project as a wiki)

You may also want to read MeatBall:RawHtmlWiki . Allowing any sort of unparsed HTML is deadly. You can easily burn people with rollover properties, for instance, as I recently did to Cliff when he put raw HTML in his test wiki. Besides, I'm not sure it is against the wiki way to limit the markup. That seems very much along the lines of wikis, actually.

If you need to do special HTML tricks, perhaps it would be best to the generate the page outside of the normal wiki parser, such as you do with RecentChanges?. In that case, the current set up you have here doesn't seem out of line ethically; however, the perception of the community may be unpleasant as it is clear that certain members of the community are more equal than others.

That being said, if the FrontPage was merely composited from other editable pages, maybe this isn't too bad. You would need to add more protections to ZWiki in order to prevent disaster to FrontPageNews?. Then again, keep in mind that WikiWikiWeb is extremely high traffic yet its FrontPage routinely survives vandalism. On the other hand, WikiBase?'s FrontPage gets irrevocably destroyed every couple of months. --SunirShah.

Personally, if the front-page write restrictions were removed I'm not sure I'd ever visit ZWiki from my workplace PC.

Hmm, another point of view - thanks Clifford. I think some of these unobtrusive safeguards (eg the cookie-based approach you describe) are going to be useful.

Raw html/javascript can be abused, no doubt. A busy site might choose to go with classicwiki mode for a simpler life. I wonder though how hard it would be to filter out all possible hostile html - script tags, dodgy looking properties, redirects, etc. --SimonMichael