Closing bugs to stop discussion does not make them not bugs

This is in reference to the following filed bugs: Shortcode escapes closing HTML tags · Issue #6006 · gohugoio/hugo · GitHub, Shortcode escapes closing HTML tags · Issue #11516 · gohugoio/hugo · GitHub, the later of which was closed then marked as invalid with almost no discussion, and no ability to continue the discussion.

Look, I’m not part of this community. Clearly. And ya’ll have a right to manage your opensource software as you see fit. I’ve only used Hugo a little, and I’m impressed by it.

But in my brief exchange in that issue report, I feel pretty insulted. Hey, I get it, it’s tech, feelings don’t matter, fine. Still, if there’s any desire to have new folks engage with the project (and maybe there is not), interactions could be managed with more… I don’t know, decorum?

So here’s that interaction from my perspective:

  1. Encounter odd behavior, read docs attempting to search for any explanation, eventually search issues.

  2. Find the exact issue from 2019 that was filed with great steps to reproduce, no meaningful attempt to root cause it, then closed for inactivity.

  3. File a bug requesting to re-open the previous bug. Because all the reproduction steps are already available, I did not include any.

  4. Get asked one question, answer the question, then told because someone else couldn’t repro it, it’s actually not a bug. Closed. No explanation of how they managed to get it to work. Additionally, get told what I really need is troubleshooting help (implying it’s just a me problem) and sign up over here.

  5. So I put together the simplest example I can come up with to repro it from an entirely new project, and respond on the closed bug with that, re-iterating I am reporting a bug not trying to get someone to troubleshoot my code for me.

  6. I get a response that does a few things: it seems to say I did not include all the repro steps (I did), it claims the reason I am experiencing this behavior (which if it was the correct explanation, could have been in the initial response!) and then marks the bug as invalid and locks it so there can be no more discussion.

  7. Of course, the explanation provided is inadequate to explain the behavior. And even if it were adequate, the docs outlining the behavior are unclear enough that it would be a reasonable conclusion to update the docs as a result. But the issue is locked, because obviously that solves the problem.

Anyway, I can take a hint. Hugo is clearly not a community for me. Good luck.

Your topic title is right.

Your issue got closed by a bot because of inactivity for some time threshold. That behaviour isn’t perfect, but with limited resources that’s currently how it is. Hugo works mostly great (I use it myself), but there are known and unknown bugs. Some are actively being worked on, some may take a long time to fix.

3 Likes

I reproduced your ‘bug’ which is a stray </p> tag, but the solutions provided by Joe in point 5 are what you should have followed to solve your issue. Out of the two options @jmooring shared, there is one additional ones that you can try:

  1. Pass the {{ .Inner }} through the RenderString function – {{ .Inner | .Page.RenderString }}. This option requires you add this code to your hugo.toml file–
[markup]
  [markup.goldmark]
    [markup.goldmark.renderer]
      unsafe = true

Joe’s first option requires you to change your code to <p>{{ .Inner }}</p> so that it appears on one line. The chomp function adds a stray <p></p> tag, so I’m not sure what’s happening there.

If I were you, I’d just go with Joe’s first option, or remove the <p></p> tags around {{ .Inner }}.

5 Likes

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