Resources do not refresh

I've recently had some problems with resources (files).  In one case I published my project and one of the resources had been moved so when I went to test the published version I got a file not found error.  That works as expected, however, I put the file in the correct directory and no matter how many times I republished, I could not get rid of the file not found message. I tried removing and readding  the resource, removing it and renaming it and readding it, resaving the project, etc.  I finally got it to work, but I'm not sure what did it.

Then in a similar situation, I had to update one of the resource files.  It kept the same name, but the content was updated.  Upon republishing the old content is still there.  I got around this by changing the directory name (where I was keeping all the resources for this project), and going to the player and changing the location of each resource.  A lot of work.

It seems that these are both related to being able to get storyline to refresh or reload the resources at publish time.  Is there a way to force that?

Thank you,

Mary

36 Replies
Adrian Dean

Hi Mary,

Welcome to Heroes. I am glad that you were able to solve your problems. The next time you are able to reproduce the issue, submit a support case. Make sure to upload your .story file.

Create a screencast using this link  to show the issue and then include the link to the screencast when you submit a support case.

We'll be able to take a look and see what may be causing the problem and if necessary get it fixed.

Always Happy to Help,

Adrian

Mary Skipp

I am not sure a screen cast would help in this case.  I'm sure you can reproduce it.  Just add a pdf resource and publish, then change the content of the pdf, go into the player and resave the resource, then republish. You will not see the new content.  I saw it in both the CD version and the SCORM version.  I came up with a work around (to change the resource directory name) after many many hours of trial and error.  What is needed is a way fo force the software to reload the resources at publish time.

Unfortunately, I can not upload my story as it is for a govt. client.  However, I just reproduced it using the big-quiz example I downloaded from your site. It is simple to reproduce. 

-Mary

Mary Skipp

I only changed the original file. I create a directory called “Resources” where I store all the original files.   The published output folder doesn’t contain the updated file after I change it and republish (I assume that is the problem, perhaps if I had replaced that file it would work but I didn’t want to touch any of the published output). 

This reproduction case is simple, during my actual problem I changed the file name as well, repointed the resource from within the player, and it still did not refresh.   What I was doing was including a pdf version of the course in the resources, so as I was doing final tweaking, I republished the word version of the course and saved it as pdf, then I couldn’t get my course to include the new version.

-Mary

Adrian Dean

Hi Mary,

I tested it myself. It's not a bug, but rather designed that way. Take a look at this tutorial. When you want to change something within one of the attachments on the Resources tab, you have to delete the existing one and replace it with the one that is changed. If the file name has changed, then an edit will accomplish the same thing.

Alternatively:

Doing like I described earlier, if you go into your published output folder you will see your file in the external files folder within story_content. If you make changes to that document there, such as swapping it out for another or changing something within, it will reflect the changes when viewed.

Both of the above have been tested and work.

Adrian

Mary Skipp

I am not sure I understand, the first procedure (which is the correct one) does not work.  I can easily reproduce it.

1. Add a resource (in this case a pdf file called Test.pdf  with content one word  "ORIGINAL")

2. Publish, launch_story.exe, view resource and see it says "ORIGINAL"

3. Create a new pdf file with content one word,  "MODIFIED"

4. Replace the original pdf file with the new modified pdf file

4. Go into the player, resources tab, view the resource in question, it should already be pointing to the correct, newly updated file

5. Click save

6. Click OK to exit player

7. Republish

8. Lauch_Story.exe

9. Open the resource from the resources tab and note that tne file that shows up says "ORIGINAL" (not "MODIFIED" as you would want)

While I believe your second solution will work as long as the file name is exactly the same. I don't think it is good practice to be changing the published output. It is hard to document, and could be easily missed on a subsequent update.

-Mary

Adrian Dean

Hi Mary,

You are correct about changing the published output directly. That's why I said it was an alternative.

In order to get your changes to reflect, you need to go into your Storyline project. Go to the resources area of the Player and delete the existing attachment. Then add the changed attachment. This applies even if they have the same file name. Just changing the original file won't do it.

Adrian

Robert Stewart

Or fix the problem.

When you publish the program code should look for the file. If it is missing from the host computer give a warning then ask if you want to remove the file from the resource list or try to find it's location on your hard drive.

If the file does exist then check the last modified stamp date.

If it is newer ask the same question or have a check box to always replace with newer files.

Make sense?

It's now August 2014

Ashley Terwilliger

Hi Robert,

I know this thread is a bit older, but since this is currently by design it will need to be a feature request. With that in mind, we are still in version 1, update 6 of Storyline - so new features and additional elements I would expect in a future version of Storyline.

In the meantime, Adrian did provide an alternative method with how you could change it in the published output.

Pete K

I've also experienced the same problem as Mary Skip and it typically involved the use of an updated PDF document in which the file name stayed the same but the published link still led to the previous version. My only workaround was renaming the file and, voila...problem solved. It's not a consistent issue, but since clearing the browser cache wouldn't solve the problem, this seemed like the only solution for me. I can't recall experiencing this in a while so it may be resolved due to a recent update. However, if I experience it again, I'll post back.

Pete K

I just experienced this issue again today (10-24-14). While typical Word and PDF attachments updated fine without having to re-upload the document or rename it (just maintained link to revised document), the issue occurred when I updated a document inside a zip folder. Relinking to the zip folder or re-zipping folder didn't help. Even renaming the project didn't help. The only solution was to rename either the zip folder or the document inside the zip folder. I even placed the course on a different site and accessed it from a different computer with the same results. Truly odd!! This is why I don't assume documents will automatically refresh when keeping the same title. Hopefully, the new Storyline 2 addresses this issue.

Ashley Terwilliger

Hi Dick,

They could still be accessing a cached copy if it was previously tested there as well. An easy way to confirm this for yourself is upload the latest version of your .story file to a site such as SCORM Cloud. 

If you can't upload there, I'm happy to help you with that. Share a copy of your .story file here and/or the published output folder zipped up. 

Albert Vis

Also having this issue.

I added several web-objects to different frames. Then I worked in the "offline folders" and changed content in those folders (like .js files, images, html, etc.)

But when exporting, Storyline gives me the old files and does not even look at the updated folders.

So folders are not renamed, nor the link in Storyline is renamed. Only content in the "offline folders" are changed. 

Can't find any help on the internet on how to tackle this. 

Deleting folders and or renaming them or updating the export manually... All will be imense work, so rather some kind of option or advice on how to purge the storyline "export cache" with every export would be appreciated. 

Cheers.

Albert Vis

Thanks Phil, I indeed noticed that. But this is not really a workable solution for us and our clients. It would cost us immense time of mindnumbing repetitive (error prone) work to solve a little change (we are not talking about 3 or 4 folders here).

Besides this, we also found it in other Storyline outputs that did not had any webobjects.

I also do not understand where the old output is comming from. If I knew that, (ie.g. if it is cached somewhere?) I could do something with that. But I did not found anything in any folders nor any information on that in the help or on the web. 

So anyone?

This is a major issue that in my opinion needs to be solved properly and not by using a work around solution to solve it! Hope that it will be adressed somewhere in time. 

Anyway thanks.

Ashley Terwilliger

Hi Albert,

Perhaps I'm not clear on what you're doing with the "offline folders" but it does sound like you're making those changes in the published output since you mentioned files like .js, html, etc. That's not something I can offer support on.

If you have a problem within the .story file where you're making changes and those aren't being reflected upon publish - I would love to take a look. Upload a copy of your .story file here and we'll be happy to test it out. 

Albert Vis

Hi Ashley,

Thanks for you reply much appreciated.

On your comments: No it is not changed in the output. Changes are being made in the folders where the "webobject" is linked to. But then if a new publish output is generated, old items are shown in the linked webobjects. So things are not updated along with a new output.

It seems like an earlier publish will result in a "cache" item where storyline somehow saves old output content somewhere that is generated earlier. Then when a publish update is done, it somehow looks like storyline does not look at what happened to the webobject content outside of storyline if the folder and index.html name remain the same. It just shows old content.

Unfortunately I can't show you the file as we already did manual updates.

But try it with e.g. a webobject linked to a external folder that holds an index.html a css file and a .js file. Then change the files, like add a different index.html, 2 more css files and another js file and a folder with images (but do not change anything within storyline or with the names of the folder). In our case the new files were not taken into the new output.

Like I said, can't find any info on how storyline tackles or treats published updates. Any info on the subjects above mentioned would be greatly appreciated.

Will await any feedback.

Cheers!

Phil Mayor

Local web objects are saved to the storyline file itself and are not editable without replacing the web object.

You can unzip the storyline file and edit the web object folders in there.

Storyline only looks at the web object the first time you attach it, this is the same behaviour when attaching resources.

You can of course change the folders in the output.

Albert Vis

Hi Phil,

Thanks for the feedback. It is true that it is possible but working in the unzipped published scorm files is no "solid correct" option nor the right solution. It also can lead to import errors depending on your type of LMS.

I get regullary customers and developers on the phone for advice that have the same issues, I cannot advice them to do the complex or workheavy solutions.

When you export work in any software you should be ensured that what you have in your slides is taken into the export. Like Adobe, software from Adobe gives distinct warnings if content is misplaced, replaced or deleten.

It is really a reliability issue and that has some impact for developers. So the only thing we can do is wait until the issue will be resolved in a future update. But since this issue has been persistent for about six years I fear that maybe different solutions need to be considered?

Cheers.