Add abs paths to site yml - #315
Conversation
✅ Deploy Preview for ucospo-net ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
…l as a relative path
692d4f9 to
a761dee
Compare
|
(FYI that force push was just me re-naming the commit to something more informative.) |
|
Aside from the tiny typo edit that I proposed above, this seems good to me! I don't love the quirk with the footer links in local previews, but that's not a big thing as long as we remember that it's a thing at all (maybe add it to the docs?), so I think this approach is better than duplicating everything. I'm going to tag in @jarrodmillman to give final approval, though, since this approach is new to me. |
|
I'll add that another major "con" is that if someone wants to edit the core site assets, such as the favicon, logo, socials, or they want to edit the footer's "ABOUT" button to say "ABOUT US", for example, they will need to remember that the hard-coded URLs point to the main branch. So they might make a change and then be confused as to why it's not updating--it's because they made changes on a feature branch, but the URLs point to main. |
|
What is the reason that the playbook is a separate repo? My sense is that it adds extra complexity for something that may end up being maintained by volunteers. |
|
@stefanv Do you have any thoughts about this? |
|
My general approach to these things is: do not generalize unless you absolutely need to. It sounds like you want to build two websites using one configuration, but it comes with some obvious downsides—like not being able to adjust the CSS and try it out, not being able to click on footers in the preview, several remote fetches occurring during build, etc. So, on this repo (which contain your reference source files) I would probably leave it as is, and then you can go to some effort on the child site to reference the original. There are several ways to do this, e.g.: the cookie-cutter approach we follow with Scientific Python Myst theme (although really only necessary if you're going to do many websites that look the same), or simply having a Regardless, I'd start with duplication, see what happens—and if you're lucky avoid the complexity of extended configurations. Could be that you never need to update anything again :) |
|
Thanks for weighing in @jarrodmillman and @stefanv! As to Jarrod's question, the impetus for using a separate repo is (1) simple separation of concerns, and (2), because if the playbook were just a series of pages within the site, the parent ucospo.net webpages would be cluttering up both the table of contents and the PDF export for playbook readers. I really like Stefan's Closing this PR as I am happy with this solution. |
4 participants
I'm, like, pretty sure this PR won't break the website.
I've swapped the relative paths in site.yml and footer.md for absolute paths. This allows the playbook repo (and perhaps, someday, other subprojects) that are inheriting stuff through MyST's "extends" functionality to find the assets mentioned in those files.
The only path I kept as a relative path is footer.md. I'll change that later, in a separate PR, for convoluted reasons. (Basically, because the absolute path contains the branch name, if I put main/footer.md in this PR, we won't actually get to see whether my modified footer file works because it will be pointing to the one that's currently live, not the one here.)
This is all copied from the workflow described in the JupyterBook blog here. I'm basing this new site.yml file on the site.yml file from their "core repo" (the one subprojects inherit from).
I added the "internal_domains" key (like they did) to indicate that links from ucospo.net should be treated as internal, and should not open a new tab or have this little symbol next to them:
Without this, both the playbook and the core site will treat the "ABOUT", "EVENTS", "BLOG", etc. links in the footer as external links.
The pro of this is, as I said earlier, it allows for inheritance. The major con is that if you are a developer deploying a local preview, you might be surprised to find that if you click, e.g., "EVENTS" in the footer, you'll find yourself on ucospo.net/events instead of localhost:nnnn/events. JupyterBook also has this problem and as far as I can tell they just live with it.
Please double-check that I am not breaking the website. Try clicking all the stuff in the footer, especially the RSS feed link. It looks okay to me but I have no idea how that works.
Also let me know if you hate this, lol. To me, it seems more elegant than maintaining duplicate code and images in two repos, but I can see the case for ditching this inheritance thing, since it is a little more complicated.