Author: jonm

Posted on

A few things that Rogo does better than Perception

Having been tied to Perception for many years, it is refreshing to be able to test out Rogo, which, although still in it’s infancy, has the potential to be a viable alternative. While we have come across some issues, there are also a good number of things that it does better than Perception (and I expect there are plenty more to come):

  1. Quicker, simpler, less clunky, more intuitive – Rogo just feels like a nicer, less 90’s system to work with
  2. Version history for questions – it will be extremely useful to be able to look back at how a question has changed and developed. In Perception, we use a complex system of question naming to keep track of major versions of a question, but this is far from ideal.
  3. Drag and drop question ordering
  4. Easy duplication of exams, with options to copy the questions or just link to the same set of questions
  5. Fire Alarm/Exit button in exam mode – students can click this button to if there is a fire alarm or other problem during an exam and it basically just shows a blank screen, so that students can be stopped and started together, without anyone seeing anyone else’s screen while they leave the room, or benefiting from seeing the exam for an extra amount of time. Assessments are not timed, and do not auto-submit, so this is not used to stop the timer.
  6. Flexible feedback settings

Perhaps the most important benefit of Rogo though is that it is OSS (Open Source Software) and written in PHP, which is where our skills primarily lie. Therefore, when there are things that don’t work as we would like, we can change them. Whereas with Perception, we generally just have to live with them and pay for the pleasure!

Posted on

Rogo Install – directory permissions

For Rogo install, we had to give the Apache user permissions to write to various directories (https://suivarro.nottingham.ac.uk/trac/rogo/wiki/Permission):

  • /help/staff/images
  • /help/student/images
  • /media
  • /temp
  • /qti/imports (not in Wiki at the time)
  • /qti/exports (not in Wiki at the time)
  • /config (only for install to allow config.inc.php to be written. Not on Wiki at the time)

To find out the user/user ID and group/group ID for the Apache user, I did the following:

  • In Putty, “ps aux | grep apache” to find out username of Apache user (wwwrun)
  • Looked in etc/passwd to find out user ID (30) and group ID (8) – wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false
  • Checked group/group ID in etc/group
  • In WinSCP, changed permissions, giving the above user/group info: user = wwwrun [30], group = www [8]. Gave this user permission over the whole help directory.
Posted on

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

Posted on

CSS – display: inline-block in IE7

I was having some problems with getting the layout of the buttons for the JQuery Tools Scrollable Navigator plugin to work in IE7 for CSlide, e.g. https://learntech.imsu.ox.ac.uk/cslide/collections/index/87.

After a bit of searching I found this: http://fourwhitefeet.com/2009/02/css-display-inline-block-in-ie7/, so thanks to Cathy at http://fourwhitefeet.com.

It turns out that, in IE7, display: inline-block only works on inline elements, and I was trying to use it on divs. The trick is to wrap the content of these elements in an element that is natively displayed inline, e.g. span. For my purpose, I could just replace my divs with spans (they probably shouldn”t have been divs in the first place, but I’d mutilated the examples for Scrollable to gte where I was). It should also work by just adding spans around the content that you want to be ‘inline-block’, but inside the ‘block’ element, e.g.

<div><span style="display: inline-block">My Content</span></div>