People frequently ask the question 'when will [an OU-developed Moodle plugin] be available for [a new or upcoming Moodle version]?' So I'm writing a blog post to cover it. Not very amusing I'm afraid...

In general, OU releases are about six months behind the community Moodle version (possibly seven months now the community schedule has been shifted). This is necessary to ensure reliability but also to give us time to update our plugins, while maintaining new feature development.

If you want to use a released, tested version of our plugins, you'll need to follow our release schedule. Or if you want to live life on the edge, you should probably find that the untested 'master' branch of our plugins will have been updated to work on the next Moodle version by about two months before our live release, i.e. about four months behind moodle.org.

This was probably hard to understand, so let me do headings and bullet points.

If you want a Moodle 2.4 version of our plugins...

• (Moodle 2.4 came out on 3 December 2012.)
• An untested version has been available in the 'master' branch of each plugin in GitHub since approximately the start of April 2013.
• The tested version will be available in the MOODLE_24_STABLE branch of each plugin in GitHub at some point early in June 2013. (You can pester me online if I have forgotten to update it!)

If you want a Moodle 2.5 version of our plugins...

• (Moodle 2.5 came out on 14 May 2013.)
• An untested version will be available in the 'master' branch of each plugin in GitHub by approximately the start of October 2013.
• The tested version will be available in the MOODLE_25_STABLE branch of each plugin in GitHub at some point early in December 2013.

Caveats

• The above dates for our future releases are not definite and are subject to change!
• You can extrapolate from this to Moodle 2.6 (June 2014 live date), Moodle 2.7 (December 2014), etc - although we might change our release pattern by then, who knows.
• As soon as we release a new stable version, we stop supporting the previous stable version. For example, once we have a MOODLE_24_STABLE branch, there will be no more changes to our MOODLE_23_STABLE branch. If anybody wants to support these old branches, we suggest forking our GitHub repositories.

Occasionally asked questions

• I want to use your plugin in a new Moodle version before these dates, does it work? No idea! Please try it. (Sometimes plugins intended for a particular Moodle version will actually work unmodified in the next version. Unfortunately there are lots of cases where this does not hold true.) If it doesn't work, you can feel free to file a GitHub issue, but we probably won't fix it sooner than those dates.

• It doesn't work but I still want to use it before these dates, what can I do? Please fix it yourself and send us the patch. :)

• I have a patch that fixes your plugin for the next Moodle version, do you want it? Yes we do! And thank you for fixing it. But because of how our release process works, the 'master' branch of our plugins has to refer to the release currently in development at the OU. For example, if you submit a patch now for Moodle 2.5, we won't be able to put it on the master version of the plugin until about the start of September 2013 (about a month earlier than the dates I gave above). Of course, if you've put your patch on a GitHub issue, then other users can still benefit from the patch sooner by applying it manually themselves.

Boring post but for info, the OU plugins on GitHub (ForumNG, OU wiki, OU blog, subpage, etc.) have been updated today:

• The MOODLE_23_STABLE branch is now based on our latest live code from our March release last week, which includes patches/bugfixes.
• The master branch includes our latest fixes from our 2.4 development release.

So anyone waiting for a 2.4 version, you might like to try it again. We think most of them basically work now but there may still be some problems (especially subpage might only work under certain conditions). If something's still broken in 2.4, feel free to file issues in the relevant GitHub project.

Oh dear, it's my first blog post of the year. :)

There is probably something more interesting I could talk about, but we're getting a bunch of questions about 2.4 versions of OU plugins lately.

To recap the OU schedule:

• We typically go live with a Moodle release about six months after it comes out, unless something goes wrong.
• Development for our release takes a three-month period that ends about a month before our release.

In this particular case for 2.4:

• We should have stable versions of our plugins for 2.4 (MOODLE_24_STABLE) in June.
• We should have development versions (on the master branch) that work in 2.4 at some point between February (yes, I know it's February now) and the end of April.

Of course, some of our plugins from previous releases may continue to work unchanged - it depends whether any of the APIs in Moodle core were modified in a way that breaks our plugins in that release.

Where our plugins don't work in 2.4, feel free to file an issue on our GitHub site, but be aware that we won't fix it until our development period starts. If it's a simple problem and you want to fix it for us by submitting a patch, please do - we'll try to apply these patches early in the development period, i.e. more like February than April. (We can't apply them before the development period starts though, sorry.)

Since I haven't written a blog post for a while, thought I'd do one about the small project I just finished. This is something we're not particularly intending to release publicly because it's probably not useful to anybody else, but it might be slightly interesting to other large-scale Moodle users. Or not. Let's see.

Basically we had two problems with our Moodle system that this is trying to solve:

• People host large files (e.g. 1GB) on the system, but Moodle isn't optimised for serving large files; this isn't causing a problem now but we're concerned it might do in future.
• Our Moodle filesystem is quite large and rapidly increasing in size. Certain maintenance operations, like when we take a copy of the entire system onto our acceptance test servers each time we test a release, are getting slower.

The OU happens to have an EMC Atmos file store, a commercial product which is obviously designed specifically to store files, so the suggestion was that we should move large files out of Moodle and into Atmos. That way we don't have to include them in the copy for acct (we'll give our acct system read-only access to the filestore so they will 'still be there') and serving the files can also be passed off to Atmos.

Conveniently, there is a new feature in Moodle 2.3 which allows files to be stored in the Moodle filesystem by 'reference' - instead of storing the actual file, it stores a reference to an external repository system.

Using this feature, I built a repository that, during cron, finds all files larger than 10MB. It checks (based on contenthash) to see if they are already in the Atmos system and, if not, transfers them to Atmos, deletes them from Moodle and replaces with the reference. Then, when users click to download a file, it redirects to an Atmos shared link (complete with security key to prove they can access it; we don't lose security by this process, it only happens after the Moodle security checks).

This wasn't very difficult; one of the 'gotchas' is that you have to make sure you set your reference's content to nothing (empty string); if you let the reference keep its original contenthash then Moodle won't delete the file.

A few things in Moodle meant the implementation is not quite as nice as it should be. First there's no way to have a repository that only lets you create one instance, or only lets you create it at system level. I hacked it so that in the creation process it throws an error if you try to create two. Second I couldn't find a way to stop this repository showing up on the file picker for admin users. For everyone else, it doesn't show because I made a capability and didn't give it to anyone.

Overall, though, neither of these are serious problems and the process appears to work well. Although I should admit - I finished the code but it hasn't been through testing yet. :)

Just by the way - this is only part of our 'filesystem too large' solution. I think this will take out about a third of the filesystem size; another third will come by removing course backup files. Those can be huge and they appear to persist forever; we'll probably do a local plugin that deletes them after a month or something. (We don't use those files for backup purposes.) So anyone concerned about filesystem size should also check how many backup files there are in course/user areas - for many of our courses, one backup can be well over a gigabyte, so these add up quickly.

We've just released a new plugin for Moodle 2.2+. (Yes, '+': purely by coincidence, this one already works on Moodle 2.3!)

It's a block that displays news messages, and we've called it the news block. (Not a very original name. Sorry. We did consider 'the boggleogglesquoop block' but it didn't fit in the dropdown.)

This is a replacement for the standard Moodle 'news forum + latest news block' combination.

I made a short (5m) screencast demonstrating how to use the block (running on standard Moodle 2.3). Assuming I haven't run out of bandwidth, you might as well watch the screencast; there aren't any jokes but at that length you can probably survive it anyway.

Features include various options for how messages display (e.g. hiding the author name, if the author isn't important), setting up messages in advance to appear on a certain date, multiple news blocks on the same course if you want to separate different types of news, grouping support so that some messages only appear to a subset of students, and integrated RSS input and output. Combined, you can use the RSS features to post shared news (for example, have a science faculty news block on one course, then include those messages automatically in news blocks on each of a dozen science courses).

The block was originally designed by me; we paid for development by Catalyst. After that initial development we've done minor changes in-house (bug-fixing etc.), and Anthony Forth, another OU lead developer, added grouping support.

To get the block for your own system, download it via the GitHub site.

Disclaimer: the block probably hasn't been much tested on systems that are different to the OU's. I recommend that you try out any new plugins on a test system before using them in production. Unless you really like downtime. :)

Just an update for any other sites using the Open University's Moodle 2 modules that I am responsible for, such as ForumNG, OU blog, OU wiki, and subpage.

Currently these modules are available and maintained for Moodle 2.2, with stable versions updated monthly (and occasionally at other times) when there are changes. In order to get the updates, you have to grab them from our GitHub site as I do not have time to do the manual update process for the Moodle plugin site.

Moodle 2.3 is about to be released but the OU will not be using it immediately. There are  changes in Moodle 2.3 which break some of our modules, especially ForumNG. If you rely on our modules and don't want to do without them, it would be advisable not to upgrade to 2.3 until we do.

I don't promise dates and these might change but I would expect that we will have 2.3-compatible but untested versions of these modules in our code repositories at some point during September. It looks likely that our first 2.3 stable branch will be in early December.

Before then, if people wish to submit patches (using our GitHub site) to fix problems so that the modules do actually work in 2.3 earlier, you could do and if it seems safe I will include it. But please test the patch fully against 2.2 before submitting. :)

This is a brief blog post to let ForumNG users know that I've now, finally, set up a stable branch.

MOODLE_21_STABLE branch at GitHub

This branch will shortly (from Tuesday) match the version on our live servers and should continue to do so until we stop using Moodle 2.1 (which is currently scheduled for April 6th). After that it becomes unsupported and we'll hopefully have a MOODLE_22_STABLE branch.

You can still use the 'master' version of the code, if you want our current untested development version. As of just now, there is a change to the master version which fixes a critical Moodle 2.2 bug (email sending was broken), but unfortunately also means that the master version won't work on Moodle 2.1 any more.

So to summarise:

• We now provide a MOODLE_21_STABLE branch which is the same as our live servers so should be stable and reliable and will receive critical security fixes. It does not work on MySQL.
• As of today, the master branch requires Moodle 2.2 or above. It does work on MySQL - thanks to Brian King for providing the answer to the problem from my last post. :)

If you really really want a version that works on both 2.1 and MySQL, I guess you can grab the relevant commit from GitHub (i.e. the one just before the commit where I say it requires 2.2).

Any MySQL + Moodle experts out there?

Somebody's reported a problem with ForumNG on Moodle 2.x, and I believe it's likely a MySQL problem. There is a really complicated query with several subqueries and the database error is something about f.id not existing (which it blatantly does).

CONTRIB-3480

If anybody fancies installing ForumNG on their Moodle 2.x/MySQL test system, please let me know in the above tracker issue (a) if it works/fails for you (confirm version numbers please?), or (b) if you can tell me what's wrong with MySQL and/or my query, and what I could change to make it work.

I do not currently have a MySQL test install so I would prefer 'I have tried this and it fixes it' type answers rather than 'You could try this, it might fix it...' :)

I did already look at the MySQL documentation because I know there is a hideous limitation in a slightly similar situation (if you have subqueries in a DELETE, they can't refer to the table you're deleting from? Something like that), but I didn't find anything that obviously seemed to apply to this.

(I've disabled comments on this blog post, please add suggestions directly to the tracker issue.)

By special request, here's a super-boring post on the ForumNG 'features' plugin infrastructure! (Not a developer? Look away now.)

It's very simple: you stick standard Moodle subplugins in the 'feature' folder. Each one must have a class which extends either mod_forumng_discussion_feature or mod_forumng_discussion_list_feature (which themselves extend mod_forumng_feature).

The difference is that 'discussion features' will be placed at the bottom of the discussion page, and 'discussion list features' just below the list of discussions on the main forum view.php. Discussion features are passed a $discussion parameter for a bunch of things, and discussion list features are passed a $forum parameter.

The classes for this basically have three methods that probably need implementing: get_order (returns an integer indicating the order relative to other features), should_display (default returns true if you have moderator permission) and display, which returns some HTML.

This doesn't really add up to much; it just means you can put a button (or pair of buttons, or dropdown, or whatever) in the area below the list of discussions or at bottom of a discussion.

Then you can put the code for handling actions in PHP scripts inside your feature.

That's about it except there are some helper functions/classes to make certain things easier (making the button form; plus for example if you want to use the 'post selector' feature which integrates with a lot of built-in JavaScript as well as non-JS alternative code, so that you can let users do some action [export or forward by email] on whatever posts they want).

There's a catch here, which is - well, let's take the 'delete discussion' feature as an example. So there's a 'delete' discussion feature and it provides the button you use to delete (or undelete) a discussion, and the script that runs when you click on it with the 'are you sure' prompt, and it checks permissions and stuff - but it doesn't really do the actual work for deleting a discussion because that clearly ought to be, and is, part of the forum back-end in the mod_forumng_discussion class. (Note: If you want to look at the code for a forum feature, the delete one might be a pretty good place to start.)

That's also true for a lot of the built-in features: the 'feature' architecture actually only includes the UI, and the real back-end work is done inside the core class, because it sort of has to be that way.

But it does still allow some degree of separation.

One of the reasons I wanted it is that ForumNG at the OU includes this totally useless 'show who read this discussion' function. Supposedly this shows you who has read a discussion and when, but in fact it's impossible to tell. So the list, though sort of correct, is basically a lie. I had to do it because they made me. :) But I didn't want to include that in the public version; no reason to spread our bad practice around the world. The 'features' system meant I could just exclude that one folder from the distribution without changing anything else.

Note: An obvious extension would be to add mod_forumng_post_feature class but we did not find a need for this yet - possibly because the 'post selector' approach (where you click a button at discussion level, but then can select one or more posts with checkboxes) is more flexible.

Important note: This is just my personal opinion as a developer. Nothing in here relates in any way to the Open University's official position on any of these matters!

Internet Explorer 6. Three words that strike fear into the spine of any web developer.

As part of our move to the new Moodle 2-based system for some of our module websites, we agreed - well in advance - that we would no longer support IE 6. Google dropped support in 2010, Microsoft run a website encouraging people to stop using it... it's game over.

Why did we drop it? Well, anyone reading this who isn't a web developer might not be aware, but IE6 isn't just equivalent to any other old browser version you might encounter, like say Firefox 3.6 or something. IE6 behaves radically worse than every other browser in terms mainly of its CSS (layout) and JavaScript (interactive) support. If you want things to work in IE6, you have to do a significant amount of extra work in testing and coding workarounds to all the problems. We would rather spend our development time improving the system for 98.5% of users, not fixing problems for 1.5%.

So, we don't support IE6. That means not only do we not test with it, but if anyone reports problems we don't fix the problems, just tell them to use a different browser. And because we developed a new theme without supporting IE6 from the very start (unlikely our previous system, where we fully supported IE6 at the time our theme was originally implemented), it was likely there would in fact be problems.

Turns out that in fact, the main portion of the page doesn't display at all in IE6. It's blank. Oh well, whatever. We don't support it, right? Not a problem.

Until last week when everything hit the fan. Specifically, it turns out that certain government institutions are currently still using IE6, and preventing their staff from installing other browsers. And those staff often don't have the opportunity to simply study at home instead.

Which institutions?

The ones with guns.

Ooops.

I could wear a bullet-proof jacket, but that wouldn't solve the real problem. Which is, we don't want to support IE6, because it costs a lot of developer time. We can't very well sort of half support it; if we support it then that means we have to test everything in IE6 because it's not like any other browser (we don't test everything in Opera either, but that usually just works) - most things probably won't work and will need workarounds. We'd lose all the benefit of ditching support.

But then I had an idea. I suggested it to my bosses and they were okay with it, so we went ahead.

IE6 is a disability. These students are being forced to use an ancient browser; it's kind of like they're being forced to walk down the street blindfolded.

We support blind users. Why not support IE6 the same way?

There's no problem with IE6 as a basic HTML browser. If your website has no style and no interactive features it will work fine. Coincidentally, this is roughly the same way that blind users (through screen readers) experience the internet. So we've already made our sites work if you don't 'see' the styles or the interactive features.

So if you're using IE6 and you look at our new module web sites system (not this one), you'll now see a totally plain screen - we've stripped out all the styles and interactive scripts. It's just like the experience you get with a screen reader - complete with skip links. Not exactly pretty (and we still don't officially support IE6), but you can access all, or nearly all, of the content.

Because I did this at a theme level, it should apply in general. We don't need to test in IE6 - if we build a new feature, as long as it works with JavaScript turned off and no styles (which it ought to, for accessibility) then it should be fine in IE6 too.

That's all. I thought this might be interesting for other people struggling with IE6 issues. There was an embarrassing/amusing screw-up when we deployed this change, but this post is already long enough so I think I'll leave it out. :)

PS To avoid confusion, I should make clear: there are many OU websites which still fully support IE6. This post is only about the new system for module websites, which doesn't.

Update on my previous post: three out of the four issues (all except media embedding MDL-29624) are now resolved and included in the relevant upcoming Moodle versions. Yay! Thanks to all Moodle HQ developers and other people who assisted with getting these approved and included.

This is a mini-post. I'm going to do a real blog post next.

For my first blog post of the year, I thought I'd just give a brief rundown on the current issues (features and fixes) that I've coded and are waiting in the review process for core Moodle. I'm afraid this isn't a barrel of laughs, but at least it's informational.

Admittedly this is partly because I want to encourage HQ developers to review things, but also partly because I thought other people from the Moodle community might be interested in some of these changes! Feel free to vote on issues if you like them. :)

All these issues are ones seen as vitally important by our staff for various reasons.

Features (for 2.3):

• MDL-29624 Media embedding should be consistent and customisable
  At the moment, there are three totally separate mechanisms for embedding audio/video/Flash: the media filter, the File module, and the 'preview' window used when uploading video files. The latter two cannot be customised by any plugin.
  This change standardises it so that all three places use the same system, and also makes it so that the embedding can be customised by writing code inside a custom theme. For example, if you want to change the Flash player used to embed video, or to support different formats, this would become possible without having to change core Moodle.
• MDL-31121 File resource: option to display size, type
  A couple of tickboxes on the File resource form; if you turn them on, then on the course page where it shows the link to the file, it also shows e.g. '24.1MB PDF document' in small text.

Bugfixes (for 2.1+):

• MDL-31122 Navigation block: hide weeks that just contain Label
  The navigation block already does not include course weeks that have no activities, because that would be stupid (you can't navigate to them). But, currently it does contain weeks that have a Label and nothing else. This change fixes that.
• MDL-31015 File/URL resource: 'Open' option doesn't work reliably
  If you choose 'Open' display type on a File or URL resource (meaning, open the file or go to the link immediately), this only works when the link is clicked from the main page. If you click it from navigation, ctrl-click to open in new tab, or open in any other way, you get an intermediate page with the link on, which you then have to click again to get the file/URL.
  Users really hate this because it's like 'I clicked a link to go to the URL - now it's telling me to click a link to go to the URL! that's what I just did!'
  This change simplifies the code (removing a chunk of JavaScript) and makes it so the 'Open' display type always works, wherever you come from.

Exciting, no? Okay, no. Still, now you know.

Finally, just as a reminder - if anyone uses any of the OU's custom modules for Moodle 2, please do make sure to keep up with the relevant GitHub repositories in case there are bugfixes that are important to you. (If you do upgrade as a result, don't forget to check the new version on a test server first.) And incidentally, developers working for the company NetSpot recently submitted a few bugfixes to those modules too, so thanks for that. You can see their contributions in the git history.

This is a special super bonus blog post. Not only are there two blog posts in one day, but this second one has two screencasts in it!

In today's Moodle developer meeting, I suggested (rather rudely, sorry) that the OU's subpage module was a better way to handle the 'everything in Moodle course has to go on the same single page which is stupid' problem than implementing some kind of 'show things on separate pages' feature in every single course format.

Subpage - quick demonstration of subpage using the standard theme so it looks pretty much like standard Moodle (about 5 minutes)

Subpage in real life - how we use subpage at the OU (about 3 minutes) - you get to see our pretty theme in this one

Here are some reasons I think subpage is a good approach:

• Not dependent on course formats, or inconsistent depending on which format you're using.
• Obvious; easily understandable by students and staff. (Except the name! The name sucks, but I couldn't think of a better one.)
• You can keep using convenient views that take advantage of the course format to see the entire structure of the course at once (only it won't be ridiculously long now), or to show N weeks around current, or whatever it is.
• Generally more flexible - for instance, want to nest pages within pages? With subpage, you can. (It's probably a bad idea, though!)

There are some problems with the way subpage is implemented; basically, it's a leetle bit of a hack. In order to make it un-hacky, some of the following things would need to happen to core:

• Add all the 'come back to this URL afterward' features that we included in a short patch.  Without that, in core Moodle every time you do anything in a subpage you end up back at the course page. (For instance, add a forum? Okay, great, but after it's added you're back on the course page.) It isn't really practical to use without this patch even though it does basically work if you struggle through.
• Implement something (ownercmid?) in the sections table to indicate that they're owned by a module and therefore take them out of the ordinary numbering. Apply some changes to backup and restore and navigation and formats to make this slicker. (It works OK without, we're using it, but we do have a few special things in our course format to handle it as well...)
  Note that this change would let authors create other modules that can include sections/Moodle activities, which could actually be pretty cool.

Subpage code repo (...may or may not work at the moment, I hope it does though).

It's slightly out of date browser stats time!

Here's our browser stats for the end of last month from our Moodle 1.9-based system (...this one!) which is responsible for the vast majority of our current course ('module') websites.

Oct 2011 browser stats (Google Docs)

This includes all off-campus access (so basically, all students and tutors, but not internal staff such as academics and me) during a week at the end of last month.

The counting method is based on page views not on individuals or IP addresses, so if you use a mobile phone to access the system occasionally, but you mainly use IE9, then (when combined with everyone else) these proportions will be replicated in the stats. And if you use the system a lot (maybe you're a very active student studying several courses) you will be counted more times than somebody who only checks their course homepage once a month.

If you saw the last lot, you might be interested as to why IE7 has dropped precipitously (from about 13% to about 6%). That's because there was an error in the stats program before and it was incorrectly counting IE8 and 9 users, who had selected compatibility view, as IE7 users. (Our site forces these browsers to behave as their real version, but the user agent still has the wrong one in. However there is a way to tell.) I recalculated the old numbers too and the trend graph shows the kind of gradual decline you'd expect.

Here's hoping most of the people who are genuinely still using IE7 get new computers for Christmas. :)

(Of interest to Moodle 2 users at other sites, developers etc.)

I've just submitted another minor administration feature for Moodle 2.2. It makes consistent across most parts of the system which user fields are displayed in lists, and lets you choose from a selection of fields; the default is to display email (same as current behaviour in most places, just a bit more consistent) but you can change it to show, e.g., idnumber and department if you like. Also adds security control for the feature.

MDL-26647 - has more complicated info and screenshots

As I've only just submitted it, I don't know for sure yet whether the feature will be accepted by HQ (possibly with revisions, of course). I really hope it is. We need it at the OU because administration is extremely difficult when you are trying to e.g. add somebody to a course, and you can't tell which of the ten Sam Marshalls in our database you should actually add!

It's actually top of the priority list I got from the person in charge of managing our transition from VLE1 (based on Moodle 1.9) to VLE2 (based on Moodle 2.1+), in the section labeled 'Hyper important'. (The other two sections are 'Super important' and 'Very important'. I found this amusing.)

I was also pleased and slightly surprised to see that there are 19 votes for the feature, only 17 of which are from me under various aliases*. That puts this in the top 100 most requested Moodle features. Hopefully that increases my chances. :)

* That was a lie! Honest... ;)

I haven't done a public blog post for a while, so here's one! It is mainly of interest to anyone using our add-on modules (ForumNG, OU blog, OU wiki); apologies for general boringness.

The OU is now live with our VLE2, based on Moodle 2.1.x, on a couple of courses. So it's a slowish launch but trust me, there have still been plenty of panics along the way. :)

On an entirely unrelated matter, if you are using the beta versions of OU modules for Moodle 2, especially ForumNG, it would be a good idea to upgrade to the latest version from our github site - after testing it on your system first of course. Just saying.

Seriously - I do have a system in place to transfer single commits from our system into our GitHub public repositories now, so you can actually see what hideous bugs got fixed. The commits do reference numbers in our own bug tracking system, which is internal so you can't see it, but you can read the summary and see the code changes. This might be enough to achieve most of the comedy value, or alternatively to make an informed decision about including the same code patch in your own servers.

It would be a good idea to get a GitHub account if you don't already have one and 'watch' the repository if you use one of our plugins (or use the Atom feeds or whatever else they provide) so that you can see each change as it comes in, just in case it might be important to you

At present, the version on our repositories is what we're still calling a beta - it is typically ahead of the live server, but as we are currently in a rather wild-west deployment phase, not by much! There will be a point where we switch to basing the repositories on our stable branches so that only critical bugfixes appear there. I'll no doubt blog about that at the time. :) Until then you should be extra careful about testing before you upgrade.

Today I've done the first proper release of three Open University contributed modules for Moodle 2.2. You can get all these from our public GitHub repository site:

https://github.com/moodleou

Click into the appropriate repository:

• moodle-mod_forumng (ForumNG)
• moodle-mod_ouwiki (OU wiki)
• moodle-mod_oublog (OU blog)
• moodle-local_ousearch (OU search back-end, supports all three)

Within each repository you will find a readme (scroll down to see it) with information about the plugin. To install a module, use the 'Download' button; unpack the zip file; rename the folder inside the zipfile (e.g. rename 'moodle-mod_oublog' folder to 'oublog') and put it in the right place in your Moodle install.

I have also gone through the somewhat tedious process of adding these to the new Moodle plugins repository as well, so you can probably also get them from the official site instead (this may save you the rename step mentioned). At time of writing, they haven't been approved there yet, but I'm sure that will happen soon.

Important cautions:

• These are now considered beta versions (as opposed to the alpha versions I put out before). They have had some testing, but still not (quite) live use with students.
• Nobody's lately checked them on a standard Moodle install or when using MySQL as a 'database'. (OU moodle is now actually pretty much a standard Moodle 2.1.x, just with a huge stack of plugins added, so hopefully it should be fine, but.)
• We can't offer individual support. Please don't contact me if you have problems with them - try to get peer support from suitable moodle.org forums (it's possible I might reply there, if I have time). However, if you find a bug, please do feel free to report it in the appropriate area of the Moodle tracker.

I hope we will release release-quality versions at some point after our next mid-October release so that from that point, these publicly released versions can be the same as our live ones.

I made a screencast about a new feature I wrote that will be part of Moodle 2.2.

Moodle already has the ability to write descriptions for a resource (link, file, ...) or activity (forum, ...), but these display on a separate screen. Using this new feature, you can choose to display descriptions directly under the link on the course main page.

View the screencast on screencast.com.

Thanks to Moodle HQ - Eloy (code review), Martin (approval, suggestions), Helen (suggestions, wording), Sam Hemelryk (testing). Also to Tim for helping with communication while I was away. And a few other people were involved as well - see the issue MDL-27001 for full details.

A bit of background about this feature - we particularly need it at the OU because in our 1.9 system we had the 'resourcepage' module which let people create pages with lists of files and links for students - and those files and links could have descriptions. Moving to 2.x, we replaced resourcepage with a new 'subpage' module - this lets you do a similar thing, but the key is that it now uses completely standard Moodle resources and activities, just like the course main page. So we had a problem when converting a course from one to the other: the descriptions disappeared. Ooops. Now it should be okay. :)

You could achieve something similar already by adding labels in all over the place, but the spacing is wrong (the system doesn't know your label is supposed to 'go with' the thing above it, compared to other labels that don't, so the space between is too much) and it's a pain if you ever have to move items (as you now have to move both the link and the label below it).

So, I think the feature should be useful for lots of people - not just us.

And by the way, using this feature doesn't reduce performance when viewing the course page, because when you turn on this option the descriptions are stored in the course 'modinfo' cache.

I thought it was time to make another short screencast (approx 4 minutes). This one is aimed at Moodle 2 developers. It's about the renderers feature in Moodle 2 and how you can use it to create significantly different designs. The example I show is the discussion page of ForumNG.

The development work shown in this video was actually all done by Ray Guo. I didn't do any of the actual work. :) But I wanted to talk quickly about the approach. Basically, we (...er, again, meaning Ray) were able to implement a particular graphic design using the renderers feature in Moodle 2.

In order to watch the screencast:

• Download the SWF file from GoogleDocs. Save it onto your desktop or somewhere convenient.
• Click and drag the SWF file into a spare tab of a suitable web browser such as Firefox or IE9 (old versions of IE don't work).

Note: I accidentally had the audio levels too loud! Set your volume low before you start. Sorry.

Rant time! (Wait. That's every time... Well, this time I'm actually typing it into my blog.) This is all about computer programming so if you don't know anything about computer programming you are officially off the hook! (Enjoy your day!)

Coding style guidelines are usually a matter of opinion. But here's one of my opinions, and in my opinion, it's not an opinion, it's a fact. :)

Apart from normal start-of-line indent, trying to align lines of code horizontally is always wrong.

Here are three examples. For each one I'll give WRONG then RIGHT.

WRONG:

$this->something = $something;
$this->x         = $x;

Right:

$this->something = $something;
$this->x = $x;

WRONG:

$thing = array(
    'value'        => 1,
    'anothervalue' => 2,
    'more'         => 3);

Right:

$thing = array(
    'value' => 1,
    'anothervalue' => 2,
    'more' => 3);

WRONG:

$something->function1()->function2($variable, $anothervariable,
                                   $yetanothervariable) {

Right:

$something->function1()->function2($variable, $anothervariable,
        $yetanothervariable) {

etc.

The wrong examples are wrong because computer code is not carved in stone, nor even printed on paper. (When you're grave-carving or desktop-publishing, feel free to make things line up. When you're computer-programming, stop it! Now!) Unlike gravestones and newsprint, computer code changes.

Let's say I add a variable called $slightlylonger to the list of assignments. With the right code, this involves me adding one code line. With the wrong code, I have to add one code line, but now I have to modify 2 other code lines as well to make the stupid thing consistent.

Similarly if I change the name of one of the functions I would now have to go around changing all the following lines as well, where it wrapped to multiple lines. (The function example is also bad because horizontal space is usually at a premium, which is why you're having to wrap lines in the first place; when you wrap the line, you want to get a useful amount of increased space for adding more parameters in future. That doesn't happen if the wrap point is artificially shifted to way up near the end.)

Having to modify extra lines matters for two reasons: first, making the changes is annoying, and second, the more lines you touch then the more chance of a conflict in your version control system.

In addition, as I'm sure the newspaper designer would tell you, both these approaches are bad even from a layout and visual design perspective. They result in 'columns' that start every which way at random points. It's messy.

So, much better not to make it line up in the first place. If you disagree... well there's a word in bold in this post... let's leave it there :)

Rant over!

And no this wasn't directed at any particular developer, or even the Moodle project. Just, grr.

I'll try to write a blog post about something more specific to do with our Moodle developments next time. But this is better than nothing, right? :)