1 Reply Latest reply on Jan 3, 2009 11:11 AM by robva65

    Hyperlink Issue In Presenter

      Hello all,

      I'm having an issue with a presenter for a client of mine.
      They want to link the buttons at the on of the presentation not to a url but to a extention of a url that will automatically locate to the domain that it's filed under.

      They would like the links to be: Contact/index.htm
      NOT www.testclient.com/sub/Contact/index.htm

      The reasoning for this is because they will be relocating the files of the presenter to different directories frequently to associate with different programs.

      The issue i'm getting is when these are published to the web and the links are clicked, an extra extention of "/data/resources/ is being added to the link so it's more like:


      Has anyone come across a stumping problem like this before?
      Please help. They're very urgent....

      Thank you,

        • 1. Re: Hyperlink Issue In Presenter
          robva65 Level 2

          The problem you're experiencing has to do with the way in which Presenter content references local vs. absolute links.

          This was (and actually, it still IS) a persistent problem that many, many folks have inquired about.

          I'm fairly certain that regardless of which version of Presenter you have installed (6 or 7), when you use hyperlinks that call relative addresses (e.g. /contact/index.htm), by the time you publish that content, Presenter will always default to the data/resources directory of your presentation. This wasn't so much of an issue with Presenter's predecessor Breeze, but it doesn't help much with Presenter 6 or 7.

          One thing that we have managed to work out is a hack; meaning that within the resources directory of a published presentation, we added an index.htm file that contains a script that forces a redirect to a landing page elsewhere on a server. This way, as soon as a button is clicked, the redirect page shows up...and on that redirect page, a message is displayed informing the viewer that they're about to be taken to a totally different location. It's by no means a clean solution...but without using absolute " http://" protocols, there wasn't much of a choice.

          The other downside to this approach is that anytime you change where folks are being redirected to, you're forced to edit the htm page within the resources directory of your published content.