Moodle 1.8 Experiences content

Arrrg! User accounts switched to Manual

Recently I toyed with the idea of resetting the default icon for this community from the "Aargg" graphic to something more pastoral and soothing. I have since repented of this  notion. Here's the situation. I used the batch course upload script (documented elsewhere) to load a heap of courses into Moodle (and don't get me started on what the Registrar's office swears is the case and what actually happens, eg course number '340' is a temporary designation and won't be there in the final course list -- ''rubbish'' there are several 340 courses -- sometimes even in the same department!). Prior to that I uploaded the list of faculty -- again incomplete. Does ''anyone'' in administration have an accurate, up to date, current list of employees? Now, when I did this I did not have LDAP functioning (another long story ...) so the accounts were set to manual. Now I batch upload the courses -- ''some'' of the faculty are set to LDAP authentication but others are not. It seems to be totally random. Now I have to plough through the whole ruddy user list and check each account. Aaargggg!

Roles and contexts

I've been struggling to suss out roles and contexts (hopefully before the proverbial cr*p hit the fan). I eventually found enlightenment with the Assign roles page on Moodle docs. I was puzzled because although contexts are mentioned a lot it wasn't clear to me where exactly these were located. So, the list on the page above bears duplicating:

• System context: Administration > Users > Permissions > Assign global roles (this context is named "site" in Moodle 1.7)
• Site context: Administration > Front Page > Front Page roles (from Moodle 1.8 onwards)
• Course category context: Assign roles link in course categories page
• Course context: Assign roles link in course administration block
• Module context: Roles tab in editing activity page
• Block context: Assign roles link in course block (editing on)
• User context: Roles tab in user profile page

Thing is, wouldn't it be useful if, in the Moodle instance, instead of just a generic "Assign roles" page there was an indication of what the current context was? Thus, the header for Assign roles in Course Categories might read something like:

Assign roles : Course category context (this is inherited by Course,  Module and Block)

 

I think that this is possible because the URL reads : admin/roles/assign.php?contextid=8 and I'm thinking that the contextid value might be used to apply the variable label.

Eduspaces dropped me once again!

I've just lost a blog entry I  had spent 30 mins on. Problems is that I can take some time formulating all my thoughts and collecting all my links and then the bloody thing times out on me. So now I've sussed out the Firefox extension Scribefire (formerly Performancing) and that uses XMLRPC and saves all my stuff locally so that I should never lose another post!

Working on solving the problem of getting moodle user lists to show lastname, firstname to match rosters

For those of us who use rosters arranged in lastname, firstname format, Moodle presents some challenges!  Most common is display of firstname lastname format, compounded by the problem that in some places the users might be listed alphabetized by first name. 

When assigning students to a course in Moodle 1.8.x, users are now alphabetized by lastname, but continued to be displayed firstname lastname.  (Earlier versions of Moodle, i.e. 1.6.3, ordered students by firstname AND displayed them by firstname.) Of course in some places, a sort link was provided so you could order by surname.  But our problems were particularly with assigning roles and assigning users to groups, since those lists were quite hard to read when they did not match the course rosters from which the faculty were working!

Therefore, Anthony Borrow was kind enough to share two hacks with me to help with this problem in Moodle 1.8.2.  The first hack has to do with moodle/admin/roles/assign.html and assign.php.

Hacks for Moodle 1.8.2 display of users  

And he posted a second hack to force the display of lastname, firstname when assigning members to groups within a course in the Moodle issue tracker.  While it is true that the participants for assigning roles to a group is limited to those who are members of the course, we have some situations where up to 300 students are assigned to a course and separated into sections using groups.  It was quite difficult to assign the students to groups manually when they were ordered by firstname.

http://tracker.moodle.org/browse/MDL-7163#action_28075

Anthony Borrow - [18/Mar/07 12:54 PM ] To change the order of the list of members in the group members box I changed line 63 of /group/lib/utillib.php

from:
$fullname = fullname($user, true);

to:
$fullname = $user->lastname.', '.$user->firstname;
 

I have applied both these fixes on my instance, and so far have had no problems.  I will also post this information at moodle.org (With Anthony's permission). 

Related issues filed in tracker (if you are disposed to go vote!)

http://tracker.moodle.org/browse/MDL-7163
http://tracker.moodle.org/browse/MDL-7591

More Nwiki angst

We (ie Earlham faculty) need a working wiki in Moodle. We need a strong, reliable wiki, with a consistent interface to do group work with shared web sites. It looks like the "old wiki" has not been worked on since version 1.4. Indeed the Wiki support forum has the following quote:

 "The older Wiki module by Michael Schneider and Mike Churchward (which is still in 1.5 and 1.6 dev) is likely to be replaced by a new Wiki module (currently called Dfwiki) being developed by Ludo and his team in Spain."

Well, it hasn't happened and judging from this posting it's not going to happen anytime soon:

" it would seem from the Roadmap that the new wiki has been pushed back until 2008 . I know that you and your team have put a lot of hard work into the wiki so this is a real shame that you/the community are going to have to wait."

Ludo's response is justified frustration:

"I completely agree with the Moodle experts resolution. I'm only sad because it came so late that we are almost too late to fix the issues. The story repeats itself again
Right now we are (specially Pigui) working on the issues reported. We will try to have another candidate ready before august, but if more issues come up, we will go on vacation anyway.
I'm only asking for a little fairness here, IF THERE'S REALLY A WILL TO PUT NWIKI IN 2.0 .. THEN IT MUST BE IN THE 2.0 Branch SINCE DAY ONE."

Ludo (Marc Alier) 's group has put a lot of effort into developing a new wiki system for moodle which has so far gone unrewarded . The wiki module seems to be the poor relation in the Moodle system -- any ideas about how to stir up support for Nwiki? I have already made a posting to the developers forum asking what's going on.

The problem is that Nwiki does not seem to be compatible with roles and capabilities  (see Nwiki bug & More on Nwiki ) in my Moodle Issues TW) and so I don't see how I can use it in the Moodle 1.8.2 to be rolled out soon. Mind you, I'm not sure that the incumbent wiki is compatible either, but it does seem to have had some bug fixing activity as indicated by the Tracker.

New Theme for EIS Moodle

New version; time for new theme. The Serenity theme in the Moodle Themes parlour seems a good shade of Quaker grey (Earlham is a Quaker school, supposedly) but I think I'll tart it up with some Earlham maroon. The CSS hacks to move the Login block in to the header are at Newschool Learning site while some neat Mini Pixel Icons are at n.Design studio. Mauno Korpelainen's superb icon set from the Moodle themes forum:

• version 1
• version 2 with different icons and more contrast
• and some extras
  

I'd really like to adapt The Ideal Website design to Moodle but I think that may have to wait for v2 which hopefully will have a tableless HTML structure.

Restore by deleting allows instructors to create a role

As I was experimenting with the courseupload.php script, I thought about additional implications of asking faculty members to take on more responsibility for their own moodle "teaching space".  After all, I think that most of our people who use Moodle heavily would like to have more control over their own courses, they just need a little training on how to make that happen.

So I am thinking about course shells and how instructors can get content loaded into the shells.  Basically, you have course restore add, course restore delete, and import.  Anthony Borrow reports (sorry, haven't found the link yet) that his school expects teachers to keep and use their own archives.  Other people indicate (no link for this either!) that they make shells and people import content from previous courses that are still on the server.  So I decided to login as an instructor, try the course restore delete and see what happened!

*Runs smack into roles problem*

The restore worked except for, at the bottom, you have a choice of teacher roles that are, more or less, below the editingteacher.  1) create a new role, 2) assign as non-editing teacher, 3) assign as student, 4) assign as guest. 

See: http://tracker.moodle.org/browse/MDL-6831 and

http://tracker.moodle.org/browse/MDL-9066 

So I chose new role. This left me with instructor rights, but it created a copy of the editingteacher role in the admin area of define roles AND I no longer showed up as instructor in the roles assigned display list.  But I still had editing rights as an instructor.  I logged out and logged back in.  I still had editing rights as an instructor, but did not show up as "editing teacher" in the lists.

So I log in as admin to go see what happened to the roles.  I saw that a copy of editing teacher had been created.  When, as admin, I deleted the new copy of the editing teacher role, it was reported that 0 users were assigned to this role. Then, my instructor account was automatically returned to the editingteacher role in the restored course and became visible again in the roles/participants lists.

Strangeness, strangeness.  So I did some further tweaking of roles.  I set up an override on the teacher definition, allowing teachers to assign teachers.  I had this on my 1.6.3 system, so it seemed that this setting might solve the problem.  And, I renamed the role so my "teachers" would be "instructors".  Evidently, in 1.9 we will return to setting the string for what to call students and teachers as part of the course settings.  Right now, it is picked up from the role name.

Now, when I (as instructor) restore with delete, the editingteacher role shows up as expected and I can keep myself in the course as instructor.

Personally, I think it is a bug that any instructor can create a new role through restore.  What would happen if you had 1000 instructors trying to do this?  Scary thought!  However, adding the role override corrects the practical problem of allowing yourself to stay the instructor!  But "new role" is still an option, and I think that is not quite right.

Are you guys seeing similar behavior?  If you all agree, maybe we should add something to the moodle docs?

 

 

Migrating Moodle from OS X to Ubuntu

Display problems on OS X connected

It was evident from the mangled URLs in Nwiki : no display and MyCourses : no display (and last weeks blog entry) that this was generated somehow by the OS X server doling out mangled URLs.

Moving from OS X to Ubuntu

So, having found a new server (or rather , a recycled Dell Poweredge 2400 circa 2000) I set it up and baptised it with bytes as Barnabus. Unlike my experience with Macarius OS 10.4 server where I had to wrestle to get php 5 to work with MySQL (of course the two did not cooperate out of the box) setting up MySQL and PHP on Ubuntu was a doddle. I just followed the destructions for Step-by-step Install Guide for Ubuntu and it all worked flawlessly. Even though there were some glitches like the fact PhP 5 did not have GD present (easily fixed) and Apache 2 did not have mod-rewrite (not needed for this but required for Elgg) — also easily sussed.

Today I copied the Moodle 1.8 version from the OS X server (Macarius) to Ubuntu (Barnabus). This involved backing up Moodle source, data and database, copying all onto the Ubuntu system and then restoring and reconfiguring. Apart from some minor glitches with excluding directories to backup with tar it worked like a charm. Particularly notworthy was the fact that I was able to restore the database into a new setup — something that Aaron hasn't even done yet!

But the proof of the pudding was did it make a difference? We know what the My Moodle page looks like on Macarius (OS X) — a blank. Here's what shows in the exact duplicate environment on Barnabus, the Ubuntu server:

PROOF Positive. Ditto, with the wiki — that worked fine too although there were issues

I'm well chuffed, over the moon, and generally zippidy doo about this.

Moodle 1.8 Can't Follow RSS Redirects

When I attempt to add a redirecting RSS feed to the Moodle 1.8 block, I get the following error message:

 "There was an error loading this rss feed. You may want to verify the url you have specified before using it."

By "redirecting RSS feed" I mean something like this one from the Wall Street Journal:

http://online.wsj.com/xml/rss/3_7014.xml

If you open that link in your web browser, you'll find that the WSJ server redirects you to this feed: 

http://feeds.wsjonline.com/wsj/xml/rss/3_7014.xml 

Moodle can't follow this hop, and generates this error with debugging turned on:

Warning: MagpieRSS: Failed to fetch http://online.wsj.com/xml/rss/3_7014.xml (HTTP Response: HTTP/1.1 302 Object moved ) in /htdocs/lib/magpie/rss_fetch.inc on line 249

Moodle uses a sligthly modified version of Magpie (an RSS parser for PHP) to handle the feeds. Strangely enough, Feed2JS, which also uses Magpie, does not have this issue, so I'm thinking the problem lies somewhere within Moodle and how it deals with Magpie response codes.

Anyone else encoutered this? Can you try that first WSJ url and let me know if you see similar behavior? There could also be something on the server preventing it from following redirected URLs, but my primary suspect is Moodle.

Debuggering blank pages

With a century of miles in my legs from Saturday's ride I felt like I could handle this, but now I'm not sure ....

To ascertain the problem with the wiki I switched on debugging in administration : server : debugging. Here's what I got when I tried to view the wiki page:

Page class mapping requested for unknown type: http:--moodle.macarius.earlham.edu:16080-mod-wiki-view

    * line 100 of lib/pagelib.php: call to debugging()
    * line 65 of lib/pagelib.php: call to page_map_class()
    * line 50 of lib/pagelib.php: call to page_create_object()
    * line 62 of mod/wiki/view.php: call to page_create_instance()

Notice: Undefined index: http:--moodle.macarius.earlham.edu:16080-mod-wiki-view in /Library/WebServer/Documents/moodle1.8/moodle/lib/pagelib.php on line 103

Notice: Undefined index: http:--moodle.macarius.earlham.edu:16080-mod-wiki-view in /Library/WebServer/Documents/moodle1.8/moodle/lib/pagelib.php on line 104
Page class mapping for id "http:--moodle.macarius.earlham.edu:16080-mod-wiki-view" exists but class "" is not defined

    * line 104 of lib/pagelib.php: call to debugging()
    * line 65 of lib/pagelib.php: call to page_map_class()
    * line 50 of lib/pagelib.php: call to page_create_object()
    * line 62 of mod/wiki/view.php: call to page_create_instance()

Notice: Undefined index: http:--moodle.macarius.earlham.edu:16080-mod-wiki-view in /Library/WebServer/Documents/moodle1.8/moodle/lib/pagelib.php on line 107

Fatal error: Class name must be a valid object or a string in /Library/WebServer/Documents/moodle1.8/moodle/lib/pagelib.php on line 67

This was not an isolated incident. I had also set My Moodle to be the default opening page for authenticated users, and this was coming up blank too. The error messages are eerily similar:

Page class mapping requested for unknown type: http:--moodle.macarius.earlham.edu:16080-my-index

    * line 100 of lib/pagelib.php: call to debugging()
    * line 65 of lib/pagelib.php: call to page_map_class()
    * line 50 of lib/pagelib.php: call to page_create_object()
    * line 31 of my/index.php: call to page_create_instance()

Notice: Undefined index: http:--moodle.macarius.earlham.edu:16080-my-index in /Library/WebServer/Documents/moodle1.8/moodle/lib/pagelib.php on line 103

Notice: Undefined index: http:--moodle.macarius.earlham.edu:16080-my-index in /Library/WebServer/Documents/moodle1.8/moodle/lib/pagelib.php on line 104
Page class mapping for id "http:--moodle.macarius.earlham.edu:16080-my-index" exists but class "" is not defined

    * line 104 of lib/pagelib.php: call to debugging()
    * line 65 of lib/pagelib.php: call to page_map_class()
    * line 50 of lib/pagelib.php: call to page_create_object()
    * line 31 of my/index.php: call to page_create_instance()

Notice: Undefined index: http:--moodle.macarius.earlham.edu:16080-my-index in /Library/WebServer/Documents/moodle1.8/moodle/lib/pagelib.php on line 107

Fatal error: Class name must be a valid object or a string in /Library/WebServer/Documents/moodle1.8/moodle/lib/pagelib.php on line 67

The thing that flummoxes me is the way that the URL is being formed. So we get "http:--moodle.macarius.earlham.edu:16080-my-index" and "http:--moodle.macarius.earlham.edu:16080-mod-wiki-view" which cannot be right. I'm using Mac OS X 10.4 server with php version 5.1.2 and MySQL 5.0.18 and I've got a feeling that it has to do with this server since I've already had similar javascript issues with Accordion.

Nwiki gnashing of teeth

OK, so wiki's are important for me and I'm resigned to not being able to migrate ewiki activities (the default wiki version for Moodles up to 1.9 I believe) to the 'new' Nwiki which, so Marc Alier asserts is going to be in 1.9 soon ..

• I downloaded the  Nwiki version for 1.8 from this page -- great success!
• being paranoid, I backup up the Moodlesite and did a Mysql dump of the moodle database
• I unzipped the archive and laboriously copied the contents into the right places (o for tar unzip ...) and then laboriously chown-ed the files/directories to match everything else (markp:admin)
• using phpmyadmin I dropped the original wiki tables (mdl_wiki, mdl_wiki_entries, mdl_wiki_locks, mdl_wiki_pages) so that they would not interfere. Note that this will definitely blatt all previous Wiki activities!
• I then fired up a browser to the moodle site and a host of new tables were created successfully. Jolly dee I thought.
• Now the nasty stuff happens. I add a wiki activity. I am able to type in the stuff and check options. I click 'Save changes' and blank page. I try again with another test activity -- still the view.php?id=515 shows blank.

Other wierd stuff:

• 13 associated wiki blocks  are listed under Site Administration : modules: blocks and all are indicated as showing. None of these appear in the block pulldown menu in the course however (moreover, neither do Login, main Menu, Social Activities, Site Adminstration). This could be a roles issue but I'm darned if I know where to look to fix it.
  

I think I'll try switching debugging on and looking at the mess produced. A job for next Monday methinks. I've got a 100 miler to cycle tomorrow ...

 

Group Events do not appear within Course Calendar

Group events for a course do not appear in the calendar under Moodle 1.8.1 (2007021510). Teachers can add a group event, and they are added to the database and associate it with a group, but it will not appear for teachers, students or admins.

There may be a related bug in tracker already:

http://tracker.moodle.org/browse/MDL-9059

Most favorite hacks (moodle 1.8)

My most favorite hacks:

--------------------------- 

Increase the number of course summaries displayed before going to collapsed mode in category view:

the following change was made in course/lib.php
line 13 should read
define('COURSE_MAX_SUMMARIES_PER_PAGE?', 25); // courses

---------------------------

 Allow admins to edit posts after closing:

In moodle/config.php file, add the following two lines:

// Setting this to true will enable admins to edit any post at any time

//  $CFG->admineditalways = true;

except uncomment the second line (remove the two slashes):

// Setting this to true will enable admins to edit any post at any time

  $CFG->admineditalways = true;

---------------------------

 Change the default course settings to create topic courses instead of weekly courses.

changes made in course/edit.php

98 change
$mform->setDefault('format', 'weeks');

to

$mform->setDefault('format', 'topics');

If you wanted to, you could change the default number of topics/weeks in a course. See
104 $mform->setDefault('numsections', 10);

---------------------------

 Increase shortname field length in the course request form and the course creation form.

In moodle/course/edit_form.php

line 72
$mform->addElement('text','shortname', get_string('shortname'),'maxlength="25" size="25"');

moodle/course/request_form.php

line 13
$mform->addElement('text', 'shortname', get_string('shortname'), 'maxlength="25" size="25"');

---------------------------

Assignment grading interface:  turn quickgrade on as default, increase default number of assignments shown to 20, and remove instructor from the list.

in moodle/mod/assignment/lib.php

line 682
$perpage = get_user_preferences('assignment_perpage', 20);

line 684
$quickgrade = get_user_preferences('assignment_quickgrade', 1);

line 982
$teacherattempts = false; /// Temporary measure 

---------------------------

Set default course blocks rather than using sticky blocks.

in moodle/config.php, lines 20-25

Find the defaultblocks_topics line and replace with this. Also change
the string for defalutblocks_weeks. Don't change social though.

$CFG->defaultblocks_topics =
'course_menu,myCourses:activity_modules,calendar_upcoming,quickmail';

$CFG->defaultblocks_weeks =
'course_menu,myCourses:activity_modules,calendar_upcoming,quickmail'; 

---------------------------

Elgg & Moodle -- ooo'er

While trying to suss out some wierdies with Eduspaces (eg changing the default page that shows when coming in to this community from Profile to Weblog -- the change doesn't 'stick') I came across some rather nice features that made me even more enamoured with Elgg and threaten to derail my Moodle tasks onto an Elgg track. Firstly this conversation on Moodle.org deals with a  moodle block which  functions  as  a  Single Sign On (SSO) between Elgg and Moodle:

"a [Join now] button which links to an Elgg 'sign-up' page which, when completed, creates a new Elgg account (or links to an existing one) and automatically logs the user in. From then on the block provides a link which automatically logs the user into Elgg, displays (RSS link) their recent Elgg activity, and allows the user to upload completed Moodle assignments to their Elgg files."

Is this cool or what? Follow the conversation to download the latest zip file and patches. I myself can't wait to get this going.

Plus,I stumbled across this video tutorial about the Elgg presentation tool which made me realise how great the presentation function was for all types of portfolio type assignments.

So, tomorrow I think I shall download and install elgg from scratch and see how the integration block works.

Testing the restoring of courses

Given the problems that folks have been having with migrating to 1.8 both with straight database switch (eg AWyatt Giving up on database upgrade 1.6.3 to 1.8.1) and restoring courses from backup (Restore removes titles from all activities and resources) I figured that I'd do some of my own testing. I was mainly concerned to make sure that assignments would be restored correctly. All the gory details are in my  moodle issues tiddlywiki but the conclusions bear repeating here:

• Avoid restoring from backup with user data. No titles appear to any of the activities or resources.
• Can restore course with teacher (& student) participants and user accounts  are automatically created (Users -> Course)
• Category must be present in order to take the course. Attempting to restore a course into a non existant category will place it into Miscellaneous.

The deal seems to be that if you have any user data present in the backup file, whether or not you opt to restore it, the course will be munged with no text on the titles.

My next job now is to see what happens with the non-standard ULPGCassignment and how the Wiki comes across. 

3rd Party Blocks and Modules

<personal aside>
I'm from the UK -- Gloucestershire to be precise. When I first visited the USA I went to Washington DC with an acquaintance who was Dutch (isn't that wierd?). We were trying to find a museum or something and so I asked  a local  person directions.  After some exchange I  said, "Oh, a couple of blocks down the road then?". "Whaat?", was her reply. "A couple of blocks down the road", I responded. "Whaat?", she replied, puzzled. My dutch friend then chimed in, "I think he means blaacks". "Oh, blaaaaacks", she said, "yes, that's right". Just goes to show that the US and UK are still divided by a common language
</personal aside>

So, what blocks are folks wanting to install, and why? To kick this off I quote AWyatt's comment :

Blocks we MUST HAVE include quickmail, course menu + (and this time, I am going with the new one from Sandor Lukacs), the gradebook enhancements from Jeff Graham (I got my copy from Anthony Borrow), and  probably MyCourses (which Julian Ridden released and Dave Kichler just completed bugfixes on).  Eventually, I hoped for two complete years of coursework on the server, so the MyCourses collapsible categories will be needed.  We will be greatly saddened if we must lose the attendance block.  I just haven't been able to get a 1.8 version on that.

I must confess that with the hassle of upgrading I'm seriously contemplating a no frills bare bones setup. I wouldn't be surprised if the move to version 2.0 breaks as much as version 1.7 did from 1.6. Other views?

Giving up on database upgrade 1.6.3 to 1.8.1

I am resigned to giving up on the database upgrade. 

This time we upgraded the 1.6.3 database to 1.7, then to 1.8.1.  No joy.  When you turn editing on, half the screen vanishes.  Somewhat less disappears that the last time I tried it, but still it is not going to work. 

I am pretty sure that the problem arises with the non-standard code we have used on 1.6.3.  We could keep trying different things, but I have concluded that it would take less time to just restore all 169 courses into a new instance than to try to figure out and fix the upgrade.  Tedious?  Yes, but it isn't hard.  Fortunately we don't have 1000 courses on the server!!

So no more of this.  We get the new codebase up this afternoon, hook it into a clean db, and start restoring courses.  I have 1.8 compliant code for every block/module we need except attendance, so I will hold off on that one for now!

Hopefully, we will do a limited 1.8 production server for the second session of summer school.  This will give us some time to find and fix any roles issues, etc., before the fall term begins in August. 

Moodle 1.8: Goodbye Groups

During our testing of Moodle 1.8 today we discovered a problem with groups. Although you can still access the Groups interface via a course, you can't use the groups you create to do anything because links to them have been removed the other subsystems. According to the Groups docs:

An attempt to add groupings to Moodle 1.8 was made; however, it was decided to remove this functionality until it can be better tested and integrated with other parts of Moodle (i.e. modules, gradebook, etc.). The initial interface has been modified so that groupings no longer appear as part of the user interface in Moodle 1.8. Read more here.

Groups is something that saw fairly heavy use in our Moodle 1.7 pilot, so I'm not quite sure what we're going to do about this.