Tech Tag: Hugo

  • What Using ghost.org Taught Me About Staying True to Myself as a Creator

    What Using ghost.org Taught Me About Staying True to Myself as a Creator

    Tried out ghost.org. It’s definitely faster than WordPress, this was surprising. Plus, you don’t have to write in Markdown like hugo, so it’s super easy to create articles. Newsletters can be sent out automatically too. It felt like I could just focus on writing.

    But reality was different. As soon as I got a subscriber for my newsletter, questions started popping up. “This subscriber probably wants to hear more about this topic. Is it bad if I write about something else? But if I publish, the newsletter goes out automatically, and while I can manually turn off the newsletter, isn’t that missing the point of using ghost.org?” As followers increased, I started feeling like I should only post about popular topics. The number of things I talked about narrowed, and it wasn’t as fun anymore.

    I hated the newsletters going out automatically. But I didn’t want to turn them off manually either. And I didn’t want to limit my blog topics. That’s where the frustration kicked in.

    With WordPress, you can create custom post types, so you can keep adding new types of posts without mixing them up with regular ones. ghost.org doesn’t have that concept.

    Eventually, I got tired of it all and decided to go back to WordPress.

    What I felt from using ghost.org is this: every time I tried to talk about something new, I started worrying, “What if I lose followers?” Sure, it’s not the end of the world if someone unsubscribes, but once you start thinking about it, even things you enjoyed become less fun. That’s why, in times like these, what really matters is expressing yourself and having fun, and picking a platform that lets you do just that.

    in , , , ,
  • [Hugo] Sitemap Index with Last Modified Dates

    [Hugo] Sitemap Index with Last Modified Dates

    In Hugo (and most modern static site generators), the value of .Lastmod (which you use for <lastmod> in your sitemap) is determined as follows, in this priority order:

    1. Front Matter lastmod: If you have a lastmod parameter in your content’s front matter, Hugo uses this date.
    2. Front Matter date: If lastmod is not set, Hugo will fall back to the date parameter in front matter.
    3. Git Info or File Mod Time (if enabled):
    • If you enable enableGitInfo = true in your Hugo config, Hugo can use the latest Git commit date for the page or section as lastmod.
    • If not using Git, Hugo may use the file’s last modification time on disk.

    So, in the context of your sitemap:

    • The <lastmod> value will show the date in lastmod front matter if present.
    • If lastmod is missing, it will fall back to date in the front matter.
    • If neither is present, and Hugo is configured for Git info, it uses the last Git commit date.
    • Otherwise, it may use the file’s last filesystem modification date.

    Summary:

    The last modified date in your sitemap is either the explicit lastmod in your page’s front matter, or (if missing) the next available source based on Hugo’s logic described above. For accurate sitemap dates, always set lastmod front matter for your pages/sections.

    in
  • How to Set Up the Timezone in Hugo

    How to Set Up the Timezone in Hugo

    Do you want your blog to show the right time, no matter where people are? Here’s how you can set the timezone for your Hugo site.

    Step 1: Add the Timezone to Your Settings

    Find your main Hugo settings file. It’s called config.toml (or config.yaml or config.json or hugo.toml).

    Open this file. Add this line:

    texttimeZone = "Asia/Tokyo"

    Replace “Asia/Tokyo” with your city’s timezone.

    Step 2: How Hugo Chooses the Timezone

    Hugo checks a few places to find out what time to use:

    • If the date has a timezone, Hugo uses that (like +09:00).
    • If you put a timezone in your templates, Hugo uses it.
    • If you set the timeZone in your config file, Hugo uses that.
    • If you don’t set anything, Hugo uses UTC (the “global” time).

    Step 3: Showing Dates in Your Blog

    To show the date on your blog, you can use this code:

    {{ .Date | time.Format "2006-01-02 15:04:05 MST" }}

    If you want to force a date to use a certain timezone, use this:

    {{ time.AsTime .Date "Asia/Tokyo" | time.Format "2006-01-02 15:04:05 MST" }}

    Now your dates will always show the correct time for your city!

    Step 4: For Blogs with More Than One Language

    If your blog uses different languages, you can use a different timezone for each one. Just put timeZone = "Asia/Tokyo" under each language in your config file.

    Step 5: Extra Step for Special Websites (Like Cloudflare or Netlify)

    Sometimes, the place where you put your website (like Cloudflare) doesn’t know your timezone. You may need to also tell it which timezone to use by setting:

    TZ=Asia/Tokyo

    This helps make sure your times look right everywhere.

    Tips and Troubleshooting

    • If your blog still shows the wrong time, check that you wrote the timezone name correctly.
    • If you see numbers instead of time zone names (like -0700), your website might not know your city’s time. Try setting the TZ variable, or ask for help.

    That’s it.

    Now your Hugo blog should show the right time, no matter where you are in the world.

    in
  • [Hugo] You must run npx pagefind everytime you build if you want to index your new posts

    [Hugo] You must run npx pagefind everytime you build if you want to index your new posts

    1. Build your Hugo site (create/update /public):

    hugo

    This builds your static site in the public/ directory.

    2. Run Pagefind to index the site:

    npx pagefind --site public

    This command creates the /public/pagefind/ folder, which contains the JavaScript and CSS needed for the search UI.

    Important:

    You must run both hugo and npx pagefind –site public every time you rebuild your site, every time you add, edit, or remove content in your Hugo site that you want to appear in search results, before deploying or serving from the /public directory.

    in