PDF and EPUB links in dev build point to main site instead of dev version #451

New Issue

GiteaMirror · 2026-03-22T15:40:41-05:00

GiteaMirror commented

2026-03-22 15:40:41 -05:00

Originally created by @profvjreddi on GitHub (Nov 1, 2025).

Originally assigned to: @profvjreddi on GitHub.

I realized that when the dev build is built, the links for the PDF and EPUB are actually pointing to the main site and not the dev version. This could lead to mistaken assumptions that everything is working correctly on the dev build, when in fact the links are not valid for the development environment.

Dev

Steps to reproduce:

Build the dev version of the site.
Check the links for PDF and EPUB.
Notice that they point to the main site, not the dev build output.

Expected behavior:
Links in the dev build should point to the dev version of the PDF and EPUB, not the main site.

Impact:
This makes it easy to miss issues with the dev build's PDF/EPUB output.

Suggested fix:
Update the build logic so that links in the dev environment point to dev artifacts.

Originally created by @profvjreddi on GitHub (Nov 1, 2025). Originally assigned to: @profvjreddi on GitHub. I realized that when the dev build is built, the links for the PDF and EPUB are actually pointing to the main site and not the dev version. This could lead to mistaken assumptions that everything is working correctly on the dev build, when in fact the links are not valid for the development environment. [Dev](https://harvard-edge.github.io/cs249r_book_dev/) Steps to reproduce: 1. Build the dev version of the site. 2. Check the links for PDF and EPUB. 3. Notice that they point to the main site, not the dev build output. Expected behavior: Links in the dev build should point to the dev version of the PDF and EPUB, not the main site. Impact: This makes it easy to miss issues with the dev build's PDF/EPUB output. Suggested fix: Update the build logic so that links in the dev environment point to dev artifacts.

GiteaMirror added the type: bug format: pdf area: tools labels 2026-03-22 15:40:41 -05:00

GiteaMirror commented

2026-03-22 15:40:43 -05:00

@siddu1324 commented on GitHub (Nov 3, 2025):

Hi @profvjreddi 👋

I went through all three Quarto configuration files (_quarto-html.yml, _quarto-epub.yml, and _quarto-pdf.yml), and I didn’t find a site-url key being defined anywhere. Instead, the links in the HTML navbar are hardcoded to production URLs — for example:

- icon: file-pdf
  text: "PDF"
  href: https://mlsysbook.ai/pdf
  target: _blank
- icon: book
  text: "EPUB"
  href: https://mlsysbook.ai/epub
  target: _blank

This means the dev and preview builds always point to mlsysbook.ai, regardless of environment.

To fix this, I can:

Introduce an environment variable (like SITE_URL or BASE_URL) in the Makefile or CI workflow,
Reference it in _quarto-html.yml dynamically (via templating or a small pre-build script),
So that local previews link to relative paths (/pdf, /epub) and production builds use the public URLs.

Would it be okay if I implement that and open a PR for review?

@siddu1324 commented on GitHub (Nov 3, 2025): Hi @profvjreddi 👋 I went through all three Quarto configuration files (_quarto-html.yml, _quarto-epub.yml, and _quarto-pdf.yml), and I didn’t find a site-url key being defined anywhere. Instead, the links in the HTML navbar are hardcoded to production URLs — for example: ``` - icon: file-pdf text: "PDF" href: https://mlsysbook.ai/pdf target: _blank - icon: book text: "EPUB" href: https://mlsysbook.ai/epub target: _blank ``` This means the dev and preview builds always point to mlsysbook.ai, regardless of environment. To fix this, I can: - Introduce an environment variable (like SITE_URL or BASE_URL) in the Makefile or CI workflow, - Reference it in _quarto-html.yml dynamically (via templating or a small pre-build script), - So that local previews link to relative paths (/pdf, /epub) and production builds use the public URLs. Would it be okay if I implement that and open a PR for review?

GiteaMirror commented

2026-03-22 15:40:44 -05:00

@profvjreddi commented on GitHub (Nov 4, 2025):

Hi @siddu1324, that would be great! However, the issue goes beyond just fixing the relative paths, which I agree we need to do. We also need to update the validate-dev GitHub workflow to properly package the build artifacts, and then the deploy preview workflow must take those artifacts and push them up. That's the real challenge.

If you examine the GitHub workflows I have set up, you'll see that they are quite complex. 😓 Once I get that working, it will definitely be helpful. I was planning to do this over the Christmas break because most people don't typically look at the dev branch outside of me.

Feel free to take a look and see if you think you can handle it, but don’t worry if it seems too messy; I know it can be difficult to understand what I've got going on.

@profvjreddi commented on GitHub (Nov 4, 2025): Hi @siddu1324, that would be great! However, the issue goes beyond just fixing the relative paths, which I agree we need to do. We also need to update the validate-dev GitHub workflow to properly package the build artifacts, and then the deploy preview workflow must take those artifacts and push them up. That's the real challenge. If you examine the GitHub workflows I have set up, you'll see that they are quite complex. 😓 Once I get that working, it will definitely be helpful. I was planning to do this over the Christmas break because most people don't typically look at the `dev` branch outside of me. Feel free to take a look and see if you think you can handle it, but don’t worry if it seems too messy; I know it can be difficult to understand what I've got going on.

GiteaMirror commented

2026-03-22 15:40:44 -05:00

@siddu1324 commented on GitHub (Nov 4, 2025):

Got it, thanks for the context @profvjreddi ! That makes total sense, I had a feeling the workflows might be the tricky part 😅

Sure, Prof! I’ll start by looking into the CI/CD setup and see how the validate-dev and deploy preview workflows are structured. I’ll also try tackling the path logic first to get that part working cleanly, and then I’ll let you know if I feel comfortable handling the rest.

Appreciate the heads-up — I’ll take a look and keep you posted!

@siddu1324 commented on GitHub (Nov 4, 2025): Got it, thanks for the context @profvjreddi ! That makes total sense, I had a feeling the workflows might be the tricky part 😅 Sure, Prof! I’ll start by looking into the CI/CD setup and see how the validate-dev and deploy preview workflows are structured. I’ll also try tackling the path logic first to get that part working cleanly, and then I’ll let you know if I feel comfortable handling the rest. Appreciate the heads-up — I’ll take a look and keep you posted!

GiteaMirror commented

2026-03-22 15:40:45 -05:00

@profvjreddi commented on GitHub (Nov 5, 2025):

Thanks a bunch @siddu1324 🙏

@profvjreddi commented on GitHub (Nov 5, 2025): Thanks a bunch @siddu1324 🙏

GiteaMirror commented

2026-03-22 15:40:45 -05:00

@profvjreddi commented on GitHub (Nov 6, 2025):

@siddu1324 I fixed it. Could you please take a look, just so that I have a different set of eyes on it?

@profvjreddi commented on GitHub (Nov 6, 2025): @siddu1324 I fixed it. Could you please take a look, just so that I have a different set of eyes on it?

GiteaMirror referenced this issue

2026-03-22 15:49:57 -05:00

[PR #451] [MERGED] Proofreading the sustainability section - fixing typos #747

GiteaMirror referenced this issue

2026-04-11 08:12:48 -05:00

[PR #451] [MERGED] Proofreading the sustainability section - fixing typos #1970

GiteaMirror referenced this issue

2026-04-13 13:13:11 -05:00

[PR #451] [MERGED] Proofreading the sustainability section - fixing typos #2692

GiteaMirror referenced this issue

2026-04-16 01:46:23 -05:00

[PR #451] [MERGED] Proofreading the sustainability section - fixing typos #3371