Course is over and all students taught by my Ludo have presented their final projects. Congratulations! You all made a great job, I’m glad to have been working with you last months.
Thanks and congratulations.
This is a usual question of all beginners.
ownerid, userid and groupid are set to wiki_pages table to differentiate them when any combination of groupmode or studentmode is set.
userid is a foreign key to Moodle users table. It contains the user id who edited that wiki page version.
If the current wiki is a separated groups or a visible groups activity. groupid is set to distinguish a page called “Moodle”between the several course groups.
ownerid is used to set a property relationship between the user and a wiki page. This is needed when any student mode is set and we allow users to edit pages belonging to other people.
This is a mini how-to oriented to new NWiki developers who usually use incorrect SQL queries to access to wiki pages.
wiki_pages table has one primary key: id. If you have it, you can invoke dmllib.php functions such get_record
$page = get_record('wiki_pages', 'id', $pageid);
Several problems appear when you don’t have this id. Then you must use wiki API. There are great magic functions that recover wiki pages data from database.
If you are developing new features you must take into account that wiki_pages table has an enormous unique key:
In a normal situation you will have a pagename and a wiki id or a coursemodule id. Then, you must get coursemodule description using Moodle API.
Using these functions you will be able to look up for the groupmode of this activity instance. At this point you will know the groupmode and stundentmode combination that is set up.
Calling get_record/s with the correct fields will return the desired wiki/s.
Moodle HQ ask us two years ago to modify our DFWiki to replace default Moodle wiki. We were really excited about this opportunity. We knew that we would have to work hard, but we accepted the propousal.
We debugged our code, ewiki migration scripts were written and backups were tested one million times. But Moodle1.6 didn’t included NWiki.
Then Moodle.com send us a large TO-DO list for Moodle 1.7. There were several security issues to fix and some requirements to implements. We didn’t finish at time, all these tasks plus roles and XMLDB integration were too much.
You will get into core in Moodle 1.8. They forgot about us…
Moodle community was eager for our wiki, so somebody opened a issue in Moodle tracker to be put to the vote. NWiki got a plenty of votes. It’s the second most popular item of the site, but we still waiting…
During the last two weeks, it seemed to be some activity around this topic. Moodle.com was revising and testing our wiki. A Moodle new site was created to put NWiki to the test, but they also installed another wiki, OU Wiki. OU from Open University and Wiki to cheat community.
I installed this module one year ago and it was crashing all time. Reading Martin’s words, I thought that it have been improved and finished so I’ve been testing it few hours. What kind of wiki is it? An WYSIWYG editor with version control is not a wiki… What kind of joke is this.
Yesterday, Martin Dougiamas post this at Using Moodle forum. He said he can decide between NWiki and OU “Wiki”… I say you can decide between to please your community or to please your company. NWiki has thousands of users but, it’s box populi that Moodle.com and Open University work together to improve this CMS. It’s normal that they (OU) want to program the application core, they spent £5 million in their online learning environment!!!!
Wikis testing course include also a pair of choices. One for user-friendly experience and the other for developer-friendly code. What’s happening with the other voting, it does not count. Of course not! It was not an official voting…
I thing that comparing NWiki and OU “Wiki” is too difficult. Ours has a lot of features so it’s less easy to use. Ours has a lot of features so it has more code to read. OU’s has very/too simple so has less code (8 times less code) and is extremely easy to work with.
“It has a lot of fancy features……the code still reflects the fact that it was built by a team of students…” said Martin talking about our wiki. What’s up with you, mr. MD? Fancy features? Do you know what’s I+D+I? It’s a great work, users have technical or teaching problems and we find solutions. We are very pleased to create useful features, Moodle community said that, not me. There always is somebody that love and use these fancy features in their learning environments. Which are Moodle learning improvements of las two years? Do you really want to put social constructionist pedagogy into practice. You need a forum and a wiki. You have the first one, but you what’s up with ewiki? Everybody hates it and you are doing nothing to solve this problem.
You don’t like our code? I’m totally agree with you, it could be much better, but it works. It has some little bugs and PHP warnings but we always fix them as fast as we can. Is OU “Wiki” free of bugs? I crashed it in a minute. Can you crash ours or ewiki as fast as me?
This is a post to claim the right of our software and to work all my pent up anger down. We have nothing to worry about, Moodle huge community supports us. We will win. Otherwise, DFWiki will strike back….
Remember that you can vote for NWiki here, you only need to create an account. Thanks a lot for you time and support.
This is a guide for NWiki developers that explains step by step what they have to do if they want change NWiki database schema.
mod/wiki/db/install.xml defines NWiki database schema. This file is used during NWiki installation. It’s necessary to modify this file according to the new development.
Adding a new field is an easy job, you only need to write a line. Be aware of the fact that every field defines which is the previous and the next field, so don’t copy an xml item only modify the name.
Adding a new table or a lot of fields more hateful. I recommend to use XMLDB editor that provides Moodle. You can access to this tool from admin block.
mod/wiki/version.php contains module version. You will have to change $module->version to a new one. Version numbers are dates, so version format is YYYYMMDDVV, where YYYY is the current year, MM is the current month, DD is the current day and VV is the version number.
If I would need to change version today I would modify:
$module->version = 2008012401
Creating several versions a long the same day increments VV. Next version would be:
$module->version = 2008012402
mod/wiki/db/upgrade.php contains NWiki upgrade script. This file defines what actions must be done into database to upgrade it. This process is used when a previous version of NWiki or Moodle old wiki is installed in your system.
The objective of xmldb_wiki_upgrade function is to modify database to set it as a new installation. In other words, executing upgrade script must create the same schema defined in install.xml.
You must add conditional blocks at the end of the file such the one below these lines to alter NWiki tables:
if ($result && $oldversion < 2008011401) {
$table = new XMLDBTable('wiki');
$field = new XMLDBField('notetype');
$result = $result && drop_field($table, $field);
$field = new XMLDBField('evaluation');
$result = $result && drop_field($table, $field);
$table = new XMLDBTable('wiki_pages');
$field = new XMLDBField('evaluation');
$result = $result && drop_field($table, $field);
}
$oldversion is the current NWiki version installed in your Moodle. You must compare it with a version number. If the condition matches, modifications will be done. To alter database schema you must use XMLDB API defined in lib/ddllib.php.
If the modifications in database have repercussions in course backup, mod/wiki/backuplib.php must be adapted to create backups with the correct information.
Is possible to forget about this step if, for example, you modify wiki_locks table, creating backups of this table is useless. If you add or remove field from, for example wiki_pages, backup script must be corrected.
If you modified backuplib.php, you will have to modify restorelib.php too. This file contains the script that restores wiki instances from a backup.
NWiki also provides xml import & export scripts. They only backup content into xml files, so if you have modified wiki, wiki_pages or wiki_synonyms tables you must adapt this process to your changes.
Thats all folks! As you can see, changing database schema is not trivial, it implies a lot of work, programing and testing.
Recent Comments