I have several topics that have PDFs "attached." Attached isn't the right word. Each of these topics is simply a "blank page" that maps to the PDF asset as its source ("assets/docs/ETF History 2018.pdf").
When you click the title of these pages in the TOC, it should open the PDF in a new browser window. But they've all stopped working when serving my help system from SharePoint. I don't know exactly when they stopped working b/c I don't look at these pages often. But they worked as recently as a month ago.
NOTE: each of these pages operates just fine when viewing the help from my local drive. It's only on SharePoint that I get the "404 not found" error.
Can anyone recommend some troubleshooting for me, please?
Maybe check your sharepoint administrator hasn't changed any permissions or file settings?
Did you rename anything recently? Perhaps check that the location and name of the pdfs in Sharepoint match what the toc is pointing to? I'd compare both your local output and the sharepoint outpoint, just in case something isn't publishing correctly as well.
Thanks for the troubleshooting, Amber. You've led me to the source of the problem.
I had our SharePoint admin look at it. She shared this:
"The URL to the pdf is incorrect which is why it returns an error. The URL ends with an extension of "aspx" rather than 'pdf'. This URL would have to end in 'pdf' for the PDF to be displayed. If you simply replace the 'aspx' at the end with 'pdf' it works. Does RoboHelp generate this URL for you? If so, the issue would be with RoboHelp not generating the correct URL. "
So I'm thinking the problem is the way I've configured these topics. Whatever I've done is causing RoboHelp to generate the .aspx file extension instead of .pdf . I've set them all up the same way, like this one:
Can you tell me how to do it properly?
PS: Setting up the topics as I have works just fine when viewing my help site locally. It's only when serving it on SharePoint that those topics throw the error.
PPS: It's possible that this behavior (the error) has always existed and I just never saw it before b/c it works just fine when viewed locally.
PPPS: One last clue for you. I created each of these problematic topics via the "New page" button.
Is that the problem?
These pages do behave strangely in the authoring pane: if I double-click one of them, no topic opens in the authoring pane, just a blank area. It looks like this:
I would have expected the topic page to be rendered in a .aspx format if going to SharePoint, but the link inside the page should be to the .pdf itself.
Yes, thank you, Jeff. Turns out there actually isn't a topic. Instead of a topic with a link in it, I think the way I set up these pages is that each one is like a link with no topic. And the link is the title in the TOC.
My current setup gives me the behavior I want, when viewing the help site locally (not on SharePoint). I want the end user to simply click the title in the TOC which opens the PDF directly. That's fewer clicks than opening a page and having to click a link on that page.
Any idea how to make that work in SharePoint?
What is the form of the output when you view locally? If it's the same as what's produced for SharePoint, then it should have the same issue - if it's not, then your local test is misleading.
I'm not quite sure what your question is, Jeff. When you say "What is the form of the output when viewed locally?" what do you mean by "form"?
I mean is it a .htm file or a .aspx when you play with it locally?
Oh - locally it's .htm. The output for SharePoint is .aspx.
One clue is that, when viewed in SharePoint, if you click the page title in the TOC, you get the "404 not found" error. And the URL is this:
If I change the .aspx to .pdf, the pdf opens instantly.
As I suspected - I think you need to go with the container (.aspx) holding the link to the .pdf route.
Usually you would stick a link to the PDF inside a topic that actually has some relevance to what the PDF is all about - why not stick it in that "History" topic?
Yes - the container holding the link. That's good advice. That's what I'll do.
Right, great idea. Should I log it as a "bug" or a "feature request"?
Feature request I would suspect
Sounds good. Thanks for suggesting it.