We recently upgraded our Moodle 1.9 clients to Moodle 2.1.  One of our clients also uses Wordpress with their students as a portfolio platform.  As part of the upgrade, the client wanted us to develop a Single Sign-On solution between Moodle and Wordpress where the students on Moodle just need to click a link and they will be automatically logged in to their Wordpress subsite.  Moodle would be the authentication authority so automatic account creation on the Wordpress side is also a requirement if no corresponding account exists yet on Wordpress.

We've done several SSO implementations before on Moodle 1.9  based on Moodle's MNET.  But MNET will soon to be discontinued so we needed another solution that will be easily supported by Moodle.  I've read that Moodle 2 is going to take the OAuth route but that it's not ready yet.  Therefore I decided to  write a basic OAuth server implementation for Moodle 2 and a corresponding OAuth consumer client for Wordpress.  Hopefully, when Moodle 2's OAuth replacement for MNET is mature enough, the scripts to move our clients to this implementation are easy enough to create.

One of our  other clients was using the Moodle 1.9 MNET implementation to SSO with Elgg.  I was able to code an Elgg OAuth consumer plugin as well which is able to communicate with the same Moodle OAuth server so this allowed us to upgrade all of our Moodle 1.9 installs to the newer Moodle 2.1 and still retain the SSO functionality to different platforms that they require.

I've provided a tarball of the code implementation here in case this sort of implementation is useful to you.  This includes the Moodle 2 OAuth server plugin, the consumer client plugin for Elgg 1.7 and the consumer client plugin for Wordpress.  The wordpress plugin has been tested and runs on Wordpress 3.0.5 but the code is straightforward enough that it might work without modifications on later Wordpress versions.  If you want to SSO to another platform but still want to use Moodle 2 as your identity provider then you can still use the server implementation of this code and write your own consumer client implementation.

View full post

posted in ,

(photo by Moodle)
We've recently upgraded several sites running on Moodle 1.9.x to 2.1.x.  The underlying code between these versions are miles apart but the moodle upgrade code does a good job of keeping the process simple and straightforward.  The upgrade procedure is similar to how one upgrades to a newer point version (e.g. 1.9.2 to 1.9.3).  It's basically replacing the old code with a new one and logging in as an admin and visiting the site url.  Here are some notes to remember.
  1. Always check beforehand if the 3rd-party modules you have installed have newer versions that are compatible with 2.1.  If there's none then they will be disabled so this might affect your decision to upgrade if these plugins are important to be enabled in your instance.  If you're ok with them being disabled after the upgrade but still want to use them in the future then it can be upgraded separately once they have proper upgrade scripts.
     
  2. There may be some some Moodle 1.9 core modules that were phased out and not being maintained anymore for 2.x so you'll need to plan for those as well before you deploy. An example of this is the journal plugin which has been officially discontinued but still being maintained under contrib.  Some plugins like exercise are not being maintained anymore since the newer code now recommends the use of assignment and workshop modules instead.
     
  3. Moodle 1.9 themes are not compatible with 2.1 so you'll need to use one of the included themes or look for one that supports Moodle 2 (http://moodle.org/themes).  If you need to use elements in your current theme then it's probably better to copy an included stock theme to your own theme folder and start modifying the copied theme.  The Moodle 2 themes are highly configurable so that helps a lot.
     
  4. Don't forget to copy over to the config.php file your setting for "passwordsaltmain" if it's present or you'll not be able to login.
     
  5. This is a given.  Make sure you test the upgrade first on a copy of your data before doing the actual upgrade.  And when you do the upgrade make sure you backup your database as well as your data repository.  Moodle 2 upgrades the structure of the moodle data directory so it's important that you have a copy of the old format in case you want to revert.
     
  6. After the core upgrade there are some additional tasks related to the system (e.g. converting to your database tables to innodb format) that you may need to do.  Most of these will be displayed in your admin notifications screen.
     
  7. Moodle 2 now makes use of a repositories file system and this is one of the major difference from Moodle 1.  It could be a little confusing to use when one is accustomed to the old one so you may want to train your teachers/instructors on how to use this system.
     
  8. IMS repository support is not yet quite there for Moodle 2 so this is something to consider if you are using one.
     
This is not in any way complete but these are the more common ones to consider when doing the upgrade.  Hopefully you'll have a smooth and flawless process once it's your time to upgrade.

View full post

posted in

(photo by jimmyroq)

For the past couple of weeks, I've used some of my time to write code that adds support for Federated Login for Google Account Users to an Elgg instance. This particular project's requirements don't end with just an implementation of Single Sign-On (SSO) but it also needs to have access to some of the user's Google Apps Data.  Because of this, I decided to use Google's OpenID+OAuth Hybrid protocol, which is a good fit for the requirements.

The first thing I did was to register the domain of the application I'm writing with Google.  You can read instructions on how to do this here.  After I've validated the domain, I now need to write the interface to Google's OpenID+OAuth Hybrid protocol.  The goal is to have SSO working with the capability to automatically create users on the Elgg side and map them to the proper Google account and to be able to request access to Google services.

I searched the plugins page for Elgg if anyone already wrote such a module and I got two results that piqued my interest.  These are Kevin Jardine's OpenID client plugin and Justin Richer's OAuth plugin.

View full post

posted in
Most of the software Solution Grove uses have support for internationalization.  We can offer to present webpages in the user's chosen language using translated message keys.  The current limitation is that internationalization usually apply to those strings which are present in the platform used itself.  It usually doesn't cover any user provided content.  And this also means that any new string that you want to use needs to be properly translated to the different languages that your site supports.

If you don't have the resources to translate everything used in your own sites, you can opt to use the Google translator tool in your site.  What it does is to add a small widget where the visitor can choose from a dropdown list of different languages and have the Google translator do the work for you.  Some of the advantages and disadvantages are listed below.

View full post


(photo by Kasaa)

We were recently tasked with an Elgg project that requires forum discussions to behave like mailing lists.  There's already a community contributed plugin that does something similar but doesn't quite meet the client's required specifications, notably with regards to permissions.

During the initial design, the client mentioned that we should think about reusability since the system might require other functionality that makes use of incoming emails in the future.  So instead of just coding a plugin that will take care of discussions via email I decided to write a plugin that can handle incoming emails in a generic way and then trigger plugin hooks.  The different plugins will then be responsible for implementation on how to handle the incoming email.

View full post

posted in , ,

(photo by oooh.oooh)

We recently posted about our project that implements Single Sign-On between Moodle and Elgg using Moodle Network (MNET). We wrote an Elgg plugin that extends the mnet-lib PHP library as part of this implementation.  This early version of the plugin allows Elgg to function as an Identity Provider (IdP)  so that its users can SSO to moodle.  The current implementation assumes that ELGG is the authorative system. It doesn't have the capability to act as Service Provider.  We expect to be doing a great deal more work to extend this plugin in its early stages so stay tuned!

View full post

posted in , ,

About two weeks ago, a client raised an issue with their moodle installation.  The client wanted course teachers to be able to take LAMS activites instead of just being allowed to author them.  Then just this week, another client wanted to suppress the emails sent to course teachers when a student answers a quiz activity in moodle.

Both these issues are related in a way since the code logic that determines who can take a LAMS activity and the code for who are notified of quiz submissions both rely on checking moodle roles and capabilities.  If you're familiar with moodle, then you'd be aware of the different roles that can be assigned to a user both on the site level and on the course level.  What some people miss is that there are capabilities as well that's assigned to each of these roles.  In order to resolve the issues that the clients raised without modifying the code, I needed to override these role capabilities so that they would behave as to how the client wants them to.

I'll outline here the steps of what you need to do to change the default roles capabilities in case you are faced with a similar problem.

To change the top-level role capabilities:

View full post

posted in

(photo by mahara.org)
I did a few posts on Single Sign-On between Moodle and Elgg some time back.  Recently, I looked at Moodle Network (MNET) and how well it integrates with other software with support for it.  Since we are interested in integrating Moodle with portfolio and social networking tools, I tried setting up Mahara to "talk" with Moodle using MNET.  Setting it up was pretty easy -- thanks to the detailed guide called Mahoodle.  After I got it working and tested it a bit, I liked what I saw.

View full post

posted in

(photo by wiki.laptop.org)

Solution Grove is in the process of testing an installation of the XO School Server (XS) of the OLPC project.  Since I don't have an XO laptop, I needed to emulate one.  I'm already running several virtual machines using VirtualBox so it makes sense that I go that route for an emulated XO.

I've outlined below the steps I did to emulate XO on VirtualBox.  The steps here will most likely work with VMWare as well just by changing VirtualBox specific steps to their VMWare counterparts.  These were researched and accumulated on the wiki.laptop.org and sugarlabs.org wiki pages. Some parts are copied verbatim and attribution go to their original authors.

View full post

posted in

(photo by LAMS Foundation)

In an earlier post, I wrote about how to properly integrate Adaptive Curriculum Activity Objects inside Moodle.   After having success with that, the client now needs to have the activity object as part of a LAMS sequence. 

The approach I came up with is to have the URL to the scorm activity created as a resource in the LAMS sequence.  This particular client's LAMS server is in a different domain and port than the Moodle server and it doesn't satisfy the requirements of JavaScript's Same Origin Policy.  This restriction presents a minor issue when launching the resource in a framed LAMS window. The only way to integrate it properly within LAMS is to have it launch in its window.

View full post

posted in ,

(photo by Adaptive Curriculum sample screenshots)

Solution Grove has a client who wanted to try out Adaptive Curriculum's (AC) Activity Objects (AO) inside Moodle.  This initially sounded trivial since they provide SCORM compliant packages and I thought it was easy as just creating a SCORM activity for the AO.  It turned out that AC's AOs are not standalone and they require authentication when installed on third party servers.  Their objects use standard SCORM API calls for getting the user and session information then use these values to authenticate.  The first part's the easy one since I don't need to write any code for that because Moodle already has API for SCORM 1.2.

The problem I encountered was that the authentication method used by AC needs to be run in a stateless manner through a server-to-server HTTP post using the user and session information that originated from the third party server (in this case, the moodle installation). This presents a problem for server-to-server communication because in moodle, the session id for the user is stored in a cookie and we will only be able to get that cookie if the script is run in the browser where it was issued.  At this point, we are now in contact with AC to ask a few questions so that I can proceed implementing a code to support their AOs.

View full post

posted in ,

(photo by freeparking)
This is the second part of my post on mapping Moodle courses to Elgg communities.  You can read about part 1 here.  This post discusses the actual implementation.

In order for us to track a one-to-one relationship between a Moodle course and an Elgg community we first need to create a mapping table.  The table definition I used is as follows:

 
															<TABLE NAME="block_eportfolio_course_map" COMMENT="">
	<FIELDS>
	<FIELD NAME="id" TYPE="int" LENGTH="10" NOTNULL="true" UNSIGNED="true" SEQUENCE="true" ENUM="false" NEXT="courseid"/>
	<FIELD NAME="courseid" TYPE="int" LENGTH="10" NOTNULL="true" UNSIGNED="true" DEFAULT="0" SEQUENCE="false" ENUM="false" PREVIOUS="id" NEXT="eportid"/>
	<FIELD NAME="eportid" TYPE="char" LENGTH="128" NOTNULL="true" SEQUENCE="false" ENUM="false" PREVIOUS="courseid"/>
	</FIELDS>
	<KEYS>
	<KEY NAME="primary" TYPE="primary" FIELDS="id" COMMENT="Primary key for block_eportfolio_course_map" NEXT="courseid"/>
	<KEY NAME="courseid" TYPE="foreign" FIELDS="courseid" REFTABLE="course" REFFIELDS="id" NEXT="courseid_uniq" PREVIOUS="primary"/>
	<KEY NAME="courseid_uniq" TYPE="uniq" FIELDS="courseid" PREVIOUS="courseid"/>
	</KEYS>
	</TABLE>
	
The eportid column corresponds to the Elgg community id for a particular course; the courseid is the one that tracks the Moodle course.

Since our code already supports single sign-on, we just add to that to track whether an Elgg community needs to be created.  Let us reuse the signupredirect.php page and just add an extra variable that tells the system to create a corresponding community.  The significant section is as follows:

View full post

posted in

(photo by freeparking)
As part of Solution Grove's ongoing improvements to its Moodle-Elgg-LAMS integration demo site [http://www.solutiongrove.net], I was tasked to implement a one-to-one correspondence between Moodle courses and Elgg communities, using the e-portfolio block which I previously wrote about in these posts [1, 2]. What this means is that instead of the Moodle e-portfolio block fetching general activities from Elgg, it gathers posts, comments, and the names of newly shared files from the members of an Elgg community that corresponds to the Moodle class. This diverts a little from original behavior which required an Elgg object to be "favorited" before it showed up in the Moodle E-portfolio block.

The end result is a custom e-portfolio block that presents the following user experience:

View full post

posted in

(photo by ShareThis)

As part of Solution Grove Blog's facelift, we added links to "share" the content to different social web communities.  We already have the standard "Digg" and "del.icio.us" links in most of our client sites and we initially thought of putting this in our own blog.  However, while browsing other blogs, I came across a niftier implementation.  It's a free script provided by ShareThis.  All you have to do is 1) register, 2) customize your "Share This" link using their "button builder", and 3) copy the code to your page or site template.

View full post

posted in ,

(photo by oooh.oooh)

A few weeks ago, I posted how Solution Grove implemented Moodle to ELGG Single Sign-On.  That was only the first phase.  The client also needed it to seamlessly auto-create users on ELGG using credentials from the user's Moodle account.  We searched for a solution for this and found his ELGG-WebCT integration solution from Aperto Elearning Solutions.  Even though the other component was WebCT, it was still interesting to us as the concept is similar - the user is automatically created on the ELGG side.  Solution Grove emailed Aperto and their contact person was kind enough to point to us the Aperto download server, where the code can be downloaded, and added a few tips in the email as well.

View full post

posted in

(photo by oooh.oooh)
One of Solution Grove's clients, The Center for 21st Century Skills, needs to integrate Moodle, ELGG, and LAMS as an online learning environment for their Connecticut Career Choices (CCC) program.  A requirement of this implementation is to support single sign-on (SSO) between Moodle and ELGG.  This post summarizes the steps Solution Grove conducted to make it work on our test servers.

For this particular implementation, we will be working with the following software versions: Moodle 1.8.3 and  ELGG 0.8.1.

The assumption is that Moodle and ELGG were already properly installed and is confirmed to be working.

Here are the steps: 

View full post

posted in
XML