conversion from RH to Flare - in-app links no longer work

[llittle]

Hi, I've converted a Robohelp project to Flare, and excluded the Content folder so the output file structure is identical to the Robohelp project. But the client reports that his in-app links no longer work:

An example of an old link is:
../default.htm#t=Contacts%2FFiveStreet_Integration.htm
While the new link is simply:
.. /Contacts/FiveStreet_Integration.htm
I tried using the old link with the new files, but it does a redirect to ../t=Contacts/FiveStreet_Integration.htm and results in a 404 error. Manually removing the ‘t=’ from the redirected path makes it work. Maybe this helps.
Is it possible that there might be some ‘compatibility mode’ setting, or another way to get around this?

Any advice? I don't understand why the initial links are so convoluted, and why they don't still work since the file paths are the same. Will this necessitate a manual clean-up (to remove the t= as he says), or is there something I can do at my end in the output generation?
I didn’t know they were doing these links. They probably located them from the help file itself rather than just using the file path directly. Client is hoping to avoid manual edits but I don’t think there’s any way around it.

[Nita Beck]

Welcome to the forums!

I haven't converted a RH project for a long time, but your description hints at an issue with the map IDs needed for context-sensitive help (CSH).

Is there a .h or .hh file that came in from RH? You may need to create a Flare alias file to provide the mapping from the identifiers that are in that .hh file to their corresponding topics where they are located in the Content Explorer. I can't recall if a RB import should have automatically created a Flare alias file or if you must create one manually, post import. Check out https://help.madcapsoftware.com/flare20 ... -Files.htm.

I don't think the issue has to do with the fact that you've instructed Flare not to include the Content folder in generated output.

And a final thought: Importing legacy content from an old tool will ALWAYS require cleanup in Flare post import. Generally, the cleaner the legacy content, the less cleanup there will be to do in Flare. I recollect that my RB-sourced content always required a lot of cleanup in Flare to get rid of an abundance of unnecessary inline formatting. But I digress from the issue you're trying to solve...

EDIT: I read your post really fast when I posted my first response. Now I notice that you've said your app developer might have linked topics by URL path. That's not a good idea. You really should convince them to use identifiers such as numbers. That way, you as the author are free to organize files in your Flare project however you want. Flare's documentation includes information for developers, depending on the target type, such as this one: https://help.madcapsoftware.com/flare20 ... lopers.htm.

[llittle]

Thanks Nita, that's what I thought.