AsciiDoc external helper not working in Fedora (Incorrect content rendering)

support
1

I switched to Linux as my primary operating system a few months ago and today I am finally updating my website with scripts to generate it in Linux… however I see that my pages are no longer rendered properly, it seems like the AsciiDoc external helper is not working for me :frowning_face:

All of my content pages are written in AsciiDoc, and they used to work perfectly fine in Windows, I have asciidoctor installed on my computer but Hugo is still not properly processing the content pages. I am using Fedora 29 with Hugo v0.53 and AsciiDoctor v1.5.6.1:

TheDcoder@BeastLappy ~/D/P/W/ProxAllium-Website> hugo version
Hugo Static Site Generator v0.53 linux/amd64 BuildDate: 2018-12-28T17:48:24Z
TheDcoder@BeastLappy ~> asciidoctor --version
Asciidoctor 1.5.6.1 [http://asciidoctor.org]
Runtime Environment (ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux]) (lc:UTF-8 fs:UTF-8 in:- ex:UTF-8)

The repository for my website is public so you can easily download it and try it for yourself to see if this issue is present: GitHub - DcodingTheWeb/ProxAllium-Website: Source code for ProxAllium's website

Thank you for the help in advance! :smile:

P.S Don’t forget to install AsciiDoctor if you want to try out the issue, you can simply use hugo server to see the live version, the build scripts don’t have much involvement in the generation of the site.

2

Do you have Hugo installed via Snap?

3

No, I have installed hugo from @daftaupe’s fedora copr repository.

4

In that case, nevermind.

5

No problem, I guess you were trying to figure out if the issue was caused by snap’s sandboxing/islotion? :smile:

6

You’re running this on Linux? Are you certain that asciidoctor is in your path?

7

Yes, I am pretty sure that asciidoctor is in my path, I can use it from my shell.

8

The output from hugo --verbose --debug does not mention what hugo is detecting my .adoc content files as, but to me it looks like it is falling back to markdown as default. Here is a comparision of the output from hugo server and my live production website:

hugo server:

image
image.png948×435 41.8 KB

Live website:

image
image.png943×682 47.5 KB

I have to migrate my website to a different domain since my current once is going to expire within a month, I would like to do it as soon as possible to soften the impact of search engines by making them detecting the newer website before the domain expires via a permanent redirect.

I would appriciate any help in regards to my issue, thank you in advance!

9

I just tested this on my Windows 10 device with AsciiDoctor 1.5.7.1 and Hugo 0.53 and had the same problem you’re having. I fixed it by putting front matter at the top of the .adoc files, e.g.:

+++
+++

Empty front matter (as above) worked for me.

It’s weird that these files worked for you on your Windows device :upside_down_face:

1 Like
10

That was excellent advice! Now my pages render properly as they were before :smile:

I see that the frontmatter syntax for TOML coincides with AsciiDoctor’s triple plus pass-through syntax. I wonder if this is a proper requirement in the newer versions of Hugo or a bug…

Actually I didn’t really test it on Windows with the latest version of Hugo, older versions worked fine. When I migrated to Linux I got the latest version available and I saw that the page rendering was broken, so I thought this maybe related to Linux… I didn’t really bothered to boot back into my old Windows OS to update and test Hugo :sweat_smile:

11

I have opened a ticked in GitHub in this regard: AsciiDoc content not rendered properly without empty frontmatter · Issue #5588 · gohugoio/hugo · GitHub

12

This issue seems to be fixed, I just tested with v0.55.5 and my pages render fine when I remove the empty frontmatter…

@_nm Are you able to test this to confirm my findings?