Differing "Pages" between dev and production

support
1

I have a weird thing going on between my local hugo server and the live site on Netlify. Going to https://samui-samui.de you will see a box on the right side with years of posts. That box (“Archives”) has 2020 to 2005 and the year 0001 (which ends up in a 404 situation). Running hugo server locally it will show only 2020 to 2005.

The theme used is at https://github.com/davidsneighbour/dnb-hugo-garuda and the template in question is probably widget-archive.html:

What would make this difference come up between dev/live?

I set my site repo to public for now if anyone would like to debug it deeper:

2

Yep, strange.
Do you have same Hugo version in dev and in your netlify.toml ??

[context.production.environment]
HUGO_VERSION = "0.74.3"

[EDIT] Oops. Didn’t see you have repo available.

Can you try removing the [context.production] line ?

Just keep [context.production.environment]

3

And keep all other lines? Like

[context.production]
  TZ = "Asia/Bangkok"
  HUGO_VERSION = "0.75.1"
  HUGO_ENV = "production"
  HUGO_ENABLEGITINFO = "true"
4

I pushed it to Github… let’s wait and see :slight_smile: My deploys on Netlify take lot’s of time these days…

5

No, something like

[build.environment]
  PHP_VERSION="7.2"

 [context.production.environment]
    TZ = "Asia/Bangkok"
    HUGO_VERSION = "0.75.1"
    HUGO_ENV = "production"
    HUGO_ENABLEGITINFO = "true"

# https://www.netlify.com/docs/netlify-toml-reference/#post-processing
[build.processing]
  skip_processing = true

This is my rock solid for years netlify.conf

[build]
publish = "public"
command = "hugo --minify"
functions = "functions"

[context.production.environment]
HUGO_VERSION = "0.74.3"
HUGO_ENV = "production"
RUBY_VERSION = "2.6.2"
HUGO_ENABLEGITINFO = "true"
TZ = "Europe/Zurich"
# pour "postcss-cli": "^7.1.1"
NODE_VERSION = "12.2.0"

[context.deploy-preview]
command = "hugo --buildFuture -b $DEPLOY_PRIME_URL"

[context.deploy-preview.environment]
HUGO_VERSION = "0.74.3"
RUBY_VERSION = "2.6.2"
HUGO_ENABLEGITINFO = "true"
TZ = "Europe/Zurich"

[context.branch-deploy]
command = "hugo -b $DEPLOY_PRIME_URL"

[context.branch-deploy.environment]
HUGO_VERSION = "0.74.3"
RUBY_VERSION = "2.6.2"
HUGO_ENABLEGITINFO = "true"
TZ = "Europe/Zurich"

[[headers]]
  for = "/images/*"
  [headers.values]
    Cache-Control = "public, max-age=604800, s-maxage=604800"
[[headers]]
  for = "/*.jpg"
  [headers.values]
    Cache-Control = "public, max-age=604800, s-maxage=604800"
[[headers]]
  for = "/*.png"
  [headers.values]
    Cache-Control = "public, max-age=604800, s-maxage=604800"
[[headers]]
  for = "/*.gif"
  [headers.values]
    Cache-Control = "public, max-age=604800, s-maxage=604800"
[[headers]]
  for = "/*.css"
  [headers.values]
    Cache-Control = "public, max-age=604800, s-maxage=604800"
[[headers]]
  for = "/*.js"
  [headers.values]
    Cache-Control = "public, max-age=604800, s-maxage=604800"
[[headers]]
  for = "/fonts/*"
  [headers.values]
    Cache-Control = "public, max-age=604800, s-maxage=604800"
6

Oh wait… the other way around :wink: It’s late :wink:

7

Hmm. No, same result. I wonder if it’s possible to somehow debug what the partial thinks it has inside of this item.

8

And may be as you have url in front matter, one post with a bad date => 0001, but “correct” url.
But it would fail in both case.

9

Yes, I was replying this : print the context and some variables while in your partial. Then search generated source code and you’ll get the origing of this 0001.

Do it locally and from netlify

poor man’s debug but efficient

10

But shouldn’t that show up locally too? I did a search for 0001 and it turned up nothing. I’ll try a branch deploy on netlify with @kaushalmodi’s debugprint. (GitHub - kaushalmodi/hugo-debugprint: Hugo "debugprint.html" partial)

11

Yes. Should be.
This is the fun part :slight_smile:

12

content/posts/2019/_index.md does not have a date, so its “date” value will be determined by:
https://gohugo.io/getting-started/configuration/#configure-dates

What happens if you remove this file, or restrict your range to .Site.RegularPages?

2 Likes
13

Minimal example:

git clone --single-branch -b hugo-forum-topic-28270 https://github.com/jmooring/hugo-testing hugo-forum-topic-28270
cd hugo-forum-topic-28270
hugo server
14

Ah, you are right. That file is not supposed to be there. I removed it and the stray year 0001 A.D. is gone. Thanks :slight_smile:

15

Cool. but why it doesn’t happen locally if you have same hugo version and same command line parameters, remains ze question.

16

that’s some next level Sherlock Holmesing you did there @jmooring! :astonished:

17

Yes, that’s very weird. There must be a difference how Hugo calculates .Site.Pages in dev and production mode

18

mmmmm I guess that’s not possible if same hugo, same command line (minimal option --gc --cleanDestinationDir).

There is something different.

19

Only difference I see is this if your netlify test is not in prod but a branch. Try skip_processing = true on branch and see if this happens. But not really a hugo pb.

I (finally) tested locally myself and there is not 0001 atifact either (0.74.3).

[build.processing]
  skip_processing = true

[context.branch-name.processing]
  skip_processing = false
[context.branch-name.processing.css]
  bundle = true
  minify = true
20

config.toml

enableGitInfo = false

netlify.toml

HUGO_ENABLEGITINFO = "true"

The environment variable takes precedence over the configuration parameter.

Another difference is the number of CPU’s available during the build. I’m pretty sure there’s a bug here somewhere, but I can’t put my finger on it yet…