External files not being included when publishing

Has anyone else encountered this?

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. 

15 Replies
Leslie McKerchie

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?

Randall Sauchuck

'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.

Leslie McKerchie

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.

Randall Sauchuck

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.

Walt Hamilton

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.

Ashley Terwilliger

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.

Randall Sauchuck

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:

  1. I link a pdf on page 10 of the Storyline file
  2. I copy the .story file to the server
  3. 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
  4. He copies the file back to the server
  5. I copy it down and publish
  6. 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. 

 

Walt Hamilton

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

susan jones

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. 

Ashley Terwilliger

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: 

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. 

susan jones

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

Alyssa Gomez

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.

Scott Hewitt

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