Actually, that is a possibility. Some buggy code may be using a number as a course id when that number is actually something else entirely.
What you really need to do now is work out where exactly in the code that error is being generated. Try turning on debug mode if yu have not already.
Tim Hunt
Příspěvky uživatele Tim Hunt
Moodle in English -> Quiz and question banks -> How do I disable letter labels for Quiz Answers? -> Re: How do I disable letter labels for Quiz Answers?
autor Tim Hunt -
You really ought to remove the corresponding too.
Another way to do this is to add:
.multichoice .anun { display: none; }
To your theme.
Another way to do this is to add:
.multichoice .anun { display: none; }
To your theme.
Moodle in English -> General developer forum -> Help reference in a new block -> Re: Help reference in a new block
autor Tim Hunt -
If your plugin is called block_frog, then the correct place to put English help files is
/block/frog/lang/en_utf8/help/frog/helpfile.php
Then the way to make a help button for this is
helpbutton('helpfile', get_string(...), 'block_frog');
/block/frog/lang/en_utf8/help/frog/helpfile.php
Then the way to make a help button for this is
helpbutton('helpfile', get_string(...), 'block_frog');
Moodle in English -> Testing and QA -> How moodle HQ handles quality assurance (QA)? -> Re: How moodle HQ handles quality assurance (QA)?
autor Tim Hunt -
Martin only started writing that development everview page a few days ago (according to recent changes) and it is not finished yet, so you probably just need to wait and see.
Moodle.com does not employ any testers as such. Like most things in an Open Source project, testing is distributed throuhout the world. Lots of Moodle users are also tester (more so than are developers).
Obviously, the tracker is the main interaction point between testers and developers.
There is also a Moodle QA team of volunteers that started about a year ago. They keep an eye on the tracker, and when a developer marks a bug resolved, they go and test tomake sure the fix works and mark it closed. That is the idea anyhow.
In generaly, on of the reasons that Open Source software tends to be quite bug free is that it is run in lots of different ways in lots of different places, and users are incouraged to report bugs they find. So the software gets a lot of testing, even if it is all rather ad-hoc.
Finally, some of the larger institutions that deploy Moodle do have professional software QA teams. For example, every time we deploy and update to the OU's Moodle install, we unleash our Technical Testing team of about six testers on it for about four weeks, and they test a wide range of functionality on all the browsers we support - and there are people in that team who have an amazing talant for breaking software. Still, better that they do it than our students. Also, as we develop new pieces of functionality between releases, they also do some initial testing when each feature is finished. Finally, we occasionally invite students in for usability and accessibility testing.
Moodle.com does not employ any testers as such. Like most things in an Open Source project, testing is distributed throuhout the world. Lots of Moodle users are also tester (more so than are developers).
Obviously, the tracker is the main interaction point between testers and developers.
There is also a Moodle QA team of volunteers that started about a year ago. They keep an eye on the tracker, and when a developer marks a bug resolved, they go and test tomake sure the fix works and mark it closed. That is the idea anyhow.
In generaly, on of the reasons that Open Source software tends to be quite bug free is that it is run in lots of different ways in lots of different places, and users are incouraged to report bugs they find. So the software gets a lot of testing, even if it is all rather ad-hoc.
Finally, some of the larger institutions that deploy Moodle do have professional software QA teams. For example, every time we deploy and update to the OU's Moodle install, we unleash our Technical Testing team of about six testers on it for about four weeks, and they test a wide range of functionality on all the browsers we support - and there are people in that team who have an amazing talant for breaking software. Still, better that they do it than our students. Also, as we develop new pieces of functionality between releases, they also do some initial testing when each feature is finished. Finally, we occasionally invite students in for usability and accessibility testing.
Moodle in English -> Languages -> Better help files -> Re: Better help files
autor Tim Hunt -
Well, the best thing would be to use the cvs log command, which produces output like this: http://moodle.cvs.sourceforge.net/moodle/moodle/lang/en_utf8/help/filters.html?view=log
Well, the command-line cvs obviously produces plain-text ouput, but that requires CVS installed on the computer you are on. If you would rather rely on a network connection, you can just use the generated HTML on sourceforge.net, and extract the information from there.
Anyway, it must be possible to script something, given enough effort.
Well, the command-line cvs obviously produces plain-text ouput, but that requires CVS installed on the computer you are on. If you would rather rely on a network connection, you can just use the generated HTML on sourceforge.net, and extract the information from there.
Anyway, it must be possible to script something, given enough effort.