As part of my testing of the upcoming Moodle 2.4 I got to try out the new Blind Marking feature.  This post gives a quick overview of how it works.

So what is blind marking?

In short, normally when you use blind marking in assessment the teacher/grader cannot see who the assignment is from while they are grading. They may or may not see after the grading happens.

So in Moodle 2.4 there is a new option in the assignment settings page:

 

As the help text explains:

Blind marking

Blind marking hides the identity of students to markers. Blind marking settings will be locked once a submission or grade has been made in relation to this assignment.

So what happens when you set this on?

For the student, they do not see anything different in the submission status window. So it may be important to explain the use of Blind Marking in the Description field as you would other assignment  aspects.

Once the students have submitted what can the teacher see in the assignment?

The new assignment also provides an option to download the list of submissions so that you can edit the grades in a spreadsheet and then upload it. This option also maintains the blind marking with no names shown and instead just a Participant number  “Participant 52″ for example.

 

When grading is complete there is an option to “Reveal student identities”. Once this is done the grades are then sent to the gradebook.

 

An interesting new feature, and as this is one of a few new options in the assignment – I will blog about the others in coming week or so.

Moodle HQ have now released the latest release versions of  Moodle 2.3, 2.2 and 2.1. If you are running one of these versions you should plan to update to the new release version to take advantage of the fixes.

As these are minor releases there is no major feature change, so these include minor changes, bug fixes and some security fixes. For example  Moodle 2.2.3 tackled 212 tracker issues.

Some highlights from Moodle 2.3.3 are:

• Upgrading books from earlier versions now works correctly
• A capability has been introduced to consistently exempt specific users from forum auto-subscriptions and forced subscriptions
• Folder resources now show files in sorted order

For the full details of all the releases use the below links:

• Moodle 2.3.3 release notes
• Moodle 2.2.6 release notes
• Moodle 2.1.9 release notes

In my last post, I had managed to get a working system that would successfully convert blocks in a 1.9 backup file to a Moodle 2.3 restore. I need to do a bit more testing, and then look for a solution for blocks that have specific backup/restore needs.

Testing uncovered that trying to restore a 1.9 course that had multiple versions of the same block installed within it (such as multiple HTML blocks) would cause an error, indicating that a file already existed. Referring back to the new code, this is likely due to the new process_block() function. In that function, a new XML file is created using the name of the block. This means that if more than one of the same block is converted, the code would try and create more than one file with the same name. I need to change that code to make sure it creates a unique file name in this situation.

I change the code:

$this->open_xml_writer("course/blocks/{$data['name']}/block.xml");
...
$this->open_xml_writer("course/blocks/{$data['name']}/inforef.xml");
...
$this->open_xml_writer("course/blocks/{$data['name']}/roles.xml");

to:

$this->open_xml_writer("course/blocks/{$data['name']}_{$instanceid}/block.xml");
...
$this->open_xml_writer("course/blocks/{$data['name']}_{$instanceid}/inforef.xml");
...
$this->open_xml_writer("course/blocks/{$data['name']}_{$instanceid}/roles.xml");

By adding $instanceid to the file path, I guarantee that each XML file will have a unique name. A quick test proves that this is now working.

The next issue to tackle is what to do with blocks that have their own backup/restore needs. The one Moodle 2 block that seems to have this requirement is the block rss_client. It will need its own backup converter.

In the tracker Paul Nicholls started to tackle this by creating a new "blocks/rss_client/backup/moodle1/lib.php" file with an extended class. When he tested the first version, a bug was discovered in my moodle1_handlers_factory::get_plugin_handlers() function changes. If a block does have its own class extended, the file containing it is not included, meaning that the handler class is unknown and an error occurs during the conversion process. Paul has also provided a fix for this error using his own git repository. To fix my copy, I will use the power of git collaboration.

First, I need to be able to pull code from Paul's repository into my local one. I have already made this possible by adding his repository as a remote named "pauln" to my local one. The commit that fixes the code is identified, so I cherry-pick it into my repository with:

git fetch pauln
git cherry-pick 630756fe1063e96cc7a6057bd512aa4afa53bc61

This modifies the code from:

if ($type != "block") {
    if (!file_exists($handlerfile)) {
        continue;
    }
    require_once($handlerfile);
} else {
    if (!file_exists($handlerfile)) {
        $handlerclass = "moodle1_block_generic_handler";
    }
}

to:

if (file_exists($handlerfile)) {
    require_once($handlerfile);
} elseif ($type == 'block') {
    $handlerclass = "moodle1_block_generic_handler";
} else {
    continue;
}

Paul has also provided a new version of the rss_client block with the new handlers. Again, I cherry-pick using:

git cherry-pick d89ade28060ae858356ff4a42cf946a4c99878c0

This provides me with a working copy of the conversion code that will correctly add the extra functionality that the Moodle 2.3 rss_client block requires.

For the record, here is the code for the rss_client conversion handler:

class moodle1_block_rss_client_handler extends moodle1_block_handler {
    public function process_block(array $data) {
        parent::process_block($data);
        $instanceid = $data['id'];
        $contextid = $this->converter->get_contextid(CONTEXT_BLOCK, $data['id']);

        // Moodle 1.9 backups do not include sufficient data to restore feeds, so we need an empty shell rss_client.xml
        // for the restore process to find
        $this->open_xml_writer("course/blocks/{$data['name']}_{$instanceid}/rss_client.xml");
        $this->xmlwriter->begin_tag('block', array('id' => $instanceid, 'contextid' => $contextid, 'blockname' => 'rss_client'));
        $this->xmlwriter->begin_tag('rss_client', array('id' => $instanceid));
        $this->xmlwriter->full_tag('feeds', '');
        $this->xmlwriter->end_tag('rss_client');
        $this->xmlwriter->end_tag('block');
        $this->close_xml_writer();

        return $data;
    }
}

I don't think that this handler will be typical of 1.9 blocks that need to restore their own data though. As it turns out, although the rss_client block does store its own data (feed definitions) in its own table, the 1.9 code never backed that data up. So all 1.9 backups contain only the standard block information for these blocks. But, in Moodle 2.3, the restore operation expects that the feed definition data will be there, and if its not included (even empty) then it causes an error. To work around this, the conversion handler creates an empty version of the expected feed definition XML file for all 1.9 conversions. I will do an extra post later to show how a block that really has extra data would provide the correct conversion code.

There are no other core Moodle blocks that require any specific restore conversion code, so I am essentially done the coding that is required by the tracker issue. Next, I'm going to ready the code for use by the HQ integrators and complete the tracker data so that they can consider it for inclusion into core.

First things I need to do is make sure my git repo is in a good state. To start with, I will make sure that the main branch of Moodle my development branch was based off of is up to date with the latest upstream Moodle code:

git checkout MOODLE_23_STABLE
git fetch upstream
git pull upstream
git push origin MOODLE_23_STABLE

This part isn't necessary, but I want to make my development branch's name a little more manageable, so I rename my MOODLE_23_STABLE_MDL-32880 branch to MDL-32880_2.3. This is purely for optics.

Now, I want to compress all of the work I have done on this issue into one commit. This makes for easier documentation and understanding, since several of my commits were code tests that were later undone. The "rebase" function of git allows me to do this. From the branch MDL-32880_2.3, I issue the command:

git rebase -i MOODLE_23_STABLE

This command will merge all of my commits with the base branch specified, keeping them in my branch, but allowing me to compress some things. The "-i" portion stands for "interactive" and brings up an editor screen that allows me to change what happens:

pick 00cab4e MDL-32880 - Playing with ideas.
pick c7849a8 MDL-32880 - Playing with more ideas.
pick 5036ed8 MDL-32880: moodle1 backup converter: add basic block handler
pick b346f7e MDL-32880 - Adding generic block conversion handlers.
pick 6a3045e MDL-32880 - Named block XML file with instance, and corrected use of currentmod to currentblock.
pick 7b9e3ec MDL-32880: moodle1 backup converter: Include custom block handers if present
pick 6fbf1fb MDL-32880: Add moodle1 backup converter for rss_client block.
pick 1012e75 MDL-32880 - Trying to use convert API in specific block instance.
pick 0b86f82 Revert "MDL-32880 - Trying to use convert API in specific block instance."

# Rebase ce44bf4..2bf7777 onto ce44bf4
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

This screen shows all of my commits in my development branch with "pick" and their information next to them. I want to compress all of these changes into one commit, so I change all but the first "pick" to "squash", and save the edits. Once I do this, I have told git to combine and merge all of the commits into one diff commit. The next thing git does is allow me to create a new commit message for the new combined commit, which I simplify to:
"MDL-32880 - Adding 1.9 block conversion to M2 restore."

Now my MDL-32880_2.3 development branch is up to date with the main Moodle code, and contains just one committed change containing all of the necessary changes for the block restore conversion. This will make it easier for others to review and include in their testing.

The last things that need to be done in order to have this considered for inclusion into core is to complete the rest of the tracker information. Refer to the tacker item MDL-32880 once again to see the results. In this case, Paul has completed all of the necessary information which includes:

• Testing instructions: Specific step-by-step instructions on how to verify that the code will do what it says. Paul has also attached a 1.9 backup file containing all core blocks.
• Pull from Repository: Git repository containing the new code.
• Pull X.X Branch: The name of the branch in the repository containing the code for the specified "X.X" version. For mine, it would be "MDL-32880_2.3".
• Pull X.X Diff URL: A link to the repository that specifies a "diff" between the codebase and the changes, so that reviewer can see a compare view. This is made easy in github, using the "branches" tab and selecting your base branch from the drop-down, and the selecting the specific branch to compare against. For mine, it produces this link: https://github.com/mchurchward/moodle/compare/MOODLE_23_STABLE...MDL-32880_2.3

 I will continue this series next by providing an example of a 1.9 block that does convert its own data.

I recently found out about the Moodle Peer reviewing checklist when its results where added to issues that I had submitted for integration.  There is also the Integration review documentation, but most of this is about principles than a checklist that might guide a developer on what is expected of them.

Since the OU has a similar checklist, and there was some discussion at the recent developer meeting in Perth about review processes, I thought it would be a good idea to compare the two lists and see if we can learn anything from each other.

The OU process is for peer review and integration to usually be done by the same person, a lead developer. Though sometimes peer review is done by any developer, integration is always done by a lead. We expect the handover checklist to be completed by the developer and checked by the reviewer so the list acts as an aide memoire for developers that they have done everything they need to. Our checklist is a series of statements with sample answers e.g.

Backup/restore

[Sample answers:
Y - Tested.
N/A - no course-related data in database or filesystem.
N/A - data is only stored in existing backed-up locations.
N/A - data does not need to be backed up.
]

Our system of sample answers allows for a little more flexibility on the part of the integrator to accept things which are not perfect, with the integrator using their judgement on how important compliance would be in each situation.

There are a number of checks which only appear in the OU checklist:

• support for groups needed
• backup/restore
• basic accessibility check
• cross browser support
• consideration of mobile devices
• install & upgrade checked

I wonder where in HQ’s processes these things are being picked up?  Presumably by the integrators, though that isn’t clear anywhere.  Should it be? Does it make sense for extra checks to take place on integration than at peer review – personally I think not.

Some of the steps in the HQ checklist are covered by our one code checker entry.   I wonder if it would be of benefit to the entire developer community if the code checker were committed into core?

Perhaps of more interest to me, the following are only in the HQ checklist:

• provision of testing instructions
• provision of new unit tests
• sanity check that similar problems throughout the code have been fixed
• git commits
• security – sesskeys, login
• cross db engines
• AMOS commands when moving/copying/deleting lang strings
• renderers, inline style, buffered output, use of appropriate css files
• _GET, _POST etc not used, moodleisms such as correct api calls used
• deprecated functions check, deprecation process
• PHP docblocks present

We’ve talked about testing instructions before at the OU, and generally think its a good idea. That said, for new features where our handover checklist is most used, this should be in the specification document.

The OU does not require new unit tests, only gives brownie points if they are present. That’s a reflection on how busy we often are – which is a poor excuse for not having tests really!

Git commits are the big difference if you work on both core and OU moodle. We flatten work-in-progress branches into a single commit on integration. The HQ way seems more time consuming and complex to me, and if I haven’t got my head round it yet, will some of our less able developers ever manage it? I’m not clear what the benefit of all the extra work is either?

I think adding a security check to our list would be a good idea. It is easy for our developers to think that the entire system is log-in protected, but when the code is used on OpenLearn as well, this is not always the case.

Similarly I think we could add some checks about renderers and CSS styling, and also about not using $_ variables or deprecated functions but using proper moodle APIs where available.

There are a couple of entries that I think are less applicable to us, unless we are offering our modules as contrib – particularly cross DB engine support, AMOS support, deprecation process.

Changes to the OU checklist are agreed by consensus of lead developers. I’m hoping this will spark some discussion about things we could usefully add without overloading people.

I like trying to keep up to date with posts from bloggers on learning and Moodle and related information. Here are some of the posts that I have read recently and that you may find interesting:

“How to load test your Moodle server using Loadstorm”

This is a step by step how-to to help test how well your Moodle can cope with a certain number of users. Now personally, I use Amazon cloud servers and jmeter for testing Moodle performance with my clients but this blog post is certainly a good read although it is for Moodle 1.9.

Source : www.iteachwithmoodle.com/

“Why Your Moodle Site is Slow: Five Simple Settings”

As with all platforms, different options can often be tweaked and disabled even if not needed. This great post takes the user through five such areas in Moodle which many people may not need and that the Moodle administrator can change to reduce them impacting the site performance.

Source: opensourceelearning.blogspot.com/

“Moodle custom fields”

Jenny Gray covers the topic of custom fields / metadata which arose the recent Moodle developer meeting. This is an interesting area and one to watch.

Source:  ltsdevmusings.wordpress.com/

“Open technical debt?”

Although this is from 2 months ago, I think it is a good one to highlight as it tackles some really big aspects of ongoing code development which relates to Moodle development as well.

Source: salvetore.wordpress.com/

“Understanding Tin Can API”

Is this the son of SCORM, or SCORM NextGen? Either way this is one future of Learning Object interaction with Learning Platforms and this blog post is a great summary of what it is all about. I do wonder how this will fit in Moodle and will fit with LTI./

Source www.open-thoughts.com

“MOOC, Motivation, and the Mass Movement toward Open Education”

Hans de Zwart blogged a session he attended about MOOCs at Learning 2012. As I recently took part in a MOOC, this post drew me in and really added some perspective on the whole area. Know what a MOOC is or not, worth a look.

Source blog.hansdezwart.info/

“Adding Moodle 1.9 Block Restore to Moodle 2.3″

Mike Churchward is at it again with another multi-part series on Moodle development this time covering the development needed to have Blocks from Moodle 1.9 backups restore correctly in Moodle 2.

So far there are five parts: Part 1- Part 2 – Part 3 – Part 4 – Part 5

In my last post, I had determined that I could make things happen correctly through the correct use of the get_paths() function creating convert_path objects. This led me to believe that I could now plan out the changes necessary to complete this task.

If you have followed along with the MDL-32880 tracker issue, you will notice that there has been some activity from other participants. Particularly, Paul Nicholls has done some work in his repository and proposed some changes. While I won't use all of them, some of them will make my work easier.

I know that the moodle1_handlers_factory::get_handlers() function (in file "/backup/converter/moodle1/handlerlib.php") uses the get_plugin_handlers() function to load all handlers it finds for blocks. But, since it expects to find specific class files and functions for any block to convert, it doesn't do anything for blocks (since none of the blocks provide this function). Paul's solution involves adding the appropriate file and function to each block in core to make the conversions happen. I still believe I can do this for every existing block without having to create new class files for every block.

I have looked closely at the functions in "handlerlib.php", and my plan is to do almost all of the work in there. My plan is:

• Use the existing moodle1_block_handler class as the main handler. It will define all of the default, necessary processes for any block conversion.
• Extend that class as moodle1_block_generic_handler, for use by blocks that don't require their own conversion handlers. This extended class will simply call all of the default functions.
• Any block that requires more than the default conversions can extend and override this class with their own derived class, using the convention moodle1_block_[blockname]_handler.
• Modify the get_plugin_handlers function to load the generic or block specific handler depending on the block. If a specific block handler class exists it will load it, otherwise it will load the generic class.

For my plan, the best place to start is with the main handler, defining the default processes. This would be adding a get_paths and a process_block function to the moodle1_block_handler. At this point, I want to take a look at what Paul Nicholls has proposed.

In Paul's changes, he has provided a moodle1_block_handler::process_block() function that pretty much does everything we need for all of the blocks. He has also provided a specific get_paths() function in every block to define the use of the process_block function. I can use the first part, but I will create a generic get_paths() function instead.

To use Paul's process_block function, I could just cut and paste his code into my version of the file. But instead, I am going to use the strength of Open Source collaboration and pull his changes into mine using Git.

I already have a local version of my Git repository checkout from my "github" repository, with a working branch for this issue. My local repository also has the main Moodle repository added as a remote named "upstream" to allow me to get the latest Moodle code from HQ. I can add Paul's as a new "remote" to my local one allowing me to "pull" commits from his. From the tracker issue, Paul's repository is https://github.com/pauln/moodle/ and he has documented specific commits for his work. So, in my local Git repository I issue the commands:

git fetch upstream
git pull upstream MOODLE_23_STABLE

This makes sure I have all of the latest Moodle 2.3 code in my local repository before I do any more changes. Next, I issue:

git remote add pauln git://github.com/pauln/moodle.git
git fetch pauln

This attaches Paul's repository to mine as a remote, and gets his latest update information. Now, the next command is the important one. I can grab just the changes he made to moodle1_block_handler by cherry picking the commit tha