Wiki requirements

Moodle wiki purpose

To provide a way for students, teachers and other Moodle participants to create an organic, on-line document collaboratively.

Key features

Pages can be created and linked using simple wiki methods.
All Moodle text formats can be supported.
Editing and viewing can be restricted by Moodle roles (i.e. currently: Students, Groups, Teachers).
Images can be easily inserted into the text of a wiki.
Attachments can be made to wiki pages.
Must be fully compliant with Moodle backup and restore.
Must be fully compliant with Moodle logging and activity tracking.
Must provide a method of grading (see assignment module). Grading should be optional on a per-wiki basis.
Allow importing of external documents to create a wiki or add to an existing one.
Allow exporting to an external document.
Allow refactoring/moving/deleting pages with appropriate permissions.

(from Martin's list):

Basic Operation

Create the wiki:- Log in/ Turn editing on/ Add and activity/ Wiki - Fill in wiki parameters (Leave defaults and experiment later. Everything except the inital page fields can be changed.)

Adding pages:

- Edit the first (& only page)/ Type the name of the new page you want within square brackets/ Click Save. The new page link is displayed beside a question mark./ Click the question mark to open the new page for data entry.

- pages can be added from any page. (Suggestion: On your start page, type "PageIndex" and perhaps "Site Map" and/or "Newest Pages" so that the user is alerted to these options immediately on entering the wiki. They also appear on the "Choose wiki links" drop down at the top of the wiki window.

The wiki is one of the most powerful tools within moodle and suitable for many educational & administrative functions including:

a wonderful way to encourage students to build, debate and share a summary of their course content as they work
a great way to deliver your school administrative manuals i.e. teachers manual; student manuals. They are searchable, interlinked automatically & able to be continuously updated showing who, when & how the updates were made.

Currently some wiki features do not work reliably:

search does not find page titles (so make sure that the page title is repeated somewhere within the page itself).
export does not export all wiki content
delete pages and strip pages often do not work. (the most common error message is: Course Module is incorrect, which sometimes can be bypassed by using another theme. formal_white is known to cause such problems.)
moodle editor does not handle hyperlinks correctly. i.e. All links must be manually placed within square brackets rather than embedded as HTML links.

Design Objectives

The Wiki should support exactly the same text formats in Moodle core as you find everywhere else (see weblib.php for standard functions, eg format_text). ie Moodle format, HTML format, Markdown, etc. Any new formats need to go in the core so they are available everywhere, and this needs to be discussed very well. We only JUST removed the old Wiki-like format to reduce confusion with the current Wiki and I don't want more of this confusion from a rushed implementation.

NWiki suports old wiki format, HTMLEditor and Mediawiki  syntax --Ludo (Marc Alier) 09:50, 3 June 2007 (CDT)

Linking should support both CamelCase and [Bracket] styles, and also automatic linking on the fly (a la Glossary).

Since wikipedia abandoned CamelCase I don't think we should keep it --Ludo (Marc Alier) 09:50, 3 June 2007 (CDT)

Upgrading from the old system to any new one should be seamless and problem-free (this includes restoring old backups from 1.4, for example).

Done --Ludo (Marc Alier) 09:50, 3 June 2007 (CDT)

The idea with eWiki was to build on the work of the eWiki team in future. Unfortunately, so many hacks needed to be made to their monolithic script that this became almost impossible. I would like to see a lot of thought put into a very cleanly-designed architecture for the Wiki in future, something that is easy to extend and maintain (and also to use).

The NWiki architecture has been redesigned for this purpose See the phpdoc documentation--Ludo (Marc Alier) 09:50, 3 June 2007 (CDT)

I really like MediaWiki, as this Wiki is becoming a defacto standard (for good reason) and it would be good to be compatible in some way with it. Perhaps we can use part of it as a library for us. However, the Moodle Wiki is a COMPONENT within the larger Moodle system and has a very different focus to MediaWiki (which is designed for large standalone web sites) ... much thought should be given to making our Wiki work very closely with other modules, rather than another module that tries to do everything itself. It should do exactly what it needs to do and no more.

OK see NWiki suport for mediawiki markup

Support for media in a very clean way is a must. This is probably my biggest criticism of the current eWiki version ... attaching images and video etc is really awkward and doesn't look good.

NWiki suports this still in a weird way, but we plan to implement it just like 
mediawiki: as wiki pages. We want also to integrate media with digital repositories--Ludo (Marc Alier) 09:50, 3 June 2007 (CDT)

New wiki (old)issue list

This list is very old, we (dfwikiteam) have commented. 
Rigth now (may 07) the nwiki development plans are 
being worked out in the NWiki roadmap page. --Ludo (Marc Alier) 09:40, 3 June 2007 (CDT)

There is no userid column in the wiki_pages table (author char-string instead). Must be supported in migration too. userid has been there since June06
There is no intro and introformat in the wiki table.. I can't remember when Eloy Lafuente added these two columns... A long, long time ago...
In the upgrade from wiki to dfwiki, as there aren't userids, my wiki-pages were assigned to "guest". Once more, userid seems to be critical.. Solved. We are using userids. In case of mismatching, we assign the page to the current user.
Wikis having different wiki_entries (group or user ones) have no support in new wiki (only one simultaneous line of versions is available?) so we get a lot of duplicate version errors with data-lost of such pedagogical feature! Or am I losing anything? With only groupid and version in the UK of the table, old student wikis can fit in the new one. Once more, userid! Solved UNIQUE KEY `wiki_pages_uk` (`pagename`, `version`, `dfwiki`, `groupid`, `userid`, `ownerid`).
Search doesn't work for diacritics. And/or match is performed with case matching (I think). Search has some bugs. We hae to improve it. Minor priority.
Search seems to work against titles and contents always (no matter the checkbox was selected or no). Perhaps it's due to that usage of globals? Ah! After a second try I saw that such checkbox is to decide to show the details of the search in the body of the page. Perhaps the title should be changed to be a bit more clear? Something like "show results page" and some sort of nice help... I don't think so. I'll review it.
The useful "What links here" block isn't available. Now it is.
Wiki backup and restore don't support individual activities! Why not? Where is the problem?
Wikis aren't included in the backup/restore at all! Backup/Restore are working correctly. We have not noticed any bug.
Blocks system. Would be difficult to migrate to core block system? Migrated in May06.
UTF-8 migration always get teacher_main_language() and it should get page author language! If we know the author responsible for the version, we must look for their original encoding instead of using the teacher one! Similar to forum_posts (if I'm not wrong). And we should know the user: userid again! ;-) I'm gonna take a look to this.
In the wiki_pages table there is one "dfwiki" field. Should be "wikiid". Such name doesn't sound ok. (although it's possible that migation become painful, so we can change it in the future...). I know. Pain! It will be changed with the API integration.
dfwiki is inside a lot of places in code. It should go out (although it's possible that migation become painful, so we can change it in the future...). Yes, variables, comments... We have to clean it out.
globals, globals, globals usage should be out. Just request parameters filtered with xxxx_param() functions. There is only a big one. We are making it smaller every day.
Attachment storage (as I've seen in the old-new migration script) seems to be a bit special with a lot of "dfwikiXXXX" dirs generated. I made a script to rename all these dirs.
The old-new migration script seems to be twice, once under the wikimigrate dir (the used one) and under the mod directory (unused?). I gonna bet for duplicated code...

Documentation