I’m looking to build sort of a commenting system. I’m going to write a serverless function that will accept a POST with the payload of comment, and then append the comment to a CSV file which will be local to every page for this blog. When the blog get’s compiled by Zola, the comments will be read in from the CSV file.
So, I’d like to ask around about the best way to uniquely identify each of these blog posts? It’s been a few months since I worked on my site, so I don’t quite remember everything in Zola’s design. I imagine explicitly setting a permalink is one way? But I’m open to hearing from all of you about alternatives.
Ideally it would be:
a.) unique site-wide (I.e. for all the articles)
b.) something that would never change (even if the article’s title changes)
c.) tell my backend where to locate the directory containing all the comments for this article
You’re not the first to start thinking of a comment system. When searching this forum, the following solutions based on Javascript pop up:
But that doesn’t exactly make the comments static.
I don’t like the idea of CSVs. The CSV format is quite fragile wrt. escape sequences.
The best idea I’ve heard for static comments, that I liked, is to use the GitHub API to create comments based on creating web-based pull requests. Then have a CI check that validates that it’s a valid comment (i.e. does not delete anything and only appends in allowed places). This approach solves authentication (you need a GitHub account to comment), and it solves where to host the submit form and the server-side validation, and it integrates neatly with re-publishing the site; and you can decide whether to auto-merge if CI approves that it’s a legal comment, or moderate every comment, or something in-between.
Hi sshine, thanks for your reply. I’ll respond to your comments a little below.
To others reading this, I’d like to keep the discussion focused on my question about what is something that acts like a primary id in Zola.
I’ll have to think more about your point regarding escape sequences and CSV (maybe the solution is to just be extra careful?).
The reason why I chose CSV over the other 2 options that are supported by Zola (JSON and TOML) actually has to do with using the GitHub API for adding comments. I’m not an expert at lower level git stuff (Parts of the GH API basically expose an http interface that offers just direct manipulation of blobs and trees, same as the CLI), but I don’t know of an easy way to “append” to a JSON or TOML array.
The reason why I chose CSV was because the path to just appending to the end of the file seemed more straightforward. You basically just use the blob API to create a new blob, then the tree API to create a new tree consisting of the original file + the new blob, and then you use the higher-level API to create a pull request to have that new tree replace part of the old one.
With something like CSV I can easily append to the file, however with JSON arrays/objects and with TOML arrays there are matched brackets, so essentially you always have to “insert” into the file instead of appending.
I’m sure conceptually it’s totally possible to “insert” in the right place, using a similar process as I was describing above, but I don’t know how to do it and there are not a ton of examples of using the low-level API to do this.
Also, the whole reason for caring about this to begin with is basically performance. I’m not really building this commenting system for anyone else besides myself, and I have some limitations on the performance side of what I’m permitted to do.
I’m blanking on what that go to comment service is called (Discourse?). The full slug/path would be what I use as a unique id, maybe hashed, but it also means you need to either not change it ever, or keep a copy if you do ([extra] old-slug = "the-old-title.md").
Alternatively, there’s an initiative called the Indie Web that looks to bring communication and networking to self hosted websites. I’m no expert, and it seems maybe a bit complicated and disorganized, but I gotta respect what they’re trying to do.
Hi @mikekasprzak , thanks for the comment. Yeah, I had a feeling that would be the case, and it’s honestly not so bad even in the scenario where this info has changed. Thanks for the input.
Just in case there’s any confusion for anyone else reading this, staticman is a static commenting system and doesn’t need javascript for serving the comments, since they are held as static files in a git repository (the idea is, within your SSG repo with your content).
Staticman can also be run as a serverless function, see the post here by the author.
Comments are added by users via a standard comment form, received by staticman (in a serverless function if you wish) and will create a commit in your git repo adding the comment, at which point its work is done. The user commenting doesn’t need a github account.
@spence I don’t know if you’ve already looked at it, but it might be a useful reference since it seems you’re trying to do something similar.
Hi @JeffPorter, I did! I actually ended up building my own because after taking a closer look none of them really did what I wanted. You can take a look at r3ply.com, where there’s a link to a demo. I will open source it at some point because I’ve received a lot of enthusiasm about it.