Relative path problem in offline mode

[yoxallj]

Hi,

I am using Zoom embedded in my own page. Everything has been easy (you seem have thought of everything) except for one problem.

I am using an overall mechanism where users can checkout the site source to any location, perform basic content editing, then build the site offline and upload the final result. As long as all paths are relative I can provide a zoom config file in the source and all users will get the same result.

I have set the Start directory and Output directory to relative paths:
Start directory: ../../release
Output directory: ../../release/php/zoom_search

Because zoom is embedded, the resultant urls should be relative to my search page, which is also in the root of /release, so I set
Base URL: /

But the resultant prefixes (looking in pagedata) are actually ./../release, instead of nothing.

This works ok in offline mode, but is incorrect when /release is uploaded to the root of the live site.

The implication is that it is using the Start directory as well as the Base URL to determine the final path. Why is that, and is there anything I can do to get the desired result?

[Ray]

I'm not entirely sure why the relative paths are necessary here.

If you are generating the configuration file on the fly, you would be able to specify an absolute path for the start directory instead of a relative one.

We never considered allowing Zoom to accept a relative path for the Start Directory, as we had never encountered any scenario where this would really be necessary (nor have we had any users ask us for this before). If you look in the "Log" tab, you'll notice during indexing that giving Zoom a relative path doesn't allow Zoom to determine where the files are actually located, they're all indexed as "../../release/index.html", etc. This is why it affects the final path.

[yoxallj]

Thanks for the response. I have solved the problem for now by creating a modified version of search.php that manipulates the url, but would still prefer a more elegant solution. I guess if I'm first person to ask for it, then it's not likely to make it far up the enhancement priority list

The reason for the relative paths is this (maybe there is another way of achieving it?):

- Multiple users can can build the site, including indexing, on their local machine
- If absolute paths are used, each user may have different paths, so needs a personal config file
- If a change is to be made to the search settings then you can't just change a single common config file, because every user has their own.

Using relative paths solves all of this at a stroke. And it so almost works, even if unintentionally.

To clarify, I am not creating the config file on the fly. I suppose I could, as another way to solve the problem - although then users who want to change the settings would have to open the separate

master

config.