Hello. After moving my audio play button on slide 1.7 and resizing the answer choices so they don't cover the button, I republished. But the answer choices still cover the button AND
I noticed that the drag and drop slide 1.8 is totally messed up...but when I published the first time it worked fine. I've cleared cache, I'm saving to my HD, program is up to date and I'm uploading to a server.
Several of us keep having this issue - Chrome and Storyline are NOT playing well lately. I cleared cache with hard reload in dev tools, and all time files/history, but we are not allowed to use incognito mode at my company. Is there some way to flush cached info somewhere ELSE in Chrome? We are an xAPI-only house these days, so the course remembers your progress, but that's okay, it's just the cached files. It may be related to xAPI, so if someone could help, that would be amazing. Not sure if I need to make a new discussion on it, or if someone will check this comment soon.
I'm glad to help out! The original issue raised in this thread was for troubles with saving edits that were made to a course during republishing. Are you experiencing a similar issue when publishing your course and uploading it to your LMS? If so, I'd like to ask a few questions to help clarify your experience:
Have you tested the issue in SCORM Cloud? Testing the issue in another LMS is a great way to identify if it is something specific to your LMS.
Does your LMS have the option to clear its cache before you upload a different version of your course?
Does your LMS have course versioning enabled? This means that users who have already started a course will see an older version of you upload a new version while they are in the middle of taking your course.
Are you able to replicate the behavior when you publish to Web or Review 360?
When I changed the folder on our repository where the published files were stored, it was fine - that is, when the URL changed, then Chrome let go of the cache. The files WERE updated in the repository with no issues, it's just that Chrome/Storyline player didn't want to show them and were showing old, cached versions. Making a new folder for every upload is not an option lol.
I'm not sure if there's some kind of Javascript command we can do at course launch to flush cached versions, but my organization locks down a lot of things, such as cleaning out browsing history, so I'm not sure if it's a symptom of our environment, but once the URL changed, then I was able to see the updated published version of the course.
We are NOT using an LMS, but a web content server - there is versioning, so I removed all the published files in the folder prior to uploading the new version, and have not had problems with this process before.
I'll see if HTML5 will produce similar results - other coworkers have experienced this issue. It's not consistent, sadly, so I was just wondering if anyone had any tricks.
Thanks for the additional information. I'm not very familiar with web content servers, but it sounds like treating the newer versions of your course as new courses addresses the issue, possibly indicating that the issue is related to the cache like you said.
I'd first recommend trying to publish multiple versions of your course to Review 360. If you are unable to replicate the behavior there, then we can isolate it to something that is specific to your web content server. If this is the case, your IT staff will know how best to fix it.
7 Replies
Some browsers are pretty persistent, even with cleared cache. Try using a private or incognito window to view it.
Thanks. Tried that with no luck. I even duplicated the slide and deleted the old one to see if the 'bug' went away.
Ah! I saved it with another file name. No amount of deleting cache was working. Fixed. :)
Several of us keep having this issue - Chrome and Storyline are NOT playing well lately. I cleared cache with hard reload in dev tools, and all time files/history, but we are not allowed to use incognito mode at my company. Is there some way to flush cached info somewhere ELSE in Chrome? We are an xAPI-only house these days, so the course remembers your progress, but that's okay, it's just the cached files. It may be related to xAPI, so if someone could help, that would be amazing. Not sure if I need to make a new discussion on it, or if someone will check this comment soon.
Hi Erica,
I'm glad to help out! The original issue raised in this thread was for troubles with saving edits that were made to a course during republishing. Are you experiencing a similar issue when publishing your course and uploading it to your LMS? If so, I'd like to ask a few questions to help clarify your experience:
Joe,
When I changed the folder on our repository where the published files were stored, it was fine - that is, when the URL changed, then Chrome let go of the cache. The files WERE updated in the repository with no issues, it's just that Chrome/Storyline player didn't want to show them and were showing old, cached versions. Making a new folder for every upload is not an option lol.
I'm not sure if there's some kind of Javascript command we can do at course launch to flush cached versions, but my organization locks down a lot of things, such as cleaning out browsing history, so I'm not sure if it's a symptom of our environment, but once the URL changed, then I was able to see the updated published version of the course.
We are NOT using an LMS, but a web content server - there is versioning, so I removed all the published files in the folder prior to uploading the new version, and have not had problems with this process before.
I'll see if HTML5 will produce similar results - other coworkers have experienced this issue. It's not consistent, sadly, so I was just wondering if anyone had any tricks.
-Erica
Hi Erica,
Thanks for the additional information. I'm not very familiar with web content servers, but it sounds like treating the newer versions of your course as new courses addresses the issue, possibly indicating that the issue is related to the cache like you said.
I'd first recommend trying to publish multiple versions of your course to Review 360. If you are unable to replicate the behavior there, then we can isolate it to something that is specific to your web content server. If this is the case, your IT staff will know how best to fix it.