Summary strange behavior

Hi, I’m using netlify to deploy my site. On a particular article, I use the frontmatter summary property to set the summary. Locally everything runs fine, but on netlify, the summary is blank.
Locally, if I rely on the automatic summary making, I also have a blank summary, because my article begins with an HTML iframe.

I suppose the behaviour on netlify is due to a hugo bug that is not visible on my laptop, maybe because there is less concurrent building on it?

Maybe I’m wrong, but your lights are welcome.
The website is here, it’s in french, you can see the first article in the blog with a blank summary.
The source of the problematic article is here

Oh and by the way, maybe the automatic summary should work even if the content file begins with an iframe (ignore the iframe and get the text after it)? Should I submit a bug?

Are you using the same hugo version on Netlify vs locally?

Yes, Hugo v.0.55.6 (the last one at the moment of writing)

@lamyseba,

Oh and by the way, maybe the automatic summary should work even if the content file begins with an iframe (ignore the iframe and get the text after it)? Should I submit a bug?

No I don’t think you should. I think much of what you discussed is well documented here

I red that documentation before posting, and checking things now that you point it, I realize that Hugo build a correct automatic-summary on my local server, even with an iframe at the beginning of the article.

Things happens when deploying on netlify and having an iframe at the beginning of the article. Neither automatic summary, nor frontmatter plain text summary works, and I stay with a blank summary on my production site. Using Hugo v. O.55.6 on both sides (locally, and on netlify)

Umh, I could have a look at the repo

Hmm. Try temporarily updating your netlify build command to:

rm -r public && hugo --gc

I know this (probably) won’t help, but I downloaded your repository (had to use the .zip option as git clone failed…that might be worth looking into). Building it on my Mac using Hugo 0.55.6 displays the summary (as you reported).

One thing I noticed is it took hugo ages to build the site the first time (21 secs). I deleted some of the unused themes and build time dropped to 2 secs.

Have you checked your netlify logs? Just wondering whether the site is failing to be rebuilt or deployed? Is there anything you can do to speed things up (delete some unused things, switch to git lfs for your assets)?

1 Like

Hi, thanks for all your replies
@Weru, my repo is public, it is here: https://github.com/pau-a-velo/pau-a-velo-websource. funkydan2 told he could only download the zip and git clone failed for him. Have no clue why this, except maybe french accents? Just checked my github repo and didn’t found any special option that could prevent git clone to work. I use this repo only with push as I am the only user.
@zwbetz , I tried your netlify build command, still a blank summary on netlify
@funkydan2, you lucky guy with a mac, on my windows surface3 it takes more than 2 minutes to build the first time. I was full of hope reading your message, but deleting unused themes didn’t improve this on my computer, time didn’t drop to 10s or so, still 2 minutes of waiting. I have a lot of images, and static files, and I think hugo could optimize this if there was an option not to update any static file that he already processed to the output directory (resized images especially), when using hugo server command. I posted something about this problem on this forum. Could you reply there what command you did to drop down build time, especially the command you used (hugo or hugo server ?)
Thanks a lot, and still hoping to find a way to display a correct summary on netlify

When I run git clone https://github.com/pau-a-velo/pau-a-velo-websource.git this is the output:

Cloning into 'pau-a-velo-websource'...
remote: Enumerating objects: 6145, done.
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Though if Netlify is building when you push changes, then that’s unlikely to be the issue.

On the zipped download, I ran simply ran hugo server from the command prompt and looked at the local site in Firefox.

@zwbetz, didn’t pay attention at first try, but your suggested netlify build command fails with this error message :

rm: cannot remove 'public': No such file or directory

Surely netlify does not deploy in a “public” subdirectory from where command is launched

summary: "Ce dimanche 16 juin, c'était la quatrième et dernière balade du cycle 'Révélation', en partenariat avec l'association Destination Patrimoine. Cette promenade nous a emmené le long de la rivière Ousse des Bois, et comme toute les sorties du cycle, elle nous a permis de découvrir notre agglomération par l'angle de l'urbanisme et du paysage."

I see a lot of special characters there. Maybe Netlify is misunderstanding the ' parts. Where is the template that displays/creates the summary?

Also would you mind to post the complete log from a Netlify deploy? Maybe that gives some hint on whats happening.

partial is here on github

My last netlify deploy

2:10:36 PM: Build ready to start
2:10:37 PM: build-image version: 9e0f207a27642d0115b1ca97cd5e8cebbe492f63
2:10:37 PM: build-image tag: v3.3.2
2:10:37 PM: buildbot version: ef8d0929ed0baabafd8bbb7d0b021e1fc24180c0
2:10:38 PM: Fetching cached dependencies
2:10:38 PM: Starting to download cache of 1.8GB
2:10:55 PM: Finished downloading cache in 16.880884499s
2:10:55 PM: Starting to extract cache
2:11:17 PM: Finished extracting cache in 22.417984071s
2:11:18 PM: Finished fetching cache in 40.31065468s
2:11:18 PM: Starting to prepare the repo for build
2:11:18 PM: Preparing Git Reference refs/heads/master
2:11:35 PM: Found netlify.toml. Overriding site configuration
2:11:35 PM: Different build command detected, going to use the one specified in the toml file: 'hugo --gc' versus 'hugo' in the site
2:11:35 PM: Starting build script
2:11:35 PM: Installing dependencies
2:11:35 PM: Started restoring cached node version
2:11:37 PM: Finished restoring cached node version
2:11:38 PM: v8.16.0 is already installed.
2:11:39 PM: Now using node v8.16.0 (npm v6.4.1)
2:11:39 PM: Attempting ruby version 2.3.6, read from environment
2:11:40 PM: Started restoring cached ruby version
2:11:40 PM: Finished restoring cached ruby version
2:11:42 PM: Using ruby version 2.3.6
2:11:49 PM: Successfully installed bundler-2.0.2
2:11:49 PM: Parsing documentation for bundler-2.0.2
2:11:49 PM: Installing ri documentation for bundler-2.0.2
2:11:49 PM: Done installing documentation for bundler after 6 seconds
2:11:49 PM: 1 gem installed
2:11:49 PM: Using PHP version 5.6
2:11:49 PM: Installing Hugo 0.55.6
2:11:49 PM: Hugo Static Site Generator v0.55.6-A5D4C82D2/extended linux/amd64 BuildDate: 2019-05-18T08:08:34Z
2:11:49 PM: Started restoring cached go cache
2:11:51 PM: Finished restoring cached go cache
2:11:51 PM: Installing Go version 1.10
2:11:51 PM: unset GOOS;
2:11:51 PM: unset GOARCH;
2:11:51 PM: export GOROOT='/opt/buildhome/.gimme_cache/versions/go1.10.linux.amd64';
2:11:51 PM: export PATH="/opt/buildhome/.gimme_cache/versions/go1.10.linux.amd64/bin:${PATH}";
2:11:51 PM: go version >&2;
2:11:51 PM: export GIMME_ENV='/opt/buildhome/.gimme_cache/env/go1.10.linux.amd64.env';
2:11:51 PM: go version go1.10 linux/amd64
2:11:51 PM: Installing missing commands
2:11:51 PM: Verify run directory
2:11:51 PM: Executing user command: hugo --gc
2:11:51 PM: Building sites …
2:12:21 PM:                    |  FR
2:12:21 PM: +------------------+------+
2:12:21 PM:   Pages            |  515
2:12:21 PM:   Paginator pages  |   17
2:12:21 PM: Non-page files   |  758
2:12:21 PM:   Static files     | 1734
2:12:21 PM:   Processed images |  488
2:12:21 PM:   Aliases          |  186
2:12:21 PM:   Sitemaps         |
2:12:21 PM:     1
2:12:21 PM:   Cleaned          |
2:12:21 PM:    0
2:12:21 PM: Total in 29970 ms
2:12:21 PM: Skipping functions preparation step: no functions directory set
2:12:21 PM: Caching artifacts
2:12:21 PM: Started saving pip cache
2:12:21 PM: Finished saving pip cache
2:12:21 PM: Started saving emacs cask dependencies
2:12:21 PM: Finished saving emacs cask dependencies
2:12:21 PM: Started saving maven dependencies
2:12:21 PM: Finished saving maven dependencies
2:12:21 PM: Started saving boot dependencies
2:12:21 PM: Finished saving boot dependencies
2:12:21 PM: Started saving go dependencies
2:12:23 PM: Finished saving go dependencies
2:12:23 PM: Build script success
2:12:23 PM: Starting to deploy site from 'public'
2:12:24 PM: Creating deploy tree asynchronously
2:12:28 PM: 310 new files to upload
2:12:28 PM: 0 new functions to upload
2:12:39 PM: Starting post processing
2:12:40 PM: Starting post processing
2:13:21 PM: Post processing done
2:13:21 PM: Post processing done
2:13:21 PM: Site is live
2:13:21 PM: Site is live
2:15:15 PM: Finished processing build request in 4m37.185959849s

I have to try without quotes and will give you the results. But strange thing is that locally everything build ok on my computer and on the computer of 2 or 3 other persons that tried it out of curiosity.

Is your publish dir named something else besides public?

No, my publish dir is public…

Nevermind. That error makes sense now. Go ahead and revert your build command to what it was before.

Is there a chance the problem comes from either the use of partialCached or the scoping of .Scratch?

There’s a long article about the scoping of .Scratch here - and the section about how range effects the scope might be relevant.

And I’m not sure why you’re using partialCached in line 15. If each card is different, I’m not sure how caching helps.

@funkydan2 thanks a lot for your reply. Scoping of .Scratch was the matter. Reading the article you pointed helped me arrange the way I called the .Scratch function within range. It seems that other side effects of this .Scratch scope problem disappeared with my fix.

partialCached was not the problem. I use this function because the same card appears in different places: in the blog listing, but also in the suggestions at the end of an article, and in the taxonomy pages (pages that list articles for a given tag).

Still, it’s not very clear to me why the code worked locally, but not on netlify. I guess it has to do with parallel processing of pages.