CSS styling and Js scripts are not working after deploy

[spacedrone808]

I suspect that this is something with relative or absolute paths here…

Repo
Website

config.toml

#LAST MODIFICATION DATE: 2024/12/04

languageCode = "en"
title = "Hugo Hacker Theme"
theme = "mainroad"
paginate = 14
BaseURL = "https://spacedrone404.github.io/hugo-hacker-testbed-template"
DefaultContentLanguage = "en"
disableHugoGeneratorInject = true


[markup]
  [markup.goldmark]
    [markup.goldmark.renderer]
      unsafe = true  # Enable html code inside markdown files

[module]
  [module.hugoVersion]
    extended = true
    min = "0.121.0"

hugo.yaml

# Sample workflow for building and deploying a Hugo site to GitHub Pages
name: Deploy Hugo site to Pages

on:
  # Runs on pushes targeting the default branch
  push:
    branches:
      - main

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

# Default to bash
defaults:
  run:
    shell: bash

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    env:
      HUGO_VERSION: 0.121.2
      extended: true
    steps:
      - name: Install Hugo CLI
        run: |
          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
          && sudo dpkg -i ${{ runner.temp }}/hugo.deb          
      - name: Install Dart Sass
        run: sudo snap install dart-sass
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: recursive
          fetch-depth: 0
      - name: Setup Pages
        id: pages
        uses: actions/configure-pages@v5
      - name: Install Node.js dependencies
        run: "[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true"
      - name: Build with Hugo
        env:
          HUGO_CACHEDIR: ${{ runner.temp }}/hugo_cache
          HUGO_ENVIRONMENT: production
          TZ: America/Los_Angeles
        run: |
          hugo \
            --gc \
            --minify \
            --baseURL "${{ steps.pages.outputs.base_url }}/"          
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./public

  # Deployment job
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

Local Hugo server and VSCode live server are showing site like it should to look.
Guys, any tips on what i am doing wrong?

[jmooring]

In these files:

themes/mainroad/layouts/_default/list.html
themes/mainroad/layouts/_default/single.html
themes/mainroad/layouts/index.html

Replace this:

<script type="module" src="/js/lazy-load.js"></script>

With this:

<script type="module" src="{{ `js/lazy-load.js` | relLangURL }}"></script>

Use the relLangURL function in a similar way to address the other 404 errors in the console of your browser’s dev tools:

Other notes:

1. In the future, don’t modify a third-party theme. Instead, override the files as needed by copying the desired file to the same path relative to the layouts directory in the root of your project.

2. Don’t put the public directory under source control. I recommend:

   touch .gitignore
   

   Then add the following to the file you just created:

   .hugo_build.lock
   node_modules/
   public/
   resources/
   

   Then cleanup your repository:

   git rm -rf public
   git rm -rf resources
   git rm .hugo_build.lock
   git add -A
   git commit -m "Cleanup repository"
   

3. Fix all of the URLs in your content files. The src attributes for your HTML img elements ignore the fact that you are serving your site from a subdirectory.

[chrillek]

What makes you think that your CSS doesn’t get loaded?

The only errors my browser complains about are misconfigured fonts:

Your CSS loads just fine:

But you might want to fix the font references to use
../fonts/FiraSans-Regular (i.e. one directory up, then down to fonts)
These references are always relative to the location of your CSS file, which is
loaded with
<link rel="stylesheet" href="/hugo-hacker-testbed-template/css/style.css">

The only JS file that doesn’t get loaded is js/lazy-load.js, and I doubt that you even need that. Why not set the lazy attributes on your images instead? The JS code fiddles around with class names that are never used in your style.css, so the whole thing is not doing anything at all anyway.

And that’s not the only thing that doesn’t do anything: You’re somehow configuring/installing dartsass, but there’s no SASS file in your repo. You have jquery in your repo (why?) but don’t load it.

[spacedrone808]

@jmooring & @chrillek this was a good lesson for sure!

Thank you for your experience sharing.

@chrillek I am lazy loading not just images but the whole blocks.
You can see it in fixed site

As for fonts, path was not correct, i’ve fixed it.
I think that Jquery is used in photo-gallery and i already have another question regarding it:)

[chrillek]

I suggest you take a look at the results of Lighthouse in Chrome.

That image shows Lighthouse for desktop. It fails utterly with Mobile.

@spacedrone808

I am lazy loading not just images but the whole blocks.

You’re over-engineering it. For example,

<div class="container header__container lazy loaded">…</div>

is one of these lazy loaded blocks. In your JS code, you then do that

let img = entry.target;
img.src = img.dataset.src;

where entry.target is that div. And then you set a src attribute on that div, which is non-sensical, because a div doesn’t have that attribute. But neither does this div have a data-src attribute, from which you could set this img.src value.

I guess you grabbed this “lazy loading block” stuff somewhere (or was it ChatGPT?). It runs on over 60 DOM elements, of which only very few have a src attribute to set. And there’s load="lazy" anyway for these cases.

Carga diferida de imágenes a nivel del navegador para la Web  | ...

And interestingly, all your images get loaded with the rest of the HTML anyway (take a look at your browser developer tool’s network tab). Not astonishing, given that no single img has class lazy.

Using properly scaled (responsive!) WebP images would probably result in more performance gains.