Picture of Sam Marshall

Conditional availability improvements

Visible to anyone in the world
Edited by Sam Marshall, Monday, 24 Mar 2014, 22:54

Oh dear, it's been a very long time since my last blog post!

This is about a new enhancement I've been working on, hopefully for Moodle 2.7, to the conditional activity availability / 'restrict access' system. Basically it's a new API and quite a large change. The key improvements to Moodle out of the box are:

  • Better user interface.
  • Conditions can now be combined using Boolean OR and NOT as well as AND.

I made a screencast to demonstrate the user interface which I have attached below. For best results, make the video full-screen. Also, for some reason I don't understand, it won't start playing until it downloads the whole thing - sorry about that. And finally... drat! It won't play on this page unless you have an OU student/staff login. If you don't, then please right click or otherwise download the link in order to save it to your computer / device and watch there. Sorry about that. (I should report that to someone...)

Screencast (20MB .mp4, 8 minutes)

This isn't quite finished yet but it's very very close (a few days) and I wanted to get it out there. smile

It isn't shown in the screencast because I wanted to concentrate on the UI but another key advantage is that you can add plugins if you want to make availability conditional on something else.

Finally just to make clear, this does replicate absolutely all the functionality of the existing interface - you might have noticed there's no button for user profile conditions, but that's only because I didn't finish the user interface for it yet. It will be there. smile

Permalink Add your comment
Picture of Sam Marshall

Backup and restore shenanigans

Visible to anyone in the world
Edited by Sam Marshall, Wednesday, 23 Oct 2013, 11:21

This blog post is about the work that the Open University has funded (and I've coded) to improve backup and restore in Moodle 2.6.

I was going to talk about this in the Moodle developer meeting, but decided to skip my item because it isn't that critical for developers to know about, I had problems connecting to the technology, and the meeting would have run late. So I'm writing a blog post instead!

There were a number of problems that meant backup and restore was not reliable for large courses. These included:

  • Backup and restore didn't display any progress during the operation - you'd just see the browser waiting for a page to load. This wasn't a very reassuring user interface, and also comes with other problems:
    • If the backup or restore took longer than an hour it would fail due to PHP timeout.
    • On load-balanced/clustered systems with multiple webservers and a front-end server that shares load between them, the front-end server typically has a timeout of a few minutes if connections do not send any output; on these systems, even small backups would fail.
  • Before you get to the actual backup and restore, some of the interface pages can also take long time to load when you have a very big course. Again this is a bad user interface and causes problems for systems with front-end servers. In addition, because the default PHP time and memory limit for these pages was low, they would fail for courses with a large number of activities, even on a 'normal' Moodle installation with one server.
  • Backup files were limited to 4GB in size due to restrictions in PHP's support for the zip file format. (Some of our courses contain more than 4GB of files.) In addition, even where it created a larger file, it wasn't possible to actually download files larger than 2GB due to limitations of a function used in Moodle file download code.
  • If there are minor problems in backup or restore, the code may add a warning message in the backup/restore log. In Moodle 2.5 these logs are never shown to users, so this is not very helpful.
  • There wasn't a simple mechanism for developers to create a standardised large course for testing backup, so while we were seeing major problems in our real usage, it was difficult for developers to deal with the equivalent situation.

To solve these problems I made a number of changes, mostly listed under MDL-38189.

My basic approach was to start with the last problem - using the excellent 'generator' mechanism already in Moodle, I built a simple admin tool to create large courses for testing. The tool had options for different sizes ranging from XS to XXL (this last size I never tried; it may possibly be stupidly big!) with L designed to be similar to the largest courses on our system, and XL designed to be larger than those largest courses on our system.

After that I simply tried to backup, and then restore, courses at each size. The XS and S sizes worked immediately, but the M size failed. Once I got the M course to work I tried with the L course and finally the XL course.

The changes I made that correspond to the above problems are:

  • I added a progress reporting API inside backup and restore. This displays a progress bar and also a wibbler bar underneath it. The progress bar shows 'known' progress as a percentage (when the code knows this is step 47 out of 300) and the wibbler bar just wibbles (changes colour) to indicate that progress is happening when the code doesn't know how many steps there are going to be.
    • The PHP timeout is reset each time progress is displayed, so the backup/restore will never time out as long as something is happening and reporting progress.
    • Because HTML code is frequently output to the browser (usually once per second), any front-end server will not time out.
    • I had to change many areas of backup code (that can potentially take time) to use the new progress reporting API so that this works. I also had to change API in some other areas of code that the backup/restore uses (most notably the file packer) to add a mechanism for reporting progress in that area too.
    • You don't normally have to add progress reporting to individual plugins such as activity modules, if they handle backup/restore in the usual sort of way, because I already put progress reporting calls in the lower-level mechanisms that they generally use - for example in the restore, progress reporting happens automatically while it's reading the XML file with your plugin's data.
    • If you are writing custom code that calls backup and restore programmatically, you can add your own callback to get the progress information - you could use the standard 'progress bar + wibbler' display, or your own custom mechanism.
  • I added and used a similar progress reporting mechanism for the steps included in the backup/restore user interface pages before backup starts (e.g. preparing the large forms for selecting activities; unzipping the backup file at the start of restore). These too can display progress as the pages are prepared for display. To avoid unnecessary distraction, these progress bars don't appear unless it takes at least five seconds to prepare the page. (I also increased the memory limit for these pages so they don't run out of memory.)
  • I made a new backup format that supports files larger than 4GB - you have to turn this on via experimental settings. The files are still called .mbz, but if you turn on the new format, internally it uses the Unix standard .tar.gz compression format. (You can rename the file to .tar.gz if you want to unpack it using WinZip, or the Unix 'tar xf' command.) When restoring the system supports either type of file automatically, regardless of the experimental setting. I also changed Moodle file download so that it works to download large files. (In some cases this might require that the servers are running in 64-bit mode, although I'm not actually certain of that.)
  • When a backup or restore completes, if there are any messages in the log, these are displayed on the last screen of the backup/restore (the one which previously just had a 'continue to course' button). This gives the backup system and plugins a chance to report problems and may see more use in future now that the log actually displays to users.
  • As noted above, there is a 'Make test course' tool in the administration block within the Development folder for developers who want a large course to test against. Other people have enhanced this further since I started it, too!

What's next? Well, I'm not planning any more large changes. But first, it's still possible there might be regressions caused by some of this code which hopefully will be spotted before 2.6 release. And second, I expect there will be some areas of backup and restore which weren't exercised by my large test courses, and which can still potentially time out - so we might need to add progress reporting calls to more areas of the code that I didn't yet spot. The general principle is that if some operation might take longer than, say, a minute, it's probably necessary to find a way of calling into the progress API periodically during that operation.

Hopefully this is more than anyone wanted to know about the backup/restore changes. smile For most people I expect all they'll notice is that they'll get a progress bar when they do backup or restore.

Finally, thanks to all the developers who helped with peer reviews and integration reviews for the many changes related to this! And also to those who worked on (or are still working on) their own separate changes to improve it.

 

Permalink 2 comments (latest by Sam Marshall, Monday, 16 Dec 2013, 10:16)
Picture of Sam Marshall

OU release dates and what that means for our plugins

Visible to anyone in the world
Edited by Sam Marshall, Wednesday, 22 May 2013, 15:15

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. smile
  • 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.

 

Permalink Add your comment
Picture of Sam Marshall

OU plugins updated

Visible to anyone in the world

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.

Permalink Add your comment
Picture of Sam Marshall

OU Moodle plugins and 2.4

Visible to anyone in the world

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

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.)

Permalink Add your comment
Picture of Sam Marshall

Moodle filesystem size and repositories

Visible to anyone in the world

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. smile

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.

Permalink 2 comments (latest by Sam Marshall, Tuesday, 8 Jan 2013, 16:31)
Picture of Sam Marshall

News block

Visible to anyone in the world
Edited by Sam Marshall, Thursday, 12 Jul 2012, 20:28

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. smile

Permalink 4 comments (latest by Sam Marshall, Monday, 6 Aug 2012, 10:33)
Picture of Sam Marshall

New blog post

Visible to anyone in the world

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. smile

Permalink 9 comments (latest by Sam Marshall, Tuesday, 5 Mar 2013, 10:50)
Picture of Sam Marshall

New blog post

Visible to anyone in the world
Edited by Sam Marshall, Friday, 2 Mar 2012, 15:03

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. smile

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).

Permalink Add your comment
Picture of Sam Marshall

New blog post

Visible to anyone in the world
Edited by Sam Marshall, Tuesday, 21 Feb 2012, 14:37

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...' smile

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.)

Permalink
Picture of Sam Marshall

New blog post

Visible to anyone in the world

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. smile 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.

 

Permalink Add your comment
Picture of Sam Marshall

New blog post

Visible to anyone in the world
Edited by Sam Marshall, Tuesday, 7 Feb 2012, 18:32

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.

Image Hosted by UploadHouse.com

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. smile

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.

Permalink 5 comments (latest by Sam Marshall, Thursday, 9 Feb 2012, 10:10)
Picture of Sam Marshall

New blog post

Visible to anyone in the world
Edited by Sam Marshall, Tuesday, 7 Feb 2012, 17:50

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.

Permalink Add your comment
Picture of Sam Marshall

New blog post

Visible to anyone in the world
Edited by Sam Marshall, Friday, 13 Jan 2012, 13:47

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. smile

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.

 

Permalink 2 comments (latest by Sam Marshall, Monday, 30 Jan 2012, 10:11)
Picture of Sam Marshall

New blog post

Visible to anyone in the world

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).

Permalink 8 comments (latest by Sam Marshall, Tuesday, 16 Apr 2013, 17:22)
Picture of Sam Marshall

New blog post

Visible to anyone in the world

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. smile

Permalink Add your comment
Picture of Sam Marshall

New blog post

Visible to anyone in the world

(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. smile

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

Permalink Add your comment
Picture of Sam Marshall

New blog post

Visible to anyone in the world

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. smile

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. smile Until then you should be extra careful about testing before you upgrade.

 

 

Permalink Add your comment
Picture of Sam Marshall

ForumNG, OU blog and OU wiki update

Visible to anyone in the world
Edited by Sam Marshall, Friday, 9 Sep 2011, 12:48

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.

Permalink 9 comments (latest by Sam Marshall, Tuesday, 31 Jan 2012, 14:58)
Picture of Sam Marshall

Moodle 2.2 - Show descriptions

Visible to anyone in the world

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. smile

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.

Permalink 3 comments (latest by Hartmut Scherer, Tuesday, 13 Sep 2011, 09:08)

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 103499