You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Explanation of the use on netlify over GitHub pages
We moved to netlify because it allows to do custom redirects, with a custom name (e.g. not ending with a file extension .json or .html, as required by our specs, but most importantly because it correctly sets the Content-Type in the HTTP headers.
Reason of this issue
We would prefer not to rely on yet another service (netlify) and just use GitHub pages.
However, this issue is on hold because at the moment Content-Type cannot be set on GitHub pages. See e.g. here where it says
While you can't specify custom MIME types on a per-file or per-repository basis, you can add or modify MIME types for use on GitHub Pages.
(we would need a per-file specification, since we do not want the .json extension).
Suggested action for this issue
if this feature is not yet supported by GitHub in one year (say by June 1, 2021), we add the wontfix label to this issue, and we close it. We can always reopen it.
Comments in case we can do the switch
To make redirects work, netlify uses a _redirects file in the root directory.
Before, a practical solution to use this repository in GitHub Pages (if we ignored the Content-Type) was to create symlinks, possibly with .html extension, to the correct JSON files. E.g. we had:
providers.json -> src/links/v1/providers.json
v1/info.html -> ../src/info/v1/info.json
v1/links.html -> ../src/info/v1/links.json
These are removed in #34.
Note that we will have also to create additional symlinks for all new redirects that will be in the _redirects file by the time this issue can be solved. In particular, at the time of writing, the redirects to the statically-served Index Meta-Databases.
The text was updated successfully, but these errors were encountered:
I'm not sure we actually want to switch back from netlify even if it becomes possible, because some of the features relating to previews etc., are actually quite useful. I'm actually thinking we may instead want to move also the main OPTIMADE website to netlify, because the limitations of github pages makes it a bit difficult to handle collaborative edits.
Nevertheless, I still think we should modify the repository to also be github pages compatible if this is possible. Because people cloning the repository to host their own index-medadb may prefer to do so over github pages.
Explanation of the use on netlify over GitHub pages
We moved to netlify because it allows to do custom redirects, with a custom name (e.g. not ending with a file extension .json or .html, as required by our specs, but most importantly because it correctly sets the
Content-Type
in the HTTP headers.Reason of this issue
We would prefer not to rely on yet another service (netlify) and just use GitHub pages.
However, this issue is on hold because at the moment Content-Type cannot be set on GitHub pages. See e.g. here where it says
(we would need a per-file specification, since we do not want the .json extension).
Suggested action for this issue
if this feature is not yet supported by GitHub in one year (say by June 1, 2021), we add the
wontfix
label to this issue, and we close it. We can always reopen it.Comments in case we can do the switch
To make redirects work, netlify uses a
_redirects
file in the root directory.Before, a practical solution to use this repository in GitHub Pages (if we ignored the Content-Type) was to create symlinks, possibly with
.html
extension, to the correct JSON files. E.g. we had:providers.json -> src/links/v1/providers.json
v1/info.html -> ../src/info/v1/info.json
v1/links.html -> ../src/info/v1/links.json
These are removed in #34.
Note that we will have also to create additional symlinks for all new redirects that will be in the
_redirects
file by the time this issue can be solved. In particular, at the time of writing, the redirects to the statically-served Index Meta-Databases.The text was updated successfully, but these errors were encountered: