search

oceanhackweek / oceanhackweek.github.io

GitHub repo for the OceanHackweek website
https://oceanhackweek.org/
12 stars 39 forks source link

TEST: Add ohw19 built files from master to source #315

Open emiliom opened 3 months ago

emiliom commented 3 months ago

... 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:

oceanhackweek.github.io/about/pasthackweeks.md:56: WARNING: 'myst' reference target not found: /ohw19/projects_2019.html

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.

netlify[bot] commented 3 months ago

Deploy Preview for oceanhackweek-preview ready!

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...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

abkfenris commented 3 months ago

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).

emiliom commented 3 months ago

Thanks for that suggestion. I'll test it out and update this PR if it looks promising.

emiliom commented 3 months ago

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 ...

emiliom commented 3 months ago

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.

emiliom commented 3 months ago

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).