Sure I have seen this mentioned in the forum before but I cannot locate it now (the search function is awful).
If I update my content and re-export it to SCORM, after updating the content on my LMS people who have previously launched the content (and not completed the module) are presented with a blank screen when they re-launch (the updated content). This is an issue unique to Rise courses. Please advise if this is a known / replicatable issue. And if there is something that can be done to resolve.
We also have to continue living with this problem and there is no solution other than resetting the learner's progress. And not even that always works, sometimes only in combination with the user deleting the cookies & site data in the browser.
I absolutely cannot understand how this problem is simply "ignored" by Articulate when it affects so many users and companies.
Indeed. Seems a bit weird how it's seemingly neglected. Our solution has been to a.) not use Rise, and instead use storyline b.) In the case someone has to use Rise they break it into smaller courses c.) Where there has to be re-made, transfer / make the course in storyline and swap it.
Neither of these alternatives are good alternatives. So of course it would be way better if there was a fix so Rise could be used without having to reset learner-progress.
We're encountering this issue as well with Rise 360 courses in Moodle 3.10+. SImplly replacing the SCORM zip with a new publish - even without changing the lesson structure of the SCORM causes the learner who has already started the module to receive a blank screen. Has this been addressed? Are there any viable workarounds? We cannot reset learners' progress because we have 1000+ learners who have completed the modules.
For those who use Moodle LMS, the workaround is to access the database through a database client (for example mySQL Workbench if you use mySQL database) and run the following SQL command:
delete from mdl_scorm_scoes_track where scoid=XXXX and element='cmi.core.lesson_location'
Replace XXXX with scoid of the Rise content. You can find it in URL when you open the lesson even if it's stuck on the blank screen. Use this very carefully, on your own risk, because if you mess up the query, you could loose or damage some data in the database.
This method should not delte the learners progress. It should delete only the location - th point where the user left the content. So it will appear as if he starts from the beggining, but the round circles indicating progress of each lessons should remained filled indicating those lessons are marked as finished.
I suggest you try this first on some sample content. It worked for me very well on several different Rise 360 courses in different Moodle versions.
Thanks very much for your suggestion - we are going to look into that. Another thought we had and am going to try see if it's possible to modify the function SCORM_GetBookmark() in the scormdriver.js file (/scormdriver folder) of the Rise publish to see if we can cause Rise to always start from the opening page even if a bookmark has been set. We'll keep you posted if we find a fix.
I believe I've found a solution to this issue which I've been able to tested successfully in Moodle and may work for other LMSs as well:
1. Unzip the Rise SCORM 1.2 zip package (I haven't tested this for SCORM 2004) and locate the file scormdriver.js in the /scormdriver folder.
2. Open scormdriver.js in Notepad or other text editor.
3. Locate this function, and highlight the entire line:
function SCORM_GetBookmark(){WriteToDebug("In SCORM_GetBookmark");SCORM_ClearErrorInfo();return SCORM_CallLMSGetValue("cmi.core.lesson_location");}
4. Replace it with this function:
function SCORM_GetBookmark(){WriteToDebug("In SCORM_GetBookmark");SCORM_ClearErrorInfo();return "";}
This basically disables the bookmark retrieval code so that while all the learner completion and progress status is retained (and shows on the left side Rise menu), it causes Rise to always restart at the opening page.
Then re-zip up the Rise SCORM package (make sure to create the zip from the root folder of the course) and re-upload to the LMS.
It's fine I found the line, it's been moved but it's still there in the scormdriver.js
This whole thing is just annoying - making changes to a Rise project with 3K users already enrolled...I do hope the Articulate team takes this seriously and provides a fix. It is a BIG deal.
Yeah - however, apart from the above, we are also keeping the same course identifier from the old SCORM. So we just copy/paste that in the new imsmanifest xml file after publishing the new SCORM. Not sure if it helps...
I had to work around this problem yesterday myself and I can assure everyone that this problem is not an LMS issue. It is specific to Rise.
The problem is that Rise uses unique IDs for each lesson in a course, and these unique IDs change when you duplicate/copy/send a course. So, if you duplicated the course to do a version update, or if you sent the course to someone else so they could do a version update, the new version of the course will have different lesson IDs.
The lesson IDs are used for bookmarking, so if you overwrite an existing course in your LMS with a new a copied/sent version, all existing users who had previously accessed the course will now have a bookmark for a lesson ID which doesn't exist in the updated version of the course.
When the Rise course cannot find a lesson with the ID matching the user's bookmark, it generates an error, and it's at this point the updated course is breaking.
It would be simple for the Rise course to first check if the lesson ID exists before attempting to load the lesson data, but that's not happening at the moment, so the resulting error is what breaks the course.
Some LMSs, such as SCORM Cloud notice the error and respond to it by redirecting the user to the start of the learning content. That doesn't solve the underlying problem of the differences between IDs, but it at least allows users to access the learning materials, albeit after losing any progress they had previously made.
I'm a developer so I was able to add some javascript to indexAPI.html to catch any attempts to load an outdated lesson ID and point it to the equivalent new lesson ID instead, but I had to collect the list of old and new IDs first for that to work, and I'd potentially need to update those lists of IDs in the future if we do another update to the course. It worked for me but it's not a robust, workable solution that would help everyone else.
The quickest and simple possible change Articulate could make to fix this problem for everyone is to add in that error handling I mentioned. ie, to check if the requested bookmarked lesson ID exists before trying to load it, and if it doesn't exist, send the user to the default starting point of the course. That would allow all users to at least access the course materials, but it would only work for courses exported after that fix was added to Rise.
The ideal outcome would be for the Articulate devs to make use of the originalId property of the lesson object to store the originial ID of each lesson. That way, if the requested lesson ID isn't found in the actual lesson IDs, it could then check against the lessons' originalId properties to see if it exists in any of those, and if it does, point the user to that lesson's content.
Hi Andrew! Thanks for sharing your findings. You're correct, the course ID changes when you duplicate/copy/send a course to another author. Ashley explained it in this comment as well.
You may reach out to our team here and we'll continue to work with you to correct the issue you are encountering.
Yes, this is a big deal that needs to be addressed. Updates to RISE E-learning courses after LMS publication should be a routine occurrence. Instead it's a real pain trying to make a simple text change and replacing the SCORM/ republishing while still keeping the existing course completions intact. Dear Articulate team, please fix this.
Using Moodle LMS and we have to set the SCORMpackage to force a new try for the user when launching the scorm file. This isnt a good solution for our bigger courses tho.
Did you try the fix that I suggested in this thread? It involves deleting user's lesson location, but not their progress. If you don't have direct access to your Moodle database, you can achieve the same thing with Configurable reports Moodle plugin, I believe.
Articulate Team, is there any fix to this issue? Whenever a new SCORM is uploaded to the LMS, users cannot view the Rise content and the screen shows blank. Also, users who have previously launched the content (and have not completed the SCORM) are also presented with a blank screen instead of the new SCORM. I need to manually delete previous attempts in order for the user to view the new SCORM content. As of now it only occurs with Rise 360.
Weighing in here with what we've seen with this issue over in our neck of the woods (we use Moodle and Rise).
In our testing we found that the "Reset Learner Progress" toggle works for our needs. The key thing we found out is that the progress is only reset when a new course version is uploaded. At first blush we thought this toggle would always reset the learner's progress (like if they simply left the course), but we found out that isn't the case.
It looks like that toggle will detect if a learner has old suspend data related to an old version of the course, and if the toggle is turned on it'll reset all the learner's suspend and bookmarking information when they next launch the course (resetting the course completely).
We also noticed what seems to break things (like Andrew mentioned above) - Lesson ID's and course structure.
For Lesson ID's we found that if we duplicated the course all the ID's would change completely. But if we only edited lessons in the original course the ID's would remain the same! I think there was another suggestion around here somewhere before to use the duplicate feature for keeping archives of older versions, and keep the original course to make updates in. A bit backwards from the norm, but now we know why!
So the lesson ID's only remain the same in the original course. And if you duplicate the lesson inside the course, the duplicate receives a new ID (which makes sense). So why doesn't Articulate store the ID's in user suspend data though? No idea, but we suspect it has something to do with supporting the older SCORM standards (they had some seriously strict suspend data limits). The lesson ID's on a large course would chew into a lot of suspend data storage space.
In our experience we found that as long as we made edits to the original course, and ensured that Reset Learner Progress was enabled, if a learner had old suspend data for a previous version it would bring them back to the start of the lesson and reset all progress.
A huge help to us for figuring this out was for us to enable the LMS debugging. When we ran into the blank page on version update problem the debugging log had some helpful text that showed why it wasn't resetting things. Wish I could remember what it said though...it's been a while, sorry.
We also wondered why we couldn't have an option to either reset the progress (if a learner encounters an error loading the course), or to keep the suspend data and location (if it's a new version but doesn't run into an issue). But when we started to think about things the complexity on choosing when to restart a course and when to let a learner use old learner data started to ramp up and made for some slightly grumpy Instructional Designers on our end.
It'd be amazing if there were some standards for eLearning that handled course versioning logic/rules so none of us would run into this problem in the first place, but sadly it looks like that was never done.
106 Replies
We also have to continue living with this problem and there is no solution other than resetting the learner's progress. And not even that always works, sometimes only in combination with the user deleting the cookies & site data in the browser.
I absolutely cannot understand how this problem is simply "ignored" by Articulate when it affects so many users and companies.
Indeed. Seems a bit weird how it's seemingly neglected. Our solution has been to
a.) not use Rise, and instead use storyline
b.) In the case someone has to use Rise they break it into smaller courses
c.) Where there has to be re-made, transfer / make the course in storyline and swap it.
Neither of these alternatives are good alternatives. So of course it would be way better if there was a fix so Rise could be used without having to reset learner-progress.
For those who use Moodle LMS, the workaround is to access the database through a database client (for example mySQL Workbench if you use mySQL database) and run the following SQL command:
delete from mdl_scorm_scoes_track where scoid=XXXX and element='cmi.core.lesson_location'
Replace XXXX with scoid of the Rise content. You can find it in URL when you open the lesson even if it's stuck on the blank screen. Use this very carefully, on your own risk, because if you mess up the query, you could loose or damage some data in the database.
This method should not delte the learners progress. It should delete only the location - th point where the user left the content. So it will appear as if he starts from the beggining, but the round circles indicating progress of each lessons should remained filled indicating those lessons are marked as finished.
I suggest you try this first on some sample content. It worked for me very well on several different Rise 360 courses in different Moodle versions.
Thanks very much for your suggestion - we are going to look into that. Another thought we had and am going to try see if it's possible to modify the function SCORM_GetBookmark() in the scormdriver.js file (/scormdriver folder) of the Rise publish to see if we can cause Rise to always start from the opening page even if a bookmark has been set. We'll keep you posted if we find a fix.
I believe I've found a solution to this issue which I've been able to tested successfully in Moodle and may work for other LMSs as well:
1. Unzip the Rise SCORM 1.2 zip package (I haven't tested this for SCORM 2004) and locate the file scormdriver.js in the /scormdriver folder.
2. Open scormdriver.js in Notepad or other text editor.
3. Locate this function, and highlight the entire line:
function SCORM_GetBookmark(){WriteToDebug("In SCORM_GetBookmark");SCORM_ClearErrorInfo();return SCORM_CallLMSGetValue("cmi.core.lesson_location");}
4. Replace it with this function:
function SCORM_GetBookmark(){WriteToDebug("In SCORM_GetBookmark");SCORM_ClearErrorInfo();return "";}
This basically disables the bookmark retrieval code so that while all the learner completion and progress status is retained (and shows on the left side Rise menu), it causes Rise to always restart at the opening page.
Then re-zip up the Rise SCORM package (make sure to create the zip from the root folder of the course) and re-upload to the LMS.
Hello Michael, thanks but for some reason, this doesn't work anymore (it used to). I think RISE made some updates and I can't find this line anymore:
"function SCORM_GetBookmark(){WriteToDebug("In SCORM_GetBookmark");SCORM_ClearErrorInfo();return SCORM_CallLMSGetValue("cmi.core.lesson_location");}"
Any ideas?
Thanks
It's fine I found the line, it's been moved but it's still there in the scormdriver.js
This whole thing is just annoying - making changes to a Rise project with 3K users already enrolled...I do hope the Articulate team takes this seriously and provides a fix. It is a BIG deal.
Glad you found the line in scormdriver.js, Robert.
When you made the suggested changes to it, did you find it worked for you as well? And just so others will see, what LMS are you on?
Thanks!
Yes, it does work, Michael.
We are using Totara LMS here in the UK. Publishing RISE courses with SCORM 1.2...
Thanks,
Robert
We are also using Totara! You had success with this update? I
Yeah - however, apart from the above, we are also keeping the same course identifier from the old SCORM. So we just copy/paste that in the new imsmanifest xml file after publishing the new SCORM. Not sure if it helps...
Yes, I know what you mean. That is an issue with Totara and replacing SCORM. I wish they would fix that issue.
I had to work around this problem yesterday myself and I can assure everyone that this problem is not an LMS issue. It is specific to Rise.
The problem is that Rise uses unique IDs for each lesson in a course, and these unique IDs change when you duplicate/copy/send a course. So, if you duplicated the course to do a version update, or if you sent the course to someone else so they could do a version update, the new version of the course will have different lesson IDs.
The lesson IDs are used for bookmarking, so if you overwrite an existing course in your LMS with a new a copied/sent version, all existing users who had previously accessed the course will now have a bookmark for a lesson ID which doesn't exist in the updated version of the course.
When the Rise course cannot find a lesson with the ID matching the user's bookmark, it generates an error, and it's at this point the updated course is breaking.
It would be simple for the Rise course to first check if the lesson ID exists before attempting to load the lesson data, but that's not happening at the moment, so the resulting error is what breaks the course.
Some LMSs, such as SCORM Cloud notice the error and respond to it by redirecting the user to the start of the learning content. That doesn't solve the underlying problem of the differences between IDs, but it at least allows users to access the learning materials, albeit after losing any progress they had previously made.
I'm a developer so I was able to add some javascript to indexAPI.html to catch any attempts to load an outdated lesson ID and point it to the equivalent new lesson ID instead, but I had to collect the list of old and new IDs first for that to work, and I'd potentially need to update those lists of IDs in the future if we do another update to the course. It worked for me but it's not a robust, workable solution that would help everyone else.
The quickest and simple possible change Articulate could make to fix this problem for everyone is to add in that error handling I mentioned. ie, to check if the requested bookmarked lesson ID exists before trying to load it, and if it doesn't exist, send the user to the default starting point of the course. That would allow all users to at least access the course materials, but it would only work for courses exported after that fix was added to Rise.
The ideal outcome would be for the Articulate devs to make use of the originalId property of the lesson object to store the originial ID of each lesson. That way, if the requested lesson ID isn't found in the actual lesson IDs, it could then check against the lessons' originalId properties to see if it exists in any of those, and if it does, point the user to that lesson's content.
Hi Andrew! Thanks for sharing your findings. You're correct, the course ID changes when you duplicate/copy/send a course to another author. Ashley explained it in this comment as well.
You may reach out to our team here and we'll continue to work with you to correct the issue you are encountering.
This is still happening in 2022....
This is still happening to me in December 2022
Yes, this is a big deal that needs to be addressed. Updates to RISE E-learning courses after LMS publication should be a routine occurrence. Instead it's a real pain trying to make a simple text change and replacing the SCORM/ republishing while still keeping the existing course completions intact. Dear Articulate team, please fix this.
Any updates on this? I have 22 courses that needed updating and can no longer be uploaded into the LMS. I have no idea what to do now.
Emma, which LMS system do you use? Do you have direct access to it's database? Maybe I can help.
This is still happening in 2023..
Using Moodle LMS and we have to set the SCORMpackage to force a new try for the user when launching the scorm file. This isnt a good solution for our bigger courses tho.
Any updates?
Ditto for me too. I've spent so long on this until I found this page & comments. A fix would be nice.
BTW, the fix mentioned in this thread by Rob and Michael. No longer works. I use moodle.
cheers
Did you try the fix that I suggested in this thread? It involves deleting user's lesson location, but not their progress. If you don't have direct access to your Moodle database, you can achieve the same thing with Configurable reports Moodle plugin, I believe.
Articulate Team, is there any fix to this issue? Whenever a new SCORM is uploaded to the LMS, users cannot view the Rise content and the screen shows blank. Also, users who have previously launched the content (and have not completed the SCORM) are also presented with a blank screen instead of the new SCORM. I need to manually delete previous attempts in order for the user to view the new SCORM content. As of now it only occurs with Rise 360.
Hello everyone,
Weighing in here with what we've seen with this issue over in our neck of the woods (we use Moodle and Rise).
In our testing we found that the "Reset Learner Progress" toggle works for our needs. The key thing we found out is that the progress is only reset when a new course version is uploaded. At first blush we thought this toggle would always reset the learner's progress (like if they simply left the course), but we found out that isn't the case.
It looks like that toggle will detect if a learner has old suspend data related to an old version of the course, and if the toggle is turned on it'll reset all the learner's suspend and bookmarking information when they next launch the course (resetting the course completely).
We also noticed what seems to break things (like Andrew mentioned above) - Lesson ID's and course structure.
For Lesson ID's we found that if we duplicated the course all the ID's would change completely. But if we only edited lessons in the original course the ID's would remain the same! I think there was another suggestion around here somewhere before to use the duplicate feature for keeping archives of older versions, and keep the original course to make updates in. A bit backwards from the norm, but now we know why!
So the lesson ID's only remain the same in the original course. And if you duplicate the lesson inside the course, the duplicate receives a new ID (which makes sense). So why doesn't Articulate store the ID's in user suspend data though? No idea, but we suspect it has something to do with supporting the older SCORM standards (they had some seriously strict suspend data limits). The lesson ID's on a large course would chew into a lot of suspend data storage space.
In our experience we found that as long as we made edits to the original course, and ensured that Reset Learner Progress was enabled, if a learner had old suspend data for a previous version it would bring them back to the start of the lesson and reset all progress.
A huge help to us for figuring this out was for us to enable the LMS debugging. When we ran into the blank page on version update problem the debugging log had some helpful text that showed why it wasn't resetting things. Wish I could remember what it said though...it's been a while, sorry.
We also wondered why we couldn't have an option to either reset the progress (if a learner encounters an error loading the course), or to keep the suspend data and location (if it's a new version but doesn't run into an issue). But when we started to think about things the complexity on choosing when to restart a course and when to let a learner use old learner data started to ramp up and made for some slightly grumpy Instructional Designers on our end.
It'd be amazing if there were some standards for eLearning that handled course versioning logic/rules so none of us would run into this problem in the first place, but sadly it looks like that was never done.