Improve Static Site Deployment to also work with file:/// based URLs

[rolandh15]

In my company we wish to use Orchid Netify as a static site generator, to generate html documents which are shipped alongside a library (C Library) in an additional docs folder. The user should be able to open the index.html from the browser.

Currently, if you examine the OrchidStarter project you can configure the baseURL as an orchid setting.

It seems there is no way to define the base URL such that the site can be deployed to work based on a file:/// base URL from the current directory.

Even if the baseURL is specified as".", this only solves the issue for the index page, all other subpages cease to function correctly.

This makes the project only work locally if you choose to run OrchidServe, which would require bundling additional things with the documentation.

It would be awesome if someone could provide a way to enable this.

Many thanks

[cjbrooks12]

The problem with file:///... as the base URL is that it would need to be an absolute file path (which would only work for something like a shared network drive), or else the generated URLs would all have to be relative, not absolute as they are now. It's the same kind of problem that is discussed in this thread in Hugo.

The first way would be easy enough to support if that's what you're looking for, but it will be pretty difficult to have Orchid generate relative URLs rather than absolute, and I'm not sure if it's even possible without significant changes to core parts of its architecture.

That said, since Orchid generates static files you don't need Orchid itself to run the local server. You can use any simple HTTP server to serve it locally, such as the Python SimpleHTTPServer or the Node http-server.

Alternatively, someone in that Hugo thread also linked a script that would "post-process" the site and convert all absolute URLs into relative ones, which would allow it to be viewed simply by opening the file in a browser. You could give that script a try, and if it works, run it as part of the deploy process, or write your own script the do that post-processing.

[rolandh15]

Thanks for the tip @cjbrooks12 I understand the problem of changing the core underlying server.

Unfortunately we strictly dont want to bundle a server. Before I close this issue, I will give the script a try and add the results here. I think that in any case the post processing would be something nice as an additional gradle task. If it all works out, I might submit a PR.

[rolandh15]

I will close this issue. i understand your reasoning completely. I assume that the final site is generated with Hugo which is why said script might work. Until they find a solution in that project for postprocessing that does not use VB we will have to use asciidoctor for now, which is a pity since Orchid does everything we need and would allow us to link documentation and javadoc very nicely.

[cjbrooks12]

Orchid isn't running Hugo under-the-hood, it is fully its own thing, but the outputs of both are basically the same (a bunch of HTML and other assets), so the post-processing would work the same on either site.

I've been thinking about how to implement relative URLs in the core architecture for a long time, but hadn't seriously considered a post-processing step to do it instead. I can certainly work toward adding this into Orchid so you wouldn't have to use a VB script (🤢), but it's not going to be ready for the next release (targeted at the end of this month). I'll post back here when I get that out, I hope you'll consider switching back to Orchid at that time!