pull em up

In order to push education, we’ve needed to at times bend Drupal to our will.

ELMSLN hold at its core foundation Drupal 7, with the idea that in order to innovate, we need to fragment functionality but not user experience. We can push the envelope in one area of education and design while still holding fast to the realities of today’s experiences in others. With ELMSLN, we’ve created an infrastructure for sustaining innovation while keeping your baseline of course experiences in check.

Because of this, we’ve got sites… boatloads and boatloads of sites. A course is not just 1 Drupal site, but the bulk of it’s experience is potentially delivered by 4 or 5 sites, influenced by data from a 6th and provided with high quality media from a 7th. This overhead comes at obvious costs (like complexity, thankfully Drush / bash keep life simple) and replication of database tables / files for gains in flexibility.

In order to correctly keep the experience in sync for students and instructors so they never need to know what’s going on under the hood, we need data and experiences to be in sync. For experiences, that’s easy, we’ve built a solid, sub-themed UI that helps people quickly forget that it’s built in Drupal. For data though, we needed something more. We’ve leaned on two capabilities that were easy to come by: cron jobs with keys, and Restful web services via RESTws module. These each come with their own set of problems. Cron is slow, and destructive to caches and performance; while RESTws is well targeted to modification of objects. The problem is, not everything is an object.

And so, we built an API that can contextually bootstrap Drupal based on the kind of command being run. I based this off of a cool module I found called the JS Module. The JS module provides a drop in, alternate index.php which bootstraps just the database and the JS module itself. I didn’t like that it was making too many assumptions about JavaScript so I took the concept and ran with it.

This screen cast details a low-bootstrap API that I wrote to allow ELMSLN to cheat on D7 bootstraps. We needed this because of the inherit structure of our system (lots of sites that need to keep very specific data in sync) but it’s an example that I think others could fork for their own purposes. A few API capabilities we currently support for lower-bootstrap:

• remote cache bin clearing - DB bootstrap only
• remote vset - variables bootstrap only
• remote theme settings sync - variables bootstrap only
• sync roster - a complex backend process that uses a full bootstrap but without page execution