Open emiliom opened 3 months ago
Name | Link |
---|---|
Latest commit | 696e99f7b2969149318841b127b3874ba82ac23e |
Latest deploy log | https://app.netlify.com/sites/oceanhackweek-preview/deploys/66578148e357650008123420 |
Deploy Preview | https://deploy-preview-315--oceanhackweek-preview.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
It looks like we may want to put the built files into _static
rather than extra and then use {external}
on links to tell Sphinx to not interpret them, but to still keep them as relative links. By using absolute external links we loose the ability to see PR previews (which aren't mission critical for older pages).
Thanks for that suggestion. I'll test it out and update this PR if it looks promising.
I placed the ohw19
directory within _static
. In conf.py
, we already had html_static_path = ['_static']
and the extension attrs_inline
needs to be added to myst_enable_extensions
](https://myst-parser.readthedocs.io/en/latest/syntax/cross-referencing.html#customising-external-url-resolution).
It didn't work. It looks like myst-nb
vers. 0.19 is required, but the version that was used in a conda env (still Py38) I created last week was 0.17.2. During build (make live
), this error was emitted at the outset:
ERROR: myst configuration invalid: 'enable_extensions' items not recognised: {'attrs_inline'}
Without adding attrs_inline
to myst_enable_extensions
, the relative links were use correctly, but the {.external}
part was just ignored and passed through as a string. Also, the HTML link was interpreted as a "download" link.
I assume myst-nb
vers. 0.19 is not available for Py38, but haven't checked. I suppose I could build a conda env with a recent Python (say, 3.11) and see whether that results in myst-nb
>= 0.19 and the feature working as expected ...
Using a fresh conda env with Py311, a recent myst-nb
version was installed and {.external}
was interpreted as expected. Links were created correctly. But, the old, Jekyll-based pages were rendered essentially as plain HTML without any styles. Between that and the string token _static
being a part of url's, I think it's best to fall back to html_extra_path
and just use absolute url's. After all, we're currently using absolute url's for these old pages, anyways! Besides, the old pages will be "rendered" (passed through) as expected, so they can will still be visible locally with make live
and on the previews; it's just the links from the "Past OHW Events" page that will be absolute. We can live with that.
I've pushed the setup I described in my previous comment. The ohw19
pages work as expected.
Let's not merge this just yet, though. I'd like to focus my OHW time right now on getting OHW24 content off the ground. Also, it'll probably be more efficient to bring in the old ohw20 & ohw21 pages into this PR too. ohw18 is best handled in a separate PR, b/c the files reside in a different repo (see #316).
... for inclusion as-is in a new set of built pages. See #314.
This PR is not intended to be merged. I'm creating it to continue the discussion in #314, to share the outcome of the current changes.
As mentioned there, the ohw19 index page is overwriting the main site index page.Update 1: I don't know what I did, but the index-page overwrite is no longer a problem! I've now updated the links to ohw19 pages in the Past OHW Events page, but the ohw19 links are not built. Here's one of the warnings:
This has to do with files in
html_extra_path
being handled differently. Apparently links are not generated as expected -- see here. But I haven't found a solution. Note that I tried both/ohw19/
and../ohw19/
, but it made no difference.Update 2: A simple solution to the link generation problem would be to use "external", absolute url's (eg, https://oceanhackweek.org/ohw19/index.html) instead of relative url's. It makes local debugging harder, but it's very easy.