It is worse with some themes and some browsers.
You can still edit by clicking the question name, but that is not obvious.
I moved the edit icon to the left.
The code to print blocks in now in theme layout.php files. (Or in
moodle_core_renderer::handle_legacy_theme)
Code for printing blocks everywhere else has been stripped out.
(Total diffstat 1225 insertions, 2019 deletions)
The way the HTML for a block instance is generated has been cleaned
up a lot. Now, the block_instance generates a block_contents
object which gives a structured representation of the block,
and then $OUTPUT->block builds all the HTML from that.
How theme config.php files specify the layout template and block
regions by page general type has been changed to be even more flexible.
Further refinement for how the theme and block code gets initialised.
Ability for scrits to add 'pretend blocks' to the page. That is,
things that look like blocks, but are not normal block_instances.
(Like the add a new block UI.)
Things that are still broken:
* some pages in lesson, quiz and resource. I'm working on it.
* lots of developer debug notices pointing out things that
need to be updated.
I don't know why the quiz only logged every 10 minutes. No other part of Moodle worked like that. However, it has always been like that and I did not have a good reason to change it until now.
What was a problem becuase it made it harder to catch people doing a primitive DOS attack against the server by hitting Reload repeatedly.
* Reorder form fields to group things more logically.
** and on the corresponding admin page too.
* Set some options to be 'Advanced' by default:
** Apply penalties.
** Each attempt builds on the last.
** Decimal places for question grades.
** The five 'Extra restrictions on attempts' settings. (password, etc.)
* Admins can still change this to suit their institiution at Administration > Plugins > Activity modules > Quiz.
* These new defaults are applied if the admin had not previously set any fields to be advanced.
* Disable some filds when they are not applicable:
** Grading method, if num attempts = 1
** Penaly scheme, if adaptive mode = no
** Each attempt builds of last, if num attempts = 1
** Review after quiz closed options, if no close date.
** Delay between 1st and 2nd attempts, if num attempts = 1
** Delay between later attempts, if num attempts < 3
* Convert quiz.timelimit to be in seconds, for consistency, and ready for the new duration field type (MDL 18500).
** Including ensuring that backup and restore is backwards compatible.
* MDL-5537 New setting, questiondecimalpoints, so, for example, you can show the quiz grade as an integer, but have fractional question grades.
** There is a 'Same as overall decimal points' option, which is the default.
* Improve some field labels.
* Make corresponding changes in the help files.
This was started and usability tested as a Finnish Summer of Code project, and then Olli did further work on it in his own time to get it in shape for inclusion in Moodle 2.0. I reviewed all the code. There are a number of minor outstanding issues that will be fixed soon. See the subtasks of MDL-17284 for a list.
The goal of these changes is to:
* help teachers new to Moodle, so when they first see the quiz editing page, they don't go "Huh! What on earth am I supposed to do here?"
* help novice Moodle users understand and learn to use some of the more advanced quiz feature;
* but, without slowing down more experienced quiz users.
Naturally, with ambitous goals like that, we won't have managed to satisy everybody, but I think this change is a big step in the right direction.
There is extensive documentation on this project at http://docs.moodle.org/en/Development:Quiz_UI_redesign.
1. Fix this by factoring out a quiz_has_grades function.
2. Fix the quiz unit tests.
3. Fix quiz_has_feedback to return false for ungraded quizzes.
4. Fix use of get_records to do record_exists in quiz reports.
This is an initial implementation that is now at a working state, but with a few things left to do. It seemed like a good idea to commit it before leaving work on Friday night.
This new messaging system replaces all the various email_to_user() calls.
They are now replaced by events triggers, and the messages are then
processed centrally according to user preferences and sent to one or more
processors (email, popup, jabber etc...)
This code is not finished yet, a lot of work still has to be done on the
interface. However, the basic structure is there and should be working.
Luis and I will be reviewing and polishing this heavily in the next few weeks.
