David Scotson

I'd like to propose a third way. I don't think this will be popular (for reasons I'll outline) but think it's still worth thinking about.

In short: the OUWiki should be added to the core, but should be renamed something completely different from wiki e.g. "Collaboration" or "Hypertext" activity. The NWiki should continue to be developed as a 3rd party add-on for people who need a more traditional wiki, but can't have their needs met by installing Mediawiki alongside Moodle.

I like the OU module. It's simple and clean and effective, apparently the code is too. If you look at it from the point of view of "we need to let students create documents collaboratively" then I'd say the OU module is the answer. If you say "we need a wiki" then I don't think it qualifies. Personally, despite being a big fan of wikis in general, I think for most uses the former is more important.

But if a Wiki is required then I think wiki markup (with or without javascript-based editing help) is an essential requirement. Preferably the markup and interface would be as close to Mediawiki as possible. And this seems to be what NWiki is aiming at.

I think splitting the modules so that one has an HTML editor and no wiki-markup and the other is vice versa could save a lot of programming time and effort.

The unpopularity comes from:

• You'd effectively be killing wiki as a core module
• you'd not be able to claim Moodle core has a 'wiki' (though it would have a similar/better/easier-to-use alternative)
• existing Moodle wiki users need to use a 3rd party add-on to migrate data forward (unless you add a one time HTML export of the latest version into the new OU module)
  
• you know pretty much what you're going to get right now (this naturally compares poorly to whatever you hope either module will be like after 'doing a lot of work')

I'd much rather see two good modules that concentrate on what they're good at/for, even if one is non-core, than see people expend effort changing and expanding one perfectly good module in order to become a partial replacement for another and be left sitting between two stools.

(a tangent inspired by the suggestion of "Hypertext" as a module name: I don't suppose the OU/Sam/anyone else is interested in producing a single user 'resource' version of the OUWiki that lets teachers create multiple inter-linked pages similar to the Book module? Student's would only be able to read. I know you could probably do this with roles, but a seperate resource/activity would communicate what was going on better).

That looks great Joseph, I'll test that out on our data too, but it looks like a fairly straightforward fix.

It would be helpful for our workflow here if this was added to the Questionnaire cvs. Would this be possible and if so how long would that generally take?

I think I've traced it to a function called response_select_name which seems to assume that the question name is unique as it adds data to a array using that as a key. This clobbers all but the last entry which is consistent with the output I'm seeing.

I think this may be a bug, I'm currently trying to pin it down exactly but in the meantime I thought I'd explain what I think is happening.

It appears that Questionnaire allows you to give two questions the same "field name" (which it will generate from the first few words of the question text e.g. HOW_WOULD_YOU_RATE).

This doesn't seem to cause any problems until you try to export the results as .csv whereupon instead of displaying each question's responses it repeats the responses to the first question with that name, but adds a set of quotes around it. If you have many such questions it adds further sets of quotes each time.

As I said I'm currently trying to find out exactly what causes this, how to fix Questionnaire to not do it, but also an easy way to rescue the data and export it correctly to .csv format.

I seem to get a Internal Service Error 500 on trying to access the styles.php.

Do your server logs give any more information?