error – MSDLT Blog

April 25, 2012April 25, 2012

The Curious Case of the Disappearing Image

During our first live test of Rogo, we were somewhat alarmed when the students pointed out that one of the questions was missing an image. Although far from ideal, it was thankfully not disastrous, as it was noticed fairly early on and we were able to print out a copy of the image for all the students.

The question is, what happened to this image? The paper was checked thoroughly against the QuestionMark Perception version of the paper immediately after it was imported, so it would have been spotted at that point had it not come through in the import. However, I clearly did not check the paper thoroughly enough immediately before the exam, as the image was not there.

So the image was lost from the question between it being imported into Rogo and the paper being taken. To find out when and why, I reimported just this question. The image is there in the QTI XML export from Perception, and was there in the question immediately after import. However, after saving the question from the edit screen, without having made any changes to the question, the image had disappeared. The table cell that should contain the image was left just containing an  .

We presumed there was something in the imported HTML that was causing this to occur. Initially we thought it might be that there was no closing tag for the <IMG …> (nor a closing slash at the end of the tag), but adding this made no difference, and there were other questions that have the same lack of closing tag and there were no problems with these. On closer inspection of the html for the questions, we noticed that there was a span in the question intro in the faulty question that was not there in any others. This span contained some attributes that came from MS Word:

diaphragm

Removing the span altogether fixed the problem, so we drilled down in order to identify what aspect of the tags was causing it. We looked into the following:

The inside span the span? Moving it outside made no difference
No quotation marks around EN-GB? Adding them made no difference
The lang attribute? Removing it made no difference
Non-standard CSS properties in style attribute? Removing the styles fixed the problem

Although it is nice to have found the specific cause, there is no reason for this span to exist at all, so we have removed it completely from the imported version. Hopefully questions containing spans such as this will be few and far between, but since many questions are copied in from Word, care needs to be taken, as it seems that the Rogo text editor, not unusually, does not like them.

For future imports, a quick find/replace through the QTI XML exports when we transfer questions en masse from Perception to Rogo should enable us to remove problematic spans. We will have to do some modification of the XML anyway (e.g. changing the path to images), so it will not be much more work to sort this out as well. I have also blogged about other issues relating to importing questions.

April 25, 2012April 25, 2012

Importing Questions into Rogo

In preparation for our first running our first live test of Rogo, we needed to get an exam paper that had been created in Questionmark Perception into Rogo. This seemed simple enough, simply by exporting the QTI XML from Perception and importing it into Rogo. This generally worked reasonably well, but there were a few issues that had to be dealt with:

Not unsurprisingly, images needed special attention. The links to the images in Perception (e.g. “%SERVER.GRAPHICS%topicresources/1065007843”, where the number at the end is the topic id) were replaced (using a blanket find/replace) with “/media(/subdirectorypath)”, and the images copied into the appropriate subdirectory.
There were some issues with tables where an image was shown side by side with the answer options, which required a hack in Perception. For some questions there were problems in the HTML in Perception (left over from the dark ages), so fixing the HTML in Perception fixed the import problems relating to this.
EMQ feedback – the general question feedback from Perception is given as the feedback for all stems in Rogo, which does not have general feedback for EMQs. This can be fixed by removing the feedback from all except the last question, so that it just appears at the end of the responses. Alternatively, the feedback can be split up to give each stem its own feedback. Either of these options would be laborious for large numbers of questions, so the best long-term alternative may be to alter the import code to deal with this.
MCQ feedback – when importing MCQs (including those created in Rogo, exported and imported back in without any modification), in which only general feedback is provided, the general feedback is put in the answer feedback for each answer and general feedback is left empty. This has been added to the Rogo Trac system (#683, https://suivarro.nottingham.ac.uk/trac/rogo/ticket/683)
Correct answers for EMQs – after importing all the correct answers are set to A. This is also the case if a question is created in Rogo, exported from Rogo and imported back in. This issue was added to Trac (#682, https://suivarro.nottingham.ac.uk/trac/rogo/ticket/682) and has now been fixed by the Rogo team, presumably for a future release. For this assessment, fixing this was simply, but annoyingly, a case of going through all the questions and changing the correct answers.
Rogo does not have a multiple MCQ question type, i.e. several MCQs that share the same stimulus and so are combined into a single question, so that it looks like an EMQ, but there are different answer options for each stem. Such questions are recognised as Matrix questions by Rogo when they are imported, but this format is not appropriate. There is no way of modifying an EMQ in Rogo so that subsets of the answer options are only available for certain stems. We have a large number of questions of this format, and currently the only option is to separate them out into MCQs, which is not a sustainable solution. Therefore, we may need to create a multiple MCQ question type, which hopefully would not be too difficult using the EMQ question type as the basis.

Having fixed all these problems, it seemed as though we had an exact copy of the assessment, with everything working as it should. The only difference between the questions as far as the students were concerned was that the multiple MCQ question (there was only one of this type in this paper) was split into 5 separate MCQs.

However, while running the assessment, we were to come across the Curious Case of the Disappearing Image, which, it turned out, was caused by a problem related to importing.

April 2, 2012April 18, 2012

Rogo install problems

On trying to install Rogo 4.2 for the first time, we came across the following issues.

On going to /install/index.php, all we saw was two errors, 103 and 104, with no explanation. On looking in the code we saw that these were caused by the /qti/imports and /qti/exports directories not being writeable by the Apache user. These weren’t mentioned in the File System Permissions page on the wiki (https://suivarro.nottingham.ac.uk/trac/rogo/wiki/Permission), but are now.

Having made these writeable, the install page then displayed input boxes, but without any labels. We realised this (and the lack of text for the errors above) was probably caused by the language file not being loaded properly. After a bit of debugging we discovered that in line 53 of classes/lang.class.php, the str_replace function was replacing the slashes in $_SERVER[‘PHP_SELF’], as $cfg_root_path is just “/” (as it would be for any installation in the webroot directory). I would guess the purpose of this str_replace is to remove the top level directory from $_SERVER[‘PHP_SELF’] for installations that are in a subdirectory of the webroot? Removing the str_replace function works for a webroot installation, but I’ve suggested a more complete solution below (though the if condition might need to be more rigorous). Another thing to note is that $cfg_web_root already has a “/” after it (as defined in install/index.php, line 45), and another slash is added in classes/lang.class.php, line 53 – I’ve changed that too below

Modified code (classes/lang.class.php, line 53):

if($cfg_root_path !== "/") {
     $self_path = str_replace($cfg_root_path, '', $_SERVER['PHP_SELF']);
}
else {
     $self_path = $_SERVER['PHP_SELF'];
}
$lang_path = $cfg_web_root . "lang/$language" . $self_path;

Once this was fixed, it was possible to complete the form with the necessary data for installation. However, the install still failed as it was not able to write the /config/config.inc.php file, as the /config file was not writeable by the Apache user. Having changed this (and deleted the database tables which had already been created), the install was attempted again and worked successfully.

Added to Trac, Ticket #680 – https://suivarro.nottingham.ac.uk/trac/rogo/ticket/680