Author Archive
Bright is super powerful, really. During a demo last week, our partner/re-seller said “I can do anything I want”. Or something like that.
Only problem [at least from our perspective] is the proliferation of Bright customizations in the wild. This can be a bit stressful when we go to change “Bright core”. How do we keep from breaking all those cool client-side customizations!??!?!
Part of the problem has been the testing architecture of Bright itself. Bright server, tested to the hilt. A continuous integration chassis is testing Bright server up pretty much day and night. If it breaks, it’s because we didn’t write a test. Easy to fix.
Nice, but in the end, Bright is primarily used to serve web pages in “other” web stacks. How do we keep track of all that UI code sitting on top of the Bright API?
As an experiment, I decided to rig up qUnit onto the Bright.js library core. We added a special settings option in the Bright plugin for WordPress:
Set that, and next thing you know, your web pages are running the new Javascript test chassis. One nice thing is if this isn’t set, all the test javascript isn’t loaded. So there’s no performance impact on production sites.
With jstest=true test, here’s an example of the test output.
The best part? Adding tests for client customizations, super easy!
For a Bright customizations plugin, just add something like this:
/* add this to your customizations plugin or anywhere you enqueue your Javascript */
function load_bright_customization_scripts() {
if (bright_testing()) {
wp_enqueue_script('my-custom-testing',
plugins_url('qunit-tests.js', __FILE__),
array('bright'));
}
}
add_action('wp_enqueue_scripts', 'load_bright_customization_scripts');
Now add some tests:
// this is my qunit-tests.js
// In this example, we are hooking to the bright tests hooks both BEFORE and AFTER the bright templates are rendered.
// In this test, we will validate the template rendered, that it has data in it, and the the jQuery data tables loaded
// and is usable.
MyTest = {};
Bright.addHook('before_load_tests', function () {
if (jQuery('.bright-template-my_results_matrix').length > 0) {
MyTest.my_results_matrix = jQuery('.bright-template-my_results_matrix').length;
}
});
Bright.addHook('after_load_tests',function () {
if (MyTest.my_results_matrix)
QUnit.test('my_results_matrix',function(assert) {
assert.equal(jQuery('.bright-template-my_results_matrix').length,MyTest.my_results_matrix,'an equal number of divs before and after render');
assert.equal(jQuery('.my-results-matrix .dataTables_wrapper').length > 0,true,"we find that datatables has loaded");
assert.equal(jQuery('.my-results-matrix .dataTables_wrapper table.my-results-matrix tbody tr').length > 1, true, "more than one row found in the results table");
assert.equal(jQuery('.my-results-matrix .dataTables_wrapper table.my-results-matrix thead span.filter_column input[value="Email"]').length === 1,true,
"A text entry search field is found for the email field");
});
});
UGH CODE!!! Yeah don’t worry about that too much. Translated for humans, we’ve made it very simple to write unit tests for Bright templates. Testing rocks!
Honestly, it’s about time.
Bright documentation website, from Aura Software:
http://help.aura-software.com/
Its a living breathing thing and we update it every day! That being said, Bright has a lot of features and it make take a while to fully flesh it out. Suggestions welcome. For the moment, we are focusing on storefronts and e-commerce integration.
Alternative chains certificate forgery
Earlier this morning, OpenSSL released a security patch to fix a new vulnerability discovered in OpenSSL versions 1.0.2 and 1.0.1. This patch fixes one high severity vulnerability, which primarily affects clients.
- This bug does not affect private keys for Certificates on Bright Servers
- No hardware operated by Aura Software is effected.
- No action is required of Bright customers unless a) you are operating your own hardware; in which case you should check with your hosting provider or b) your site use a certificate not directly procured through us.
Developing e-commerce solutions for SCORMCloud is an emerging business for Aura Software, and we are happy to hear that Rustici Software AKA SCORMCloud will feature Bright in a business case on ecommerce to be published on the scorm.com website. I just have to get around to writing it….
Since we’ve been talking to Rustici about ecommerce a lot, we have had the opportunity to talk to many prospects interested in using the Bright + SCORMCloud + WordPress + WooCommerce system.
One of things that has fallen out of these conversations is the need for license management in Bright, wired straight into the shopping cart.
The idea here is that a customer might want to buy a 1000 seat license in a single transaction, and then distribute the license internally [or externally] to their organization. You also might want to combine licenses for multiple courses into single transaction, and of course, there has to be reporting.
It seems that many learning content producers make these kinds of deals already, in some cases with considerable manual work or one-off coding. This is something that we feel we can make as seamless as regular single-user course buys already are in the Bright WooCommerce Integration Bridge. Coming soon!
How will it work?
The thinking at the moment is that during checkout, a custom checkout field would be provided for the cart:
When this is set, instead of an actual course registration being generated via the completed purchase, a license key will be generated and attached to the user’s order. The license data will be written into the Bright server, storing the associated courses and the # of seats available.
This key can be used in the following fashion:
- A user can attach this key to their user profile, and we will provide extensions that will allow user profile fields to be mapped to license keys.
- Thus, when a license key is added to a user’s profile, an API call will be generated which will associate the user with the license. This call will have the side effect of generating the appropriate registrations for the user.
- By using Bright templates that require an existing course registration, the net effect of this will be to grant access to users who have added the appropriate license keys.
- The Bright API will insure that the seat limits associated with the key is enforced.
This model supports:
- reporting by license key
- multiple license keys per user.
Based on Google analytics:
– the best 4 months in terms of traffic for www.aura-software.com are #4: Feb 2015, #3 Dec 2014, #2 Jan 2015, #1 Mar 2015
– March 2015 ….. our best month ever by a huge margin [30%]!
For occasions where you have rogue courses that don’t update their “passed” status, but you WANT or NEED the course passed in Bright, you can set a custom course property in your Bright metadata:
The field name is “completion_means_success”.
With that set, every time a registration is updated for this course, if the registration is marked ‘complete’, it will be ‘passed’ as well.
Note, this may not fix existing registrations that were updated BEFORE the change. But no worry, our awesome support will fix that for you in a jiffy.
Under the covers, this is a “after_crawl” registration hook compiled into Bright server. There’s LOTS of things you can do with hooks….
Got “custom” work you need to do to your registrations every time they are changed [aka launched]? Ask us, we do that.
In some cases, we see issues with existing registrations where when launched, they produce the following errors in the SCORMCloud player: “please make a selection”. At this point, the course is frozen and the only workaround is to reset the registration.
After several months of debugging and troubleshooting, it seems that the source of the problem is somewhere deep in the bowels of the sequencing features of the SCORMCloud player.
In working with Rustici, it looks like a two phase fix is in the works.
Phase 1 will be a bugfix for the “alwaysFlowToFirstSco” course property [which currently doesn’t work correctly and thus can’t be used to workaround the problem]. As described here [http://rustici-docs.s3.amazonaws.com/engine/2014.1.x/8-packagepropertiesreference.html]:
“If true the SCORM Engine will always load the first SCO in a course upon initial launch regardless of whether sequencing rules dictate this behavior. “
For courses with a single SCO, this will be sufficient to fix the problem. This bugfix is in progress for SCORMCloud [April 2015] so we expect it shortly.
Note this option is default setting.
In phase 2, the sequencing engine will need to be fixed. Release date for that is TBD.
Got questions about SCORMCloud? Ask us.
One of the most common questions we get is, “what does Bright for WordPress do that I can’t do with the SCORMCloud plugin for WordPress?
Invariably the topic of performance comes up. What we say is the performance of the SCORMCloud plugin for WordPress scales according to the # of courses on the page. So it is “linear”. In contrast, Bright performance is flat …. which means more courses doesn’t result in more time.
So today I got a support request from a customer to look at the performance of a page. It seems that they’d embedded 5 courses on the page, but used the SCORMCloud plugin, not bright.
It was taking about 21 seconds for the page to respond:
So I just replaced those embeds with Bright embeds. There’s even a “SCORMCloud classic” embedder template that replicates the look and feel of the SCORMCloud plugin; so you can’t even tell that it was changed.
Then I refreshed the page:
OK even we grant that this call took a bit longer to setup [for DNS lookup]; we killed it. Wait time went from 21.08 seconds to 1.75 seconds.
So with Bright, the page load time is 8% of what it is using the SCORMCloud plugin; or 12x faster. As the SCORMCloud plugin gives linear performance, you can expect it to be 24 times faster for a page w/ 10 courses on it, and so on.
Curious on how to speed up SCORMCloud applications? Ask us …. we do that.
SCORMCloud maintains launch history, but so does Bright.
But they are totally different animals.
In SCORMCloud, launch history is recorded, in Bright launch history is ‘captured’.
HUH WHAT!? Yer talking …… MADNESS!!!!
But all kidding aside, what’s the difference [there are lots of Bright blog posts with this theme]?
- in SCORMCloud, a course has to write its own ‘launch history’ data. So if its a TinCan course, for instance, there’s no launch history. Also for misbehaving courses, you may also get no launch history. In the world of debugging, this can be a big bummer.
- for Bright, we capture the fact a course has been launched before it happens. This means that you get launch history for TinCan and you get it even if the course didn’t load correctly.
That’s what I mean the difference between recorded and captured.
So we does the Bright launch history include? Lots of goodness! Check it out:
Now this is just formatted JSON like is returned from the Bright API:
- id – that’s just an internal reference. Unlikely to be of much use.
- registration_guid – for SCORMCloud, that’s the registration ID. For other types of course providers, the unique ID for that resource.
- course_guid – for SCORMCloud, that’s the course ID. For other types of course providers, the unique ID for that resource.
- learner_id – that’s the user. Hi!
- launch_source – what requested the launch; or the client type.
- http_referer – this is the page we launched off. It’s the where. Click it, it should be live!
- http_user_agent – the holy grail. User agent. YES!
- remote_addr: IP address of where the launch was requested. Also highly useful and also not available from SCORMCloud.
- request_uri: the actual request generated to the Bright server. Just guts.
- created_at: when?
- provider_launch_url: see below
So there’s some REAL magic here in the provider_launch_url. Since we capture this, we now can provide introspection to running courses. If they can grab their own location [via window.location from javascript], they can do their own logging by holding onto the window URL and logging it.
You can then backtrack via Bright to the original learner id and registration ID. Already we’ve built some really amazing tracking with this…. and the possibilities are quite breathtaking.
What’s next? Recording the registration state before and after the launch. That will be too cool and will provide great insight.
http://wpml.org/2015/03/wpml-security-update-bug-and-fix
So, yeah, upgrade WPML.
But beyond that, this post contains an absolutely fascinating comment thread on how one SHOULD and SHOULD NOT detail security exploits when releasing a fix.
