Archives: Tech

  • How I Fixed IndieAuth Problems by Adding rel=”me” in WordPress

    How I Fixed IndieAuth Problems by Adding rel=”me” in WordPress

    Have you ever wanted to use your own website to log in to other sites? That’s what IndieAuth helps you do.

    But what if the special WordPress plugin for IndieAuth stops working?

    That’s what happened to me. So, I found a simple way to fix it myself—with help from something called the Code Snippets plugin.

    Let me show you how I did it.

    What Is rel=”me”?

    rel=me is a small bit of code that you can add to your site.

    It tells other websites which social media accounts and links belong to you.
    This helps prove that you are really you when you log in or connect your accounts.

    For example:

    <link rel="me" href="https://mastodon.social/@yourusername" />
    <link rel="me" href="https://github.com/yourusername" />

    You can add as many links as you want for your different profiles.

    Why Did the Plugin Break?

    Sometimes, plugins don’t work because:

    • Your WordPress site or theme gets a big update.
    • Another plugin causes problems.
    • The plugin just hasn’t been updated in a long time.

    When this happens, important things like rel=”me” might not show up on your site.

    How I Fixed It With Code Snippets

    Instead of changing tricky WordPress code, I used the Code Snippets plugin.

    This plugin lets you safely add new code to your site, kind of like adding stickers to a notebook.

    Step 1: Get the Code Snippets Plugin

    • Go to “Plugins” in WordPress.
    • Click “Add New.”
    • Search for “Code Snippets.”
    • Install and turn it on.

    Step 2: Add Your rel=”me” Link in Header & Footer

    • Go to your WordPress dashboard.
    • Open the Code Snippets plugin.
    • Find the section for “Header & Footer.”
    • In the “Header” area, paste your rel=”me” code.
    • Change the links to match your real accounts!
    • Save your changes.

    How to Check If It Works

    • Go to your website.
    • Right-click and choose “View Page Source.”
    • Look for your rel=”me” links in the head section.
    • Try using IndieAuth again on another site.

    If you see your links, you did it.

    Why This Helps

    Plugins can break sometimes. But you can still show other sites which accounts belong to you. Adding rel=”me” links by yourself is a simple fix.

    This way, you stay in charge of your online identity, even when tools break. Give it a try and see how easy it is.

    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 long does it take to restore from a backup on Xserver?

    How long does it take to restore from a backup on Xserver?

    tl;dr it took me 20 hours.

    The official guideline from Xserver is that restoring from a backup takes about 10 minutes for 10GB of data. However, actual restoration time can vary greatly depending on the amount of data, the number of files, and the current server load.

    Based on user feedback and real cases:

    • Restoring less than 1GB took about 4 hours for some people.
    • Restoring 3.7GB took around 12 hours in one instance.
    • Restoring 25.5GB took about 7.5 hours in another example.
    • Some users have reported restorations being completed in just a few minutes.

    Both the official manuals and user reports warn that the process can take much longer during periods of high traffic or with large amounts of data.

    Summary

    • Official estimate: 10 minutes for 10GB
    • Actual time: Can range from several minutes to several hours; rarely, more than half a day in some cases
    • Time varies depending on: Server load, amount of data, number of files
    • You can check the progress from the control panel

    If you’re in a hurry or have large amounts of data to restore, it’s best to allow for ample time to complete the process.

    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
  • Why I Switched from Categories to Tags

    Why I Switched from Categories to Tags

    For years, I ran my WordPress website using the classic combination of categories and tags to organize my content. Each post would find a home in one main category—and then gather a handful of tags for good measure. But recently, after spending some time exploring Ghost.org and its elegant approach to publishing, I realized there might be a better way.

    Inspired by Simplicity

    Ghost’s platform immediately struck me with its minimalistic and focused user experience. One thing I noticed was the absence of rigid, hierarchical categories. Instead, Ghost leans on tags as the main way to group and discover content. This led me to a simple question: What if I ditched categories altogether and made tags my core content taxonomy?

    Making the Switch

    The migration wasn’t difficult. I removed categories from my WordPress setup and started organizing everything by tags. Suddenly, posting felt more flexible. Instead of worrying about which category a post belonged in, I could simply assign tags that best described what the article was about.

    What Changed?

    • Navigation became cleaner, both for me and my readers.
    • Adding new topics was as simple as creating a new tag, with no need to reshape an entire category tree.
    • Discoverability improved: Readers can now click on a tag and instantly see every post on that topic, with no extra steps.

    A Fresh Start

    This approach won’t be for everyone—some sites still need the structure that categories provide. But for me, tags have opened up a new, modern way to organize and explore my content. If you’re looking for a flexible, user-friendly taxonomy, give tags a try—you might be surprised by how much simpler things become.

    in ,
  • How to Use Your Own Domain Name with Ghost.org (and Why Cloudflare Helps)

    How to Use Your Own Domain Name with Ghost.org (and Why Cloudflare Helps)

    Do you want to use your own .com or .net for your Ghost blog? It’s actually pretty easy, but there’s an important step: You should use a service called Cloudflare for your domain’s settings. Let’s break down why and how to do it!

    Why Do You Need Cloudflare?

    Normally, when you set up a website, you can point your domain to a server in two ways:

    • You use something called an “A record” for root domains (like mysite.com).
    • You use a “CNAME” for subdomains (like www.mysite.com).

    But Ghost.org needs you to use a “CNAME” for your main (root) domain. Here’s the problem: most companies won’t let you do this for the root domain! This is because of how the old rules of the internet work. Cloudflare is special because it has a tool called CNAME flattening.

    What is CNAME Flattening?

    This just means Cloudflare lets you add a “CNAME” for your main domain. When someone visits your site, Cloudflare automatically handles all the tricky parts. Your site still shows up at your own domain, and it all works smoothly.

    What’s the Big Deal?

    Without Cloudflare, you can’t use a CNAME with your main domain. Your blog might not work the way you want, or you would be stuck using “www.” in front of your address. Cloudflare makes it simple, and you don’t have to worry about the old rules of the internet.

    Easy Steps: How to Connect Your Domain to Ghost with Cloudflare

    1. Move your domain’s DNS to Cloudflare. (First, go to the company where you bought your domain, like GoDaddy or Namecheap. There, update your nameservers so they point to Cloudflare. This lets Cloudflare control your domain’s settings.)
    2. Log in to Cloudflare. Once your nameservers are set up, sign in and go to your domain.
    3. Add a CNAME record for your main domain (@). Set the “@” (which means your main address, like yourdomain.com) Point it to the Ghost address given to you by Ghost (it looks like yourblog.ghost.io).
    4. Add an A record for www A. Add a new A record. B. For “name,” type www C. For “IPv4 address,” use the special IP address Ghost told you to use for www (find this IP in your Ghost setup instructions).
    5. Make sure CNAME Flattening is ON in Cloudflare. Cloudflare usually turns this on for you. This makes your domain work with Ghost even if old internet rules say you can’t use CNAME at the root. Double-check to be sure.

    On Ghost’s side, it’s just three steps:

    1. Enter the domain you want to use.
    2. Create your DNS records (with Cloudflare).
    3. Activate your custom domain!

    Now your Ghost blog will show up at your custom web address!Here is your original step-by-step list, revised for a middle school reading level with your notes included, more line breaks, and simple words:

    Bottom Line

    If you want to use your main domain (like mysite.com) for your Ghost blog, use Cloudflare and CNAME flattening. It’s the easy way to get your custom address working—even when other companies say it’s not possible. Ghost.org and Cloudflare together make your blog easy to find.

    in , , , ,
  • Fix Category Count Issues After Switching Post Types in WordPress

    Fix Category Count Issues After Switching Post Types in WordPress

    Switching post types with the Post Type Switcher plugin can cause incorrect category counts. Fix it easily by deleting the problematic category:

    1. Identify the Issue: Check which category shows incorrect counts.
    2. Delete the Category: In the WordPress dashboard, go to Posts > Categories and delete the broken category (posts remain intact).
    3. Reassign/Create Category: WordPress will recalculate counts when posts are reassigned or defaulted.

    This quick fix resolves misaligned counts and keeps your site organized. Advanced users can opt for database solutions if needed.

    in