Development talk:Wiki requirements
What about wrapping the already existing bits of Moodle together to create a new wiki (oh, no...not another wiki) My thinking is that we already have the following tools:
- a "standard" markup (Markdown)
- several ways to store attachments/images/binary files in various modules
- filters for multimedia, Latex, Math and the like.
Could these instances be refactored and refined then called from the wiki parser? This would avoid re-inventing the wheel(s) and simplify maintanence of system. I guess I'm suggesting a "plugin" mechanism where each of these tools could be added to Moodle and then assembled to form the wiki rather than create a monolithic and eventually cumbersome script. If all wiki pages are simply text, the wiki script will just dole out portions of each page to the proper tool. I'm imagining these tools could be used everywhere in Moodle, rather than being specific to the wiki...kind of following the unix philosophy of assembling several simpler tools to perform complicated tasks. Looking at Martin D's post outlining the must-have features, he alludes to this approach when discussing Mediawiki. Posts in other discussions have as well.
Regarding feature ideas, I would recommend folks look at Uniwakka. This "academically oriented" wiki engine has some great possibilities including support for MathML (better than latex filter for sophisticated maths?), Latex, chemistry (a personal favorite), and bibliographies; it exports/imports OpenOffice documents directly and exports Latex versions of the pages. Veeerryy nice!
Thoughts?
~Steve
These are interesting thougts Steve, in fact it was my fisrt idea twio years ago when I longed to develop tools for the current wiki. But teh coding and features of the current wiki convinced me that we needed a new wiki from scratch. I vbeliebe that the aproach you propose can be implemented once we have the DFWiki up and official.
By the way we are already working on a wiki parser compilant with mediawiki, comming soon .
Ludo - DFWikiteam
The features I find myself often missing in the current Moodle Wiki are:
- editable sections/sub-pages
- in history: ability to compare two arbitrary versions
These are things I have grown used to in MediaWiki.
In the markup department I'd like to see:
- at minimum: a basic wiki-like markup as the default
- optionally: ability to define your own markup
- optionally 2: ability to define what if the default markup
I find that most cases people will use the default markup. I don't use the Markdown format although I hear great things about it from people who do use it. I wouldn't want to make the users at our site transfer to Markdown, when I didn't even mention it in the basic training sessions they participated in.
~Jussi
I have used a number of different wiki systems and some of them with students. I've tried TWiki and found that students with no knowledge of html take to it quite readily (and do understand the wiki way of makinglinks). I use different versions of Tiddlywiki but the markup drives me bonkers (eg because links use | you cannot encluse a URL inside a table). I have also helped faculty use the Moodle wiki (Moodle v 1.5.1) for class but what I don't like about it is the html editor approach. A student actually managed to crunch the wiki at one point with mangled html code pasted in from MS Word which was then edited! My favourite and what I consider to be the most flexible markup system is Xilize which at version 2 is powerful strong. There's a plugin for Jedit which I use to create web pages.
Personally, I hope that the Moodle wiki behaves more like a 'traditional' wiki with CamelCase links and a default markup system that's easy to comprehend and orthogonal (I don't much like the accent on quotes in Markdown).
For me the selling point of Moodle wiki for use in a course is the flexibility of access control -- one can configure it to be individual access or group access, etc etc. If it defaulted to a wiki like markup and were more stable (especially with Postgres back end) I and many faculty would be happy campers.
~Markpea 25 Jan 2006
I think you should either put the same information that you find in this link or the link itself in the wiki part of the documentation. I needed to know about the markup used in Moodle's wiki, and it would be nice if it were laid out right here.
I didn't know if it were more appropriate to link to this previous documentation, or if it would be better to re-create it.
Thank you, atw
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...
This summer three of us will apply a re-engineering process to adapt NWiki to Moodle standards, solve incoherences and improve architecture.
