Does Hugo support the static comment? I’ve looked at this link https://gohugo.io/extras/comments/ but I didn’t see any information about supporting the static comment.
I prefer not to use Disqus or anything that are not static.
Kaiju looks great but it doesn’t let us to create the static comments.
Comment Migration: We can import the existing comment to Disqus or etc. but we need to have the JS code that load the comments from 3rd-party service. It’s the cost to the performance. Plus, it allows 3rd-party provider to load what they want to load along with our comment feeds. For example: Disqus load the related comments by default. Would it be better if we can import the comment to Hugo and generates the static file?
Search (read only) : I don’t search the comment much but if we need to support it, any search engine that can search the static HTML should be able to search the static comment as well.
Commenting (public write) : We can let the blog owner to decide whether they want to do a simple ‘email to comments’ (https://caurea.org/2012/03/31/this-blog-has-comments-again.html) or just have a simple custom form that loads nothing but allow the commenter to send the comment to the server. And the blog owner or CI or that server will create a comment (maybe using hugo new comment/title.md ) and rebuild the blog to generate the new comment.
Edit (private write) : We can use the same approach as “Commenting” but I don’t mind sacrificing this feature.
Real time comment capabilities : Nice to have but I can live without this feature.
Push the latest comment : Nice to have
Pagination for comments: I think this is a must-have feature.
Nested Comment (post/reply) : Nice to have. Even facebook supports only 1 deep-level.
What would be the build flow if I use that tool? I mean, Will this tool generates/import the comments as markdown files under hugo content folder? How will hugo pick up those files when I build to generate the static site to public folder? What do we need to change in theme? I assume that is no API for comments in creating a theme.
On Mon, 26 Oct 2015 10:37:00 +0000 michaelsync discuss@gohugo.io wrote:
What would be the build flow if I use that tool? I mean, Will this
tool generates/import the comments as markdown files under hugo
content folder? How will hugo pick up those files when I build to
generate the static site to public folder? What do we need to change
in theme? I assume that is no API for comments in creating a theme.
Well, Isso is similar to Disqus in a sense that it’s server-side
technology, so you have to install it on your production server.
Recommended setup is with e.g. uWSGI and it uses sqlite3 as database
back-end.
You can take a look at Nikola (python static-site generator) which has
support for Isso, but it simply involves to add Javascript snippet to
every Hugo-generated page, possibly by adding it to your preferred theme
similar to methods involved to add support for Disqus, analytics etc.
There is some work involved for the price of not depending on 3rd party
service ala Disqus.
But I would prefer having the generated static comments instead of loading the comment feeds from 3rd-party service or my own service. I think that having the static comment might be faster compared to loading the feed using javascript.
I would have said that type of ‘static comment’ is doable now. It could just be stored as content and displayed much like blog posts. All you’d need is each comment created as a separate .md file.
FYI, the beginning sentence of this thread wasn’t clear to me with regard to what is wanted.
a static site generator cannot support this as a whole feature when is self-hosted, as getting the comments is a server side task.
I think Kaiju is dead. The repo hasn’t been updated in years and I’ve asked twice about it on here and not got a single reply [even from its developer!].
hugo new comment/first.md (I created a comment or list of comment for my dummy post “first.md”. Is it a good idea? )
hugo new theme my-theme ( I created a theme )
In index.html of my-theme, I have the code below so it shows the list of posts. I haven’t considered about the pagination yet. How do I get the count of comments here? maybe read “comment/first.md”?
<html>
{{ partial "header.html" . }}
<body>
{{ range where .Data.Pages "Section" "post" }}
<a href="{{ .Permalink }}">
{{ .Title }}
</a>
{{ .Content }}
{{ end }}
</body>
</html>
In _default/single.html, I have the code below. How do I show “comment\first.md” in “post\first.md” here?
Dead is a strong word… but yeah, it’s in a coma. I only have so much time and without help from a community I think Kaiju will remain where it is. It’s sad, it’s a good program, but needs some love.
I think it would be even better if hugo supports the static comments instead of loading the list of comments dynamically from 3rd party. Of course, the static site won’t allow users to post the comment but we can deal with it later.
As of now, I managed to use archetype + type + section to make the static comment work for my test site. It would be better if hugo support out of box (except public-write). I am modifying the “wordpress to hugo exporter” to generate the static comments now. I will share my change and love to get some feedback on it.
Hi Michaelsync, have you followed up your approach? I think straight about exactly the same solution. Static comments are the simplest way to publich comments.
This is an old post, but I’d like to bring it to the foreground again (if I missed a newer follow-up, please let me know).
The benefit of static comments is long term: when the site is no longer active, it can still be used and archived in full, even at archive.org, really long-term.
Given Hugo’s speed, wouldn’t it be possible to simply regenerate the entire site after a new comment has been posted? As web-hook, basically?
This approach seems so obvious to me that I keep wondering why it hasn’t been pursued (or perhaps more likely: why I haven’t found it).
It’s not yet live on my site (still need to do the disqus import), but I’ve been working on something like this.
Basically I create comment files under /content/comment/test.md for example, and the content of the file is like this:
---
date: 2018-12-15T12:51:28Z
tags:
- tech life
draft: false
parent: /2018/11/my-history-in-text-editors/
author:
name: roytang
anonymous: false
username: roytang
---
<p>I don't usually need the font resize, but there's Ctrl + and Ctrl - available I believe. I haven't used VS Code long enough to have an opinion on extensions yet, maybe a follow-up post later down the line.</p>
The parent param links it back to the original page. Then in the page footer template you can have something like this to retrieve the matching comments:
<h1>Comments</h1>
{{ $url := urls.Parse .Permalink }}
{{ $filtered := where .Site.Pages "Params.parent" $url.Path }}
{{ range $filtered }}
<div class="comment">
<a href="{{.Permalink}}">Comment by {{ .Params.author.name }} on {{.Date.Format "2006-01-02"}}</a>
{{.Content}}
</div>
{{ end }}
It mostly works in my local testing, just need to see how it does when I import a whole batch of comments from Disqus and WP.
I’m fairly new to Hugo so IDK if this is the most efficient way to do it. I’m also not sure if there’s a better way to get the path component of the url from the permalink for the matching. Any advice would be great!
Once this is set up, you can just make a service to accept new comments via POST (or email or whatever method) and generate the md files (maybe set as draft first or in a separate place if you want to review them first)
(Edit: IDK what I was thinking with my first pass where I used intersect over two query sets when just one would have worked. Removed it from above)
As much as I love some of these ideas, I think many of these features (and many more) could be solved by using server-side components. For example, a form search would a great option as well that doesn’t require JavaScript.
I’d much rather see more server-side component support added to Hugo with great developer and creative design ideas going in for a more dynamic experience that doesn’t rely on JavaScript to make changes. Hugo could really benefit from a content editor and with access control using GPG keys too, but there would need to be efforts going in those directions blessed by the project leader, because otherwise they’ll stagnate too and eventually you’ll end up with a forked-version of Hugo or someone building similar capabilities into their own project.
