The new release breaks our build process. No useful warning/error is generated:
Using v0.31.1:
malaga% hugo -v
INFO 2018/01/04 11:09:54 Using config file: /Users/synadia/go/src/github.com/nats-io/nats-site/config.toml
INFO 2018/01/04 11:09:54 syncing static files to /Users/synadia/go/src/github.com/nats-io/nats-site/public/
WARN 2018/01/04 11:09:54 No translation bundle found for default language "en"
WARN 2018/01/04 11:09:54 Translation func for language en not found, use default.
WARN 2018/01/04 11:09:54 i18n not initialized, check that you have language file (in i18n) that matches the site language or the default language.
Started building sites …
INFO 2018/01/04 11:09:54 found taxonomies: map[string]string{“tag”:“tags”, “category”:“categories”}
INFO 2018/01/04 11:09:54 Alias “/blog/page/1/index.html” translated to "blog/page/1/index.html"
WARN 2018/01/04 11:09:54 [en] Unable to locate layout for “404”: [404.html]
Built site for language en:
0 draft content
0 future content
0 expired content
140 regular pages created
168 other pages created
5 non-page files copied
6 paginator pages created
4 categories created
74 tags created
total in 192 ms
Using the new release v0.32.2:
malaga% hugo -v
INFO 2018/01/04 11:10:34 Using config file: /Users/synadia/go/src/github.com/nats-io/nats-site/config.toml
Building sites … INFO 2018/01/04 11:10:34 syncing static files to /Users/synadia/go/src/github.com/nats-io/nats-site/public/en
WARN 2018/01/04 11:10:34 No translation bundle found for default language "en"
WARN 2018/01/04 11:10:34 Translation func for language en not found, use default.
WARN 2018/01/04 11:10:34 i18n not initialized, check that you have language file (in i18n) that matches the site language or the default language.
INFO 2018/01/04 11:10:34 found taxonomies: map[string]string{“tag”:“tags”, “category”:“categories”}
WARN 2018/01/04 11:10:35 [en] Unable to locate layout for “404”: [404.html]
Yes your site fails to render spectacularly with hugo server. If I run hugo then the public folder is populated with content but the CSS is missing.
But it seems that you have a fancy setup with a non standard /src/ folder where users post assets that are then resized and moved in different directories with Gulp.
At first glance your templates seem ok and I haven’t looked very deep. It is quite hard to say what’s wrong with a non standard set up like yours.
If I were you I would either keep using the 031.1 version or overhaul that Hugo project by eliminating the use of /src/ and Gulp and making use of the new .Resources that were introduced in Hugo 0.32. But then again you might not want to do that.
Maybe someone else can look into your repo and offer you better advice than me.
I didn’t work on the site’s coding. But from what I can tell, the gulp tasks are simply compiling .less, minifying the javascript, and copying images from their locations to the static assets directory. Hugo is then invoked. So I wouldn’t think that would be the reason. Just to do a test, I will comment out all the tasks (since after they run the static directory will have all the assets).
When I looked at your repo I remember seeing several regex filters in your JS. Do you rewrite the URLs of assets in a way that could potentially conflict with Hugo 0.32?
Your pages are generated when published but not rendered with Hugo server. There is something weird with the way assets are handled.
Or have you created some variable that conflicts with the new ones introduced with Hugo 0.32?
It’s tough to know what’s going on. And I cannot debug this for you. It’s beyond my skills.
Hi @aricart - I confirm that the only thing rendered by hugo server is a <pre></pre> tag.
If the repo is correct your index file is not set up in the modern Hugo way, but rather in a way that used to work but does not any longer. I think it needs a “baseof” template in _default.
I’m not yet 100% versed with this style but, this is what I have working:
I had large sections of my site fail to render after updating to v32.2. For example, this entire section of my site with 14 pages only rendered the index page after the upgrade. I reverted back to v31.1 as I had some major content releases scheduled for this week.
I have a similar setup to @aricart where I introduced a build system to minify images and scripts to build a production ready site. I also use both an site/layouts/index.ace and site/content/_index.html to render my homepage.
My entire repo is online, but it’s HUGE as I store my site assets in git. Let me know if I can help track down the source of the bug.
Yes. That happened because you are using index.md for your section and Hugo 0.32 converts your section into a leaf bundle. You should use _index.md for your section list pages (or as Bjørn-Erik calls them branch bundles) and index.md for your single page (leaf) bundles. Try that and tell us if your section rendered like it used to.
The original poster has no index.md or _index.md in his sections. Something else is causing his problem.
False alarm. While all of the non-index pages are being rendered, the section index is not. Does this have something to do with section layouts? In the past I believe my index.md content files were using the single.ace layout.
I started trying to update a site that I last built with 0.17, and, when I run hugo server on it as usual, I get the same <pre></pre> that I observed when I compiled @aricart 's site, in my site’s source. I’ll start working through the errors in stdout.
