Archive note
Building a wiki with Drupal, one decision at a time
A calm checklist for teams that want shared, versioned pages without leaving their existing content system.
A wiki is less a feature than an agreement. The software can store pages and revisions, but the useful part is a group of people deciding how to write together. Drupal can support that agreement if you make a few choices on purpose.
Decide what a page is
Start with one content type for shared pages. Give it a clear name, a short description, and only the fields the group will actually fill in. Every extra field is a question someone has to answer before writing, and most of those questions can wait.
If the pages form a hierarchy, decide how deep it should go. A flat list is easier to search. A tree is easier to browse when the material has a natural order. Pick one and write it down, because the structure will drift as soon as two people disagree.
Revisions are the safety net
Turn on revisions before the first edit, not after the first accident. A revision history lets people be bold. They can fix a sentence, restructure a section, or remove outdated material without fearing that the old version is gone forever.
Add a short edit summary field. It costs a few seconds and saves a long conversation later when someone asks why a paragraph disappeared.
Permissions should match trust
Not everyone needs the same rights. A useful starting point is: everyone can read, a known group can edit, and a smaller group can change structure or delete pages. Keep the groups visible and review them when the project changes.
If a permission is hard to explain in one sentence, it is probably doing two jobs. Split it.
Write the editing conventions
The software will not tell people whether to use sentence case, how to title a page, or when to split a long article. Write those rules in a page that is easy to find. Keep the list short enough to read in a minute.
A good convention answers a real question that came up in editing. A convention invented in advance for a problem nobody has is clutter.
Plan for search and for leaving
Shared pages are only useful if people can find them. Check the search result for a phrase a newcomer would use. Add redirects when a page moves. Keep a simple index page for the main areas.
Finally, decide how the content could leave. A wiki that can export clean text or structured data is easier to trust. Lock in is a quiet cost that shows up years later. The MediaWiki project is worth studying for how a mature wiki documents its own conventions.
A short launch list
- One page type with a short field list.
- Revisions enabled and visible.
- Two or three permission groups with clear names.
- An editing guide that fits on one screen.
- A search test using a newcomer's wording.
None of this is exotic. The point is to make the agreement explicit, so the software supports the group instead of defining it.