[Edit]Overview

Most wiki systems all any user to put anything into the system. However for some of the wiki's I'm looking to build, there are issues with 100% open access.

[Edit]Motivation

My client has a need to allow various groups and departments to submit information and/or change the content in pages. However we have departmental content authors that verify and organize this submitted content. In worst case scenarios, it would be bad overall for us to have a disgruntled employee submit profanity all over the page for everyone to read before our content authors had a chance to remove it.

[Edit]Philosophical Debate

This proposal works directly against the original intent of a wiki system to some degree. The point here is to have open collaboration from many source. However there are some groups that cannot do this no matter what. Large corporations cannot open expose themselves to non-validated submitters putting up topics like racial slurs. So if anyone has a better suggestion for achieving the same goal, please put it here! :)

Just thought of something this morning as well. If I as a wiki builder go through the trouble of setting up a nice organizational structure to the wiki with quality content, etc, then what is to prevent someone else from coming through and reorganizing/wrecking the existing one?

[Edit]Proposed Solution

I build a system like this for companies in the past where we had a “staged” content page. The page content was modified by:

1. making a database record copy of the existing page with a “parentId” field referencing the original (current) page.
2. updating the content, from the submitter, in the copied page record

This keeps the current page with the current key, the page name in this case. However when a content reviewer agrees that the new content looks good, they can launch the updated page to the site. Internally this would:

1. delete the existing page from the database
2. update the copied page with the database key (page name) from the original page

[Edit]Caveats

Then all the references to the page would be intact. This system would work to some degree for a wiki, but there are some caveats:

• in my design, the business only had 1 copied page at a time because of the nature of their business. However in a wiki model, there may be 2 or more page submissions before a reviewer could “launch” a page. This brings in the possibility of a required merge.
• During the delete/update process, the rows, or table, would need to be locked. It wouldn’t be locked long, but still would halt any other DB queries against the same row/table.