I have a PDF which is accessed via a hyperlink. The file path is correct and the .story file and the .pdf file are on the same hard drive.
When I publish the file the PDF is not automatically copied into the "story_content/external_files" folder. Clicking the hyperlink results in a "file not found" error. However if I manually copy over the PDF, then the link works fine.
The only way to get it to automatically work is to go back into the dialog box for the hyperlink trigger and RE-LINK TO THE EXACT SAME FILE. This is unacceptable.
'What do you mean by: "However if I manually copy over the PDF, then the link works fine."?'
I mean if I use Windows Explorer to copy the PDF to the directory it is supposed to be copied to automatically ('story-content/external-files') then the published course can locate it and it works correctly. For some reason the Storyline publishing process does not copy the file unless I go into the trigger panel, and re-link the pdf before I publish it. This is true even though the path to the pdf is EXACTLY the same. Needless to say this is extremely annoying.
Thanks for the further explanation and for letting me know what version of Storyline you are using.
I am not able to replicate an issue when adding a pdf file to my project. It works when published and is displayed in the output folder you specified above.
I can understand that it would be annoying, especially since it works when you re-link - so it seems to indicate that the file path is okay. Do you have any non-English characters in the filename?
Is this in just a single project file or something you can recreate in general and in any project file?
If it's happening in any/all files, you should certainly conduct a repairof your software, assuming you are on the latest update as listed here.
If you can record this behavior (initially adding a pdf, publishing, checking output file/showing broken in published output) that would be helpful as well or you are always welcome to work directly with a support engineer here if you prefer as well.
Following up. The issue happens when another developer opens the file on their machine. We often have multiple people working on a file by the time it is complete so we transfer it through source control. The links to the external files are not modified by the other team members , but they are still broken when they get back to me.
I know this doesn't help you, but it sounds like when someone else opens the file, SL checks all the links. If that file is on a local drive, but not theirs, it won't be found.
Sounds to me like SL is leaving a note that "This link is broken", and when you get it back, that note is overriding the link. Maybe it's not even checking it again.
Are you linking these files originally from your local drive? I'd agree with Walt's assessment that the link is breaking as the file is transferred around. I'm not familiar with Source control, but I'd also want to make sure that when you all are sharing and transferring files you're following along with the guidelines here for collaborating and our recommendations here to prevent file corruption.
Yes the original files .story and .pdf are on my local hard drive originally. we transfer them via our internal server (client security would never allow the use of external services like DropBox as your article suggests.) Here is a sample workflow:
I link a pdf on page 10 of the Storyline file
I copy the .story file to the server
A colleague copies it down and makes an unrelated edit on page 2 and never so much as LOOKS at the link to the pdf
He copies the file back to the server
I copy it down and publish
Link to the PDF is broken
Why? I mean basically the .story file is just a modified .zip archive. The PDF is still in it, right?
I mean right now I am resigned to the fact that I cannot trust SL to maintain these connections and I have to assume they will break.
If you're able to insert the file into your Resources tab (vs. directly linking it on the slide) that should keep the file connected to the .story file. If you still need to provide the link on the slide itself, you can use the steps here to do so.
I have the same issue with files that get worked on by multiple people - I have to make sure that the PDFs are in the same folder (beside the source file) all the time. If they ever get moved the link will break. Currently I am doing that - and the PDFs are NOT getting moved into an external folder, it is being created in the published file - and is empty and in the zip, it doesn't exist. I have tried copying the PDFs and that folder into the zipped file but it won't work. I haven't had this issue before, it's only happening to me today.
How are you linking the PDF files into your course? Did you test the method I previously shared to add them to your Resources tab as that will pull them into the .story file that you share with colleagues:
If you're able to insert the file into your Resources tab (vs. directly linking it on the slide) that should keep the file connected to the .story file. If you still need to provide the link on the slide itself, you can use the steps here to do so.
I did not try that - as they don't want a "resources" tab in the course.
I did find out what the issue was however. I am running parallels and somehow my dropbox path was changed, so the PC side (where I have storyline) wasn't able to properly connect and keep the files with it when published. I ONLY Run parallels because of Storyline:(
Can Articulate PLEASE make a MAC version of Storyline?
You can actually still use this method, even if you don't include the resource tab in the player. It really is the safest way to ensure that your links don't get broken down the line.
Our team uses Parallels on a Mac also, and we've had lots of success with it! Let us know if you have any more questions about running Storyline on a Mac.
I know this is an old thread, but I don't know if people are still having issues with PDF files or files not appearing in published files.
We had the same issue but after some research and testing worked out the issue and a solution.
We also want to link to PDF files within the content and not via the tab. We use a trigger.
We learnt that linked via a file on a network drive is very unreliable.
We started putting all the files (storyline, PDF etc) on the local drive and publishing. We noticed that the PDF would be missing from the external_files folder.
We tried loads of things - stuff I'm sure you've all tried.
Eventually we realised the problem was the filename length of the PDF or linked file. If we reduced it massively it always worked. I've got one that is about 25 characters at the moment and this works. Anything that is really long doesn't get picked up.
Reduce the filename of your linked file and you should be fine.
I know this is an old thread but just wanted to pop in to say that Scott's solution is what worked for me! I shortened the name of the PDF file that was missing from the published output and re-added it to the Resources tab. Now when I publish the project, the file is in the "external_files" folder as expected.
Hello. I wanted to jump in here as well. This issue happens to me periodically as well. And it just happened again. However, the names of my .pdfs are short. But they are still not being included in the folder when I publish. So I have to manually create the subdirectory and add the .pdfs to the SCORM package. Very aggravating.
It's not just the name of the pdf that counts toward having too many characters. it is the whole path. So moving the file up a few directories may solve your problem.
18 Replies
Hey Randall,
Sorry that you're having difficulty getting your pdf hyperlinks to work in your course.
What do you mean by: "However if I manually copy over the PDF, then the link works fine."?
I'd like to understand your differing approaches to do some testing on my end as I've not seen any issues reported.
Also, what version of Storyline are you using?
'What do you mean by: "However if I manually copy over the PDF, then the link works fine."?'
I mean if I use Windows Explorer to copy the PDF to the directory it is supposed to be copied to automatically ('story-content/external-files') then the published course can locate it and it works correctly. For some reason the Storyline publishing process does not copy the file unless I go into the trigger panel, and re-link the pdf before I publish it. This is true even though the path to the pdf is EXACTLY the same. Needless to say this is extremely annoying.
I am using storyline 3.
After you re-link the trigger, how long can you wait and what activities can you do before it won't copy over the file?
Hey Randall,
Thanks for the further explanation and for letting me know what version of Storyline you are using.
I am not able to replicate an issue when adding a pdf file to my project. It works when published and is displayed in the output folder you specified above.
I can understand that it would be annoying, especially since it works when you re-link - so it seems to indicate that the file path is okay. Do you have any non-English characters in the filename?
Is this in just a single project file or something you can recreate in general and in any project file?
If it's just this file, I would advise to import the file into a new one and proceed.
If it's happening in any/all files, you should certainly conduct a repair of your software, assuming you are on the latest update as listed here.
If you can record this behavior (initially adding a pdf, publishing, checking output file/showing broken in published output) that would be helpful as well or you are always welcome to work directly with a support engineer here if you prefer as well.
Following up. The issue happens when another developer opens the file on their machine. We often have multiple people working on a file by the time it is complete so we transfer it through source control. The links to the external files are not modified by the other team members , but they are still broken when they get back to me.
I know this doesn't help you, but it sounds like when someone else opens the file, SL checks all the links. If that file is on a local drive, but not theirs, it won't be found.
Sounds to me like SL is leaving a note that "This link is broken", and when you get it back, that note is overriding the link. Maybe it's not even checking it again.
Hi Randall,
Are you linking these files originally from your local drive? I'd agree with Walt's assessment that the link is breaking as the file is transferred around. I'm not familiar with Source control, but I'd also want to make sure that when you all are sharing and transferring files you're following along with the guidelines here for collaborating and our recommendations here to prevent file corruption.
Yes the original files .story and .pdf are on my local hard drive originally. we transfer them via our internal server (client security would never allow the use of external services like DropBox as your article suggests.) Here is a sample workflow:
Why? I mean basically the .story file is just a modified .zip archive. The PDF is still in it, right?
I mean right now I am resigned to the fact that I cannot trust SL to maintain these connections and I have to assume they will break.
Why? I mean basically the .story file is just a modified .zip archive. The PDF is still in it, right?
No, the .pdf is not loaded until publish. The external_content folder does not exist in .story. It is created during the publish process.
A colleague copies it down and makes an unrelated edit on page 2 and never so much as LOOKS at the link to the pdf
Maybe it shouldn't do it, but it still sounds to me like SL looks at that link, even if your colleague doesn't.
Since I agree that you have to assume link breakage, I would suggest a workflow that has
1. I copy the .story file to the server
5. I copy it down.
5b. I link a .pdf
5c. I publish
Hi Randall,
If you're able to insert the file into your Resources tab (vs. directly linking it on the slide) that should keep the file connected to the .story file. If you still need to provide the link on the slide itself, you can use the steps here to do so.
I have the same issue with files that get worked on by multiple people - I have to make sure that the PDFs are in the same folder (beside the source file) all the time. If they ever get moved the link will break. Currently I am doing that - and the PDFs are NOT getting moved into an external folder, it is being created in the published file - and is empty and in the zip, it doesn't exist. I have tried copying the PDFs and that folder into the zipped file but it won't work. I haven't had this issue before, it's only happening to me today.
Hi Susan,
How are you linking the PDF files into your course? Did you test the method I previously shared to add them to your Resources tab as that will pull them into the .story file that you share with colleagues:
I did not try that - as they don't want a "resources" tab in the course.
I did find out what the issue was however. I am running parallels and somehow my dropbox path was changed, so the PC side (where I have storyline) wasn't able to properly connect and keep the files with it when published. I ONLY Run parallels because of Storyline:(
Can Articulate PLEASE make a MAC version of Storyline?
Susie:)
Sent from Outlook
Hi Susie!
You can actually still use this method, even if you don't include the resource tab in the player. It really is the safest way to ensure that your links don't get broken down the line.
Our team uses Parallels on a Mac also, and we've had lots of success with it! Let us know if you have any more questions about running Storyline on a Mac.
Hi,
I have the solution.
I know this is an old thread, but I don't know if people are still having issues with PDF files or files not appearing in published files.
We had the same issue but after some research and testing worked out the issue and a solution.
We also want to link to PDF files within the content and not via the tab. We use a trigger.
We learnt that linked via a file on a network drive is very unreliable.
We started putting all the files (storyline, PDF etc) on the local drive and publishing. We noticed that the PDF would be missing from the external_files folder.
We tried loads of things - stuff I'm sure you've all tried.
Eventually we realised the problem was the filename length of the PDF or linked file. If we reduced it massively it always worked. I've got one that is about 25 characters at the moment and this works. Anything that is really long doesn't get picked up.
Reduce the filename of your linked file and you should be fine.
Hope this helps
Scott
I know this is an old thread but just wanted to pop in to say that Scott's solution is what worked for me! I shortened the name of the PDF file that was missing from the published output and re-added it to the Resources tab. Now when I publish the project, the file is in the "external_files" folder as expected.
Hello. I wanted to jump in here as well. This issue happens to me periodically as well. And it just happened again. However, the names of my .pdfs are short. But they are still not being included in the folder when I publish. So I have to manually create the subdirectory and add the .pdfs to the SCORM package. Very aggravating.
Mary-Scott,
It's not just the name of the pdf that counts toward having too many characters. it is the whole path. So moving the file up a few directories may solve your problem.