Anyone familiar with #Hugo enough to tell me if I can get it to just make me a static site without any extra features? No blogging, no "featured" pages or whatever. I just want to stick a bunch of markdown files into a directory structure and have them rendered into HTML.
You know, the thing I did in 30 lines of C#, but with proper linking between pages. Heheh.
Este domingo, HUGO vuelve a tierras madrileñas.
#OsNaufragosTeatro #Hugo #Autismo
It feels good in the curent situation to be fully free of any proprietary solution.
#Linux #Debian #FreeBSD on all systems only, own #public #DNS servers on own systems including management.
#Mastodon, #Matrix , #Bridges , #Email , #SOGo #Nextcloud #Owncloud #UnifiedPush #ntfy #HomeAssistant #WebSites mostly done with #Hugo, and far more all self hosted on own systems in the basement or in our housing rack.
Mobiles #GrapheneOS and #LineageOS
Whatever #Trump #Microsoft aso does i dont care
If you're a web designer or developer, this might be just what you need! I've created a website showcasing the most beautiful and inspiring web designs. Check it out here: https://thecolophon.com/
With the update to #Pixelfed 0.12.5, I was finally able to export all my statuses. Before that, there was a hard limit of 500. Even though I only had about 170 posts of my own, all shares and likes and stuff counted into that balance, hence no download for me. Yet.
Now that I got a nice .json file, I used Excel to convert this into a usable table. Yeah, I know, Excel! But LibreCalc doesn’t understand .json and I have to use Microsoft shit at work anyhow. So why not take advantage of that?
The Pixelfed export contains not only texts, but also the URLs for all images. Copy that column of URLs to a text file, push it through WGET et voilà, a directory full of joy.
All I have to do is write a short macro which takes the available info from the spreadsheet and creates separate .md files for use in #Hugo or whatever platform I want to show the images on.
Since I don’t need any Pixelfed-specific functions, I can now close down my two instances. Future images will go to #Friendica and – via another script yet to be written – also to my blog.
Bonjour à tous , je présente un peu plus en détail #blogdown , et le worflow de publication d'articles avec #hugo : https://ordinatous.github.io/blogdown/2025/03/29/rstudio-et-blogdown-partie-2/
Today's accomplishment:
Got #hugo to *actually* include JS correctly depending on page.Store settings from shortcodes.
You can define "shortcodes" in Hugo for things like "insert a video player here". So when I say `{{< video "foo" >}}` it'll insert whatever HTML I've defined for playing the "foo" video. The problem is that most of the interesting things that you can do with shortcodes (video, echarts, mermaid, etc) need Javascript to work. So the usual pattern is that the shortcode template calls something like `{{ .Page.Store.Set "hasMermaid" true }}` and then the include-all-the-Javascript template only includes the JS if `.Page.Store.Get "hasMermaid"` is true, so you don't end up adding extra JS all over the place.
It worked fine for each individual post's page (/post/YYYY/MM/DD/foo/) but not for / or /page/X/. So any time I put a JS-needing shortcode above the fold on a post, it failed to render correctly.
I'm not entirely sure how I broke it, but something about the way I was doing summaries kept .Store from propagating right, so none of the logic that used page.Store.Get(...) thought that the feature was used on the page, so none of the JS was included, breaking charts and video.
Reverting my article-summary changes fixed .Store propagation (but looked ugly), and then it was just a matter of walking through it line by line to see which line broke it. I ended up reverting to `{{- with .Markup "home" -}}{{- with .Render -}}` instead of `{{- .Summary -}}`. The generated HTML is identical, but .Store works now. And I have a headache, after a total of about 5 hours looking into this.
I'm impressed with how far Hugo can push Go's text templates, but... maybe that wasn't the best way to implement something this complicated?
Periodic update:
- graduated from my studio engineering program
- minor medical things
- more background on the song we released CC-BY-SA this week
I'm looking for a new comment system for my #Hugo blog, and I'm not seeing any clearly great options.
I've been using #Commento for #comments on my blog for a few years now, and it's about time to switch comment systems.
Commento has been effectively unmaintained for 4 years (see https://gitlab.com/commento/commento). Their (paid) hosted version has been continuing to work, but I've seen increasing numbers of errors lately, so it's time to move.
I'd really *love* something that could integrate semi-natively with #activitypub so new blog posts could show up in Mastodon and Mastodon replies would show up as comments, *but* I don't want to require a fediverse account for commenters; that rules out most (all?) of the embedded-Mastodon comment options.. After looking through Hugo's somewhat-outdated list of commenting options (https://gohugo.io/content-management/comments/), it looks like #Discourse is the only option that even *slightly* fits that, and it's a lot heavier-weight than I really want to run today. Hours-of-maintenance-per-comment should be less than 1, thanks.
Basic requirements:
- Either easy to self-host or has a cheap hosted option.
- Allows anonymous comments plus common external auth options.
- Possible to import comments from Commento, possibly requiring code on my part, but it needs to allow arbitrary names, etc.
- Works with static sites.
- Not a privacy disaster
- If self-hosted, ideally written in something sane -- Go, Rust, etc. *Ideally* it's a single binary that listens to HTTP and stores comments in Postgres.
- Supports Markdown.
Does anyone have anything that they're really happy with?
Just posted a brief description of how I incorporated the HTML details disclosure element into my emacs to ox-hugo to hugo stream. Many who are more tech-savvy than I will find this obvious, but it might be helpful to some.
https://johnrakestraw.com/post/using-the-html-details-disclosure-element/
This was also an opportunity to test Obsidian's new Web Viewer plugin. It is so much of a smoother experience, being able to edit your text and see the effect right away. If you use something like Hugo's dev server locally, it will cause the page to re-render each time the file gets saved, so changes are near-instantaneous.
Great stuff!
I have now worked for close to a decade with #Git and feel pretty confident using it nearly every day.
Still, whenever I have to deal with submodules, I feel incompetent as hell. It almost feels like that is by design 
IMO #HUGO definitely should have a different mechanism for including themes by default.
For most of my sites I can manage that issue with #Nix at least.
A couple of years back I wrote a blog post about linking my static blog posts to Mastodon threads so that the threads can serve as blog comments.
I realise I never pinned that post to my profile, and I have since deleted the Mastodon thread, so I'm sharing it again. I'm pinning it this time!
Hey @NVAccess someone wanted me to record going through their #Hugo and #Eleventy website, on video, using a screen reader and upload the video to PeerTube. Is there any visual things I can do to make the experience easier to follow for sighted viewers? I've enabled speech viewer but I can't seem to alt tab to it? Am I supposed to dock the speech viewer on the side of the screen or keep it focused? I have the highlight enabled. Is there anything else I can do to make the keystrokes easier to follow visually built into NVDA itself?
Did you know that by default your zippy static website created with #hugo and served via #caddy doesn't support HTTP content compression? And did you know that of the three common compression options (gzip, zstd, and brotli), brotli gets substantially better compression results for most content (better than zstd!) and is supported by basically everything?
I wrote up a few details here:
https://scottstuff.net/posts/2025/03/09/precompressing-content-with-hugo-and-caddy/
I also wrote a tool to make pre-compressing directories full of web pages much less complicated, see https://github.com/scottlaird/incremental-compress.
I've written about how we've migrated the @OpenBio website from Wordpress to Hugo. Which was surprisingly easy, especially given that the OBF website has been around since _2001_, so there's nearly 25 years worth of blog posts, conference pages etc.
Last RT> I have actually nominated some things for the 2025 #Hugo awards :)
We have moved our website https://open-bio.org/ from a hosted #WordPress instance to #Hugo running on #GitHubPages, with a new look and feel (and light/dark themes) but preserving all the content. Thank you to everyone who helped make this happen!
#
