I’ve just updated the version of my Online Users Map block for Moodle 1.9 so you have the option of using OpenStreetMap for the map display. I’d already done this for the version of the block for Moodle 2, so was quite easy to retrospectively add this to the 1.9 version too.
You can see a live demo running on my Moodle installation.
Any feedback or comments welcome 🙂
I’ve just updated the online_user_map block so you can optionally show offline users too – the offline users will be displayed by a grey marker and the online users will be in green.
To enable the display of offline users, update the block with the new code, run ‘notifications’ from Moodle admin to update the database, then go to the block settings and select Yes to the option to display offline users.
For info, only the 50 most recent online users, and (if applicable) 50 most recent offline users will be displayed – this is just to ensure that the map doesn’t try to download 100’s or 1000’s of users to display.
Any comments, feedback etc welcome 🙂
I’ve just updated the online_user_map block to try and make it easier to debug. I know some people have a little trouble getting it to work, probably because they have trouble connecting to the external service which does the geocoding.
Now if you go to the block settings and turn debugging on, when you run the cron script it will report which users it is trying to update the locations for, and for which users it has successfully updated their location.
Hope you find it useful 🙂
I’ve just made a few updates to the online users map block:
- made the initial centre point and zoom level options in the block settings
- Fixed a bug with getting the lat/lng of locations when not url encoded
- Applied the moodle “fullnamedisplay” setting for mouse overs on the map
- Translated into French and Hungarian – not by me, but by Valery Fremaux and Peter Csaszar-Cs – cheers 🙂
well, English and Portuguese, so maybe bilingual rather than multilingual!
Thanks to Pedro Crispim for giving me the Portuguese lanugauge file for the online users map block 🙂
It’s in the Moodle CVS if you’d like to download it and if anyone else feels like translating into other languages, please do – if you already have then send me the lang file so I can add it to the package for others to use 🙂
I’ve just finished writing a new Moodle block, which is a variation on the standard online users block, but rather than showing a list of users, it uses the location information from users profiles to display online users on a Google map:
You can download this block from Moodle.org – or it’s in the Moodle contrib CVS
All feedback welcome – please post any comments/feedback etc below 🙂
Have now pretty much finished off moving the MSG block to use JSON style services instead on XmlHttRequest and Chris has made quite a few updates to the BuddyXML service and MSG Client so we don;t get the odd little problems I previously mentioned. One big change is the ability to hook onto existing sessions, so for example if you log in with the MSG web client and then log in with MSG alert, they’ll use the same session, whereas previously you would actually be running two separate instances.
We’ve still got a fair bit more testing to do I think, but so far all seems good 🙂
Now I’m back on the Visual C++ stuff for updating MSG Alert, which is moving (very slowly!) forward, I’ve still got plenty to learn there I think 🙂
Spent the last few days updating the MSG-Moodle block so that is uses the JSON method rather than XmlHttpRequest and all seems to be going quite well. It will certainly make the application much more responsive as it makes the MSG-Moodle block a ‘proper’ client rather than having all the communication going via Moodle using a global user. It also means we can flag up when a user receives messages and they are always logged in to MSG if they have logged in to Moodle.
We still have a few problems to overcome, for example the fact that you could have multiple ‘clients’ running – eg the standard MSG Client and MSG-Moodle which causes a few problems for one grabbing presence and message notifications before the other has also obtained the data – this is because the data sits in a queue which is cleared when it;s returned to the client, so if it’s obtained for one client then the queue is clear when the other client requests the info. Hopefully we can get a neat solution to that one.
in the end I think we’ll have ended up almost re-writing the MSG block, but I think it;s definitely worth it if we can get it running ok – especially as it’ll remove all the ‘mess’ of caching presences etc within the Moodle database.
We’re now looking at how we could use JSON rather than XmlHttpRequest for the MSG-Moodle connection to the MSG server. The reason being that the users browser could then communicate directly with the MSG server (and not have to be proxied through Moodle) – and ought to make things a lot simpler and mean that I don’t need to cache all the presences on Moodle (and all the hassle that entails!) as they’d be gained directly from MSG server instead.
Made a bit of a start on it all, but have come up with a few little issues which can occur as you could effectively have 2 MSG clients running (one would be the ‘real’ client and the other running in Moodle).
Had a bit of a nightmare the last couple of days! When we moved the MSG Block over to the ‘live’ server, we started to find that things weren’t working very well – the Moodle site was incredibly slow, this obviously(!) turned out to be a problem with the MSG block slowing things down with the number of requests being made keeping peoples presence status up to date. And this was with relatively few users…
So I’ve had to make fairly big changes over the last day or so to the MSG block to reduce the amount of communication between the Moodle and MSG servers. The way I’ve got around this is to create a database table for the MSG block to cache users presence for a minute or so and only to update the presence when the cache has expired. The obvious downside of this is that user’s presence doesn’t appear quite so ‘live’ on the browser page. There’s also a kind of natural limit to how long the cache should be set to – as if it’s too long it defeats the point of having the live updates via AJAX and the presences only refreshed when the whole page is refreshed (and no AJAX). At the moment I have the cache set to 1 minute, which seems ok for now, but we may have to make this even longer if performance drops again.
I would have preferred to have kept this cache in memory rather than database table (which keeps needing to be read and updated), but apparently this is a bit tricky to do in PHP – see the posting I made on the Moodle forums at: http://moodle.org/mod/forum/discuss.php?d=54994