Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fetch for json needs to respect rootURL #13

Open
gokatz opened this issue May 5, 2020 · 1 comment
Open

fetch for json needs to respect rootURL #13

gokatz opened this issue May 5, 2020 · 1 comment

Comments

@gokatz
Copy link

gokatz commented May 5, 2020

I've changed the rootURL property of config as I'm deploying my docs under some nested directory of the server. Since field-guide generates various json file configs for the docs, we may need to respect the rootURL config while fetching these JSONs. Otherwise, the field-guide will try to fetch these JSONs from the root of the server which leads to 404

@gokatz gokatz changed the title fetch for toc.json needs to respect rootURL fetch for json needs to respect rootURL May 5, 2020
@mansona
Copy link
Member

mansona commented May 6, 2020

We've chatted about this in Discord but I'm going to put a summary of our discussion here for others to see 👍

Right now most Empress projects don't support being deployed in a sub-folder, for exactly the reason that you're seeing. Sure you can change the rootURL and move the Ember files and the Ember app will work, but Empress also creates a static API of JSON files that do not adhere to the rootURL config.

Some deep thought needs to go into this to make sure that it covers all of the expected use cases. We need to come up with some scenarios (like deploying to github pages that requires a subfolder, or a lightning deployment strategy that has static files on a different host to the index.html using prefix) and make sure that we solve this problem in a general enough way that all Empress projects can share the solution 👍

It's a complex problem but if we keep the goal of the feature in mind I am confident that we can come up with a reasonably straight-forward solution that is flexible enough to cover every use case (possibly with a bit of extra config)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants