On runnig hugo serve -D from inventory on error occur.

[yokwejuste]

Summary

On following up Step 2 issue for Outreachy interns for this cohort, I got some challenges and difficulties. At the level of the cohorts.html, there was a problem at the level of line 110.

What you expected to happen

I actually expected this, as seen in the picture below. That will be the correct output.

What actually happened

A description for this is the picture below.

Suggestion

I have a solution which will be appropriate for this error.

[jwflory]

@yokwejuste What version of Hugo are you using? You can check with hugo version.

[yokwejuste]

My Hugo version is And from the Hugo released website, I got this info

[jwflory]

@yokwejuste Could you try upgrading to a newer version of Hugo and retest? I am not getting this issue. It could be because the Ubuntu repositories ship an outdated binary for Hugo.

Hugo releases notes are no longer published on the website, but you can find new releases on GitHub. The current version is v0.96.0. Try using the binary cross-platform installation method.

$ hugo serve -D
Start building sites … 
hugo v0.96.0-2fd4a7d3d6845e75f8b8ae3a2a7bd91438967bbb+extended linux/amd64 BuildDate=2022-03-26T09:15:58Z VendorInfo=gohugoio

                   | EN  | ES  
-------------------+-----+-----
  Pages            | 139 |  8  
  Paginator pages  |   0 |  0  
  Non-page files   |   0 |  0  
  Static files     |  56 | 56  
  Processed images |   0 |  0  
  Aliases          |  18 |  0  
  Sitemaps         |   2 |  1  
  Cleaned          |   0 |  0  

Built in 21579 ms
Watching for changes in /home/jwf/git/unicef/inventory/{archetypes,content,i18n,layouts,static,themes}
Watching for config changes in /home/jwf/git/unicef/inventory/config.toml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/inventory/ (bind address 127.0.0.1)
Press Ctrl+C to stop

[jwflory]

Looking back, this issue likely arises if the git submodule is not fully present. It could be something else, but I think we can rule this out as an upstream issue. I'm going to close this issue out from the open issues. Thanks for raising the issue here, @yokwejuste.