I have a project file on my computer titled "Project 1" (not the real project name, just for example purposes). When I published the Storyline file for the LMS, I did not get a warning that there was already a folder with the same name on my computer that would have given me any indication there was a problem. However, when I went to the "Project 1" folder on my computer, most of my files are missing from that folder and have been replaced with the LMS output files, despite the fact that the files were categorized in folders with names different from the output files.
I've worked in Storyline for 10 years and have never had this happen. When I try to revert to a previous version of the folder, it says there are no previous versions.
Has anyone had this happen, and if so, did you find a way to recover the lost files???
Great question! I understand your folder was overwritten when you published a course with the same title in the publish settings. I'm so sorry that happened to you. Let me get you some information about that.
After testing this out on my own project, I experienced the same behavior. No warning appeared when publishing a course with the same name. This is the intended behavior when publishing to LMS. I have included a Peek recording of the behavior below.
I have just experienced I think, the same behaviour. I published a file back to it's folder and in the process, a significant number of files and folders asscociated with the build are now gone. I have lost a massive amount of work. All that is in the folder are the punlished files. No source assets other than some archived videos. This is very concerning.
So just republished again. If you choose to publish a file to your SL working folder, SL is not creating a new publish folder like it has has in the past. It seems to be just writing over files in the working folder. Not good!
Sorry to hear that you ran into a similar issue. I tried replicating the behavior you reported but on my end, Storyline 360 first created a folder before publishing the course. No other files were deleted in the process. Here's a screenshot showing where Storyline 360 published the course for me (in the default "My Articulate Projects" folder):
We're also not seeing this being reported by our other users, so there's a chance that the behavior might be isolated. If you're already working locallywhen publishing your project files, would you be willing to make a Peek 360 recordingof the behavior so we can take a closer look at what's happening?
This just happened to me too. My project folder and storyline export have the same name. Exporting wrote over the project folder so now all I have is the last version's export. I tried to quickly save-as the storyline file and it crashed. It wrote over several sub-folders, itself (i.e., storyline file), PDF documents, Word documents, folder short cuts, etc. How is this possible with no error!! It deleted it's own source file while exporting itself!
There should still be a fail safe. I can't save a pdf with the same name with out a pop-up if I want to replace the existing file! Glad there are at least temp files to restore the storyline file, but there should be some recognition that it's not replacing an export folder or that it lives in that folder.
No offense to anyone but I am not new to Storyline. I have been publishing in the same way since Storyline came out. I do know how it works as I have developed hundreds of courses and published for LMSs in SCORM 2004, SCORM 1.2 and AICC, along with publishing for WEB and frankly any other way to publish.
This is the first time I have seen this behaviour and it is startling! In know way should authoring software overwrite/erase its own assets.
There is a glitch somewhere and I will try to recreate it and document my exact steps so that I solution can be found. I will also change my process to avoid this happening in the future but will have to have my other developers follow suit moving forward as we cannot afford the extra time necessary to rebuild the folder structure!
Also curious at what point, if any, storyline will give an error? Can I delete software applications or system default folders by exporting?? Seems like it would be easy to minimally have a check that the folder it's deleting is an existing export folder and if not have some sort of indication that you might be making a mistake.
Thank you for the feedback. This however is the problem and Articulate should fix the issue by retaining the ouput folder. I resolved the issue by creating a publish folder however developer processes should not have to change due to a bad update. Fix the issue do not force users to change their work flow/process.
As well, this should be flagged very clearly in some form of update alert. I am sure I am not the only developer that wasted significant time trying to figure out the issue, and then have to recreate all assets from a project. Luck for me I back up regularly to an external drive. other I am sure are not so lucky!
12 Replies
Hi Lauren,
Great question! I understand your folder was overwritten when you published a course with the same title in the publish settings. I'm so sorry that happened to you. Let me get you some information about that.
After testing this out on my own project, I experienced the same behavior. No warning appeared when publishing a course with the same name. This is the intended behavior when publishing to LMS. I have included a Peek recording of the behavior below.
LMS Publishing Test
Unless you have made a backup of the folder, once a folder is overwritten there is no way to retrieve it.
I hope this clarifies things.
I have just experienced I think, the same behaviour. I published a file back to it's folder and in the process, a significant number of files and folders asscociated with the build are now gone. I have lost a massive amount of work. All that is in the folder are the punlished files. No source assets other than some archived videos. This is very concerning.
So just republished again. If you choose to publish a file to your SL working folder, SL is not creating a new publish folder like it has has in the past. It seems to be just writing over files in the working folder. Not good!
Hi Dave,
Sorry to hear that you ran into a similar issue. I tried replicating the behavior you reported but on my end, Storyline 360 first created a folder before publishing the course. No other files were deleted in the process. Here's a screenshot showing where Storyline 360 published the course for me (in the default "My Articulate Projects" folder):
We're also not seeing this being reported by our other users, so there's a chance that the behavior might be isolated. If you're already working locally when publishing your project files, would you be willing to make a Peek 360 recording of the behavior so we can take a closer look at what's happening?
This just happened to me too. My project folder and storyline export have the same name. Exporting wrote over the project folder so now all I have is the last version's export. I tried to quickly save-as the storyline file and it crashed. It wrote over several sub-folders, itself (i.e., storyline file), PDF documents, Word documents, folder short cuts, etc. How is this possible with no error!! It deleted it's own source file while exporting itself!
if you publish, the first action of storyline is to complete delete the destination folder
storyline uses as destination folder a combination of "Folder" + "Title"
in this example "D:\Projekte_P4\Storyline\my title of the course is very very\" *
if the folder exist, all files in this folder are deleted - regardless of whether they are files from storyline or another program
* storyline 3.78 only allows 8 words for the publish folder
There should still be a fail safe. I can't save a pdf with the same name with out a pop-up if I want to replace the existing file! Glad there are at least temp files to restore the storyline file, but there should be some recognition that it's not replacing an export folder or that it lives in that folder.
No offense to anyone but I am not new to Storyline. I have been publishing in the same way since Storyline came out. I do know how it works as I have developed hundreds of courses and published for LMSs in SCORM 2004, SCORM 1.2 and AICC, along with publishing for WEB and frankly any other way to publish.
This is the first time I have seen this behaviour and it is startling! In know way should authoring software overwrite/erase its own assets.
There is a glitch somewhere and I will try to recreate it and document my exact steps so that I solution can be found. I will also change my process to avoid this happening in the future but will have to have my other developers follow suit moving forward as we cannot afford the extra time necessary to rebuild the folder structure!
Also curious at what point, if any, storyline will give an error? Can I delete software applications or system default folders by exporting?? Seems like it would be easy to minimally have a check that the folder it's deleting is an existing export folder and if not have some sort of indication that you might be making a mistake.
I saw no indication that anything was going to be over written.
this problem started with SL 3.70
before SL 3.70 the (auto deleting) publish folder was
now it's
so the problem can occur much more easily if you are not paying attention
but there is a simple workaround, create 2 folder on your data drive
put all your sources, ... in the first folder and publish always to the second folder
Thank you for the feedback. This however is the problem and Articulate should fix the issue by retaining the ouput folder. I resolved the issue by creating a publish folder however developer processes should not have to change due to a bad update. Fix the issue do not force users to change their work flow/process.
As well, this should be flagged very clearly in some form of update alert. I am sure I am not the only developer that wasted significant time trying to figure out the issue, and then have to recreate all assets from a project. Luck for me I back up regularly to an external drive. other I am sure are not so lucky!