Hugo_stats.json is missing some classes when there is somewhere an apostrophe in string

I narrow again the problem. I miss interpreted. It is not index.html vs layout/list.html.

It is I have a partial code just before my problem. Removing this partial makes the bug disapear.
I gave the detail in GitHub.

I invite you as i’ve done for jmooring.

OK. Narrowing to one line responsible for making wasting time to all of you (but still no sensible explanation for me).

Removing the comment line {{ "<!-- Hero Area Image d'accueil -->" | safeHTML }} in this hero.html partial solves the bug.

Just that. Weird.

I. GET. IT !

Removing the ' in the comment solves the bug.

I have found that it is always best to wrap strings in backticks instead of double quotes in Go templates.

Strings wrapped in backticks are literal.
Strings wrapped in double quotes are interpreted.

This way one avoids problems like the one you encountered.

Therefore the Go comment in your template should read:

{{ `<!-- Hero Area Image d'accueil -->` | safeHTML }}

For an explanation have a look at the Go spec: String Literals

1 Like

Thanks a lot @alexandros. Will do this in all my site asap. Thanks a lot for the tip.

Try my suggestion first and then if it works -as I described above- mark it as the solution, so that people who might read this forum topic, know that this is how Go templates handle strings.

1 Like

Works fine. No pb.
It solved some identical problems I didn’t saw because less obviuos than a missing icon. Thanks again.

Only thing is a wrong analysis/formatting in VSCode plugins for go template. Nothing huge.

[EDIT] reported this small VSCode plugin bug to budparr on their site. They corrected it in no time !!! Whoa !!!

… or you could drop HTML comments in the final output …

1 Like

Yes Bep. All solutions are good. No brainer.

The problem for me was to understand the root of this weirdo. As you saw, not an easy trip.
Once I understood, workaround where simple.
You gave me the light ( … and there where light …) when you ask to have exacty same code on home and section. This was the declic as I have to take care of other partials.

I’m glad you were able to resolve the problem, but what was the problem? This is a valid HTML comment:

<!-- Hero Area Image d'accueil -->
1 Like

yes, and a big thank you for your help & time. Really.

Problem was an apostrophe ' in the HTML comment (because in a go template), while putting this in go-template beetween double quote ".
This make the parser go wrong for some case.

Workaround was either :

  • to remove the faulty apostrophe '
  • to enclose the comment in backticks ` instead of double quote ".
  • or better solution™ by Bep : remove the line. Same thing as in the movie “Speed” : remove the hostage from the situation by shooting the hostage in the leg.

But the main point was to understand where the problem was.
Because this problem was belonging to an other template

Same like a huge leak on your house east wall. After scrapping the wall you discover that the root cause is on the east side of rooftop :slight_smile:

As I said above Go templates interpret strings enclosed in double quotes, hence the error for the extra single quote (meant as an apostrophe), despite the valid go/HTML comment.

This is how Go templates operate.

To use literal (uniinterpreted) strings one must enclose them in backticks.

We had this discussion before over here with @moorereason

cc: @jmooring

1 Like

Yes, you where very clear.

Confusion (for me) is that we can do some similar printf valid with ".

{{ printf "<!-- Hero Area Image d'accueil de %s -->" .Site.Title | safeHTML }}

I will check where to put an advice in the hugo doc. ==> Merge Request

Τhe %s verb in conjunction with Hugo’s printf function outputs:

%s the uninterpreted bytes of the string or slice

ref: fmt - The Go Programming Language

Basically you created a string literal with
printf "<!-- Hero Area Image d'accueil de %s -->"

1 Like

This is not related to Go templates etc. This is my fault … We look for HTML elements, but skip any string inside quotes; in this case the parser found an opening quote, but no closing, so it skipped to the end …

So, the reason we’ve not seen this bug before is probably that Go templates do remove HTML comments, but not in the way it’s added here.

Personally

  • I really like template comments in templates, use them all the time
  • I don’t see the value of HTML comments.
2 Likes

I understand.

But my use case (not a huge needs tho) is that my websites are for other non technical people (my daughters, my friends, etc …).

And I wanted to give a hint about where are the sources of what they want to change by themself (if easy).

So the HTML comment (the one who will stay in the final html code) was the tool I choosed to lead them on the right path of the source. My sites/themes scan be quite sophisticated in their organisation. I want to avoid a 30page notice :slight_smile:

But as said, just I was not aware about all those impacts. I will change whatever is needed & adapt to what is logic and rock solid.

But it’s a bug and we will fix it…

2 Likes

Here we can see the main difference between northern people (rational, transparent, efficient, no fear of telling about mistakes, etc …) and French people, like for example our beloved President who recently claimed that “I would not say it’s a failure : it didn’t work”.

Ok. Good to know. Looking forward to a fix.

In any case I have switched to using backticks for most of my use cases in Hugo templates and this approach has saved me from several time consuming quirks or bugs like this one that @divinerites has encountered.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.