Making a website: home on the web

Webcraft
, , ,
1

Not a “front page” per se, but a place to call “home”, on the web.

My new imagining of interi.org is a place for digital archivists and artists to preserve and present their vision. Data, meaning, art, community, hypertext, fun.

It also means a place I can be non-mercenary, non-commercial. I can just publish my piece, and enjoy the experience. I have the other domain for my capitalism.

First off: nothing is gonna live at interi.org. Go ahead, check it out. Nothing resolves. It is not required.

Then I’m gonna load up some form of personal home pages at https://home.interi.org. Mine will be at home.interi.org/maiki. I plan to model what I’m doing, and hope others catch on.

This thread will document the steps I take to get a non-existent Hugo site uploaded to a non-existent CDN/bucket.

Wow!

2

hugo new

I know the shape of the hugo project I’m building. Let’s see which parts I’ll need, repo by repo:

  • a config repo - to hold the site settings, and pull in everything via modules.
  • base theme - this will be tule, and I only need it to get started; later I’ll pull in additional theme-y components via modules.
  • content - this will potentially many repos, but to start I need a single section: maiki

That’s it! Well, to get started.

Everyone gets a section!

In Hugo a section is a logical division of content, and a lot of info can be inferred from how a section is organized. For this site I want to emulate the idea behind tilde user directories. I’ll have one, and I can put all the maiki-specific stuff into my one repo, and it will live in my section of the site. This one-to-one mapping makes it easy to add more folks to the site, and provides an easily understandable restraint: if you publish information to this site, it will live in this place and in this way.

So I’ll create a repo that is just some text files. I haven’t loaded content via modules yet, so I’m not sure how to best format the file layout. Do I put them all in the root, include LICENSE and README, and map that to content/maiki? I think that will work, maybe with a little config tweaking.

tule as a theme

I named my tiny CSS file tule, so I’d have an easy-to-understand-for-maiki reset that told most browsers to do the thing I care about.

The idea isn’t to create a robust framework that does a bunch of stuff for me. Rather, it captures my “philosophy” of decent defaults for knowledge sharing.

Currently it is:

main {
    max-width: 70ch;
    margin: 0 auto;
    padding: 0 2vmin;
    font-family: sans-serif;
    font-size: 1.5rem;
}

h1 {
    font-size: 2rem;
}

I’m still developing exactly what I want this to become. Maybe create my own sense of separation of structure and design… at any rate, it is fine to publish now (it’s what I use on maiki.xyz). But I do need to make it an actual component/theme/module/thing. :grimacing:

A config by any other name

With modules, a “code” hugo repo has gotten kinda weird. It can basically be a single config (I think), which can provide hugo with enough instruction to pull in data and templating information and deploy a built site. Wow!

I intend to use a media server type computer at my home to deploy the site, and probably have it build once a day or week; I’m in no hurry. That means a cron job on that computer will do three things:

  1. Pull down any changes to the config repo
  2. Run hugo, which pulls down everything else and builds the site
  3. Upload changes to server

Hugo can utilize external apps for certain deployment types, but I don’t know how I’ll upload files at this point.

Next step is to create these repos, one at a time, and discover the many ways to structure home on the web. :slight_smile:

3

Oh, turns out I already have a repo for tule: maiki/tule - allthe.codes

Nothing there, just LICENSE and README.md.

Locally I’ve got some more, and am using it on maiki.xyz, so let’s commit each file and see what it does…

Gotta have a stylesheet, which lives at static/css/style.css (Add style sheet · 71c84337a0 - allthe.codes).

That’s useful, obviously, but I wanted tule to be an easy way to get started on new projects, so I provide a little default structure, as well.

We start with layouts/_default/baseof.html (Add baseof template · 0d124bf719 - allthe.codes):

    <!doctype html>
    <html lang="en">
        <head>
            <meta charset="utf-8">
            <meta name="viewport" content="width=device-width, initial-scale=1">
            <title>{{ block "title" .}}{{- .Title -}}{{ end }}</title>
            <link href="{{ "css/style.css" | absURL }}" rel="stylesheet" type="text/css">
        </head>
        <body>
            <main>
            {{- block "main" . -}}
                <header>
                    <h1>{{- .Title -}}</h1>
                </header>
                {{ .Content }}
            {{ end }}
            </main>
        </body>
    </html>

With this template I’ve said: by default I want every page to have this same structure. It produces a very plain, very readable website. I’ve got two blocks, one for title and the other for my main section. Generally those are the only two portions I want to change, or at least so far. This is my lowest common denominator framework, so not a lot is needed to get started.

Then… you know what, I think that’s it. I have some other layouts, but I’m not using them. I think that is a complete (minimalist/brutalist) theme. 40 lines. Huh.

Not quite. It requires a template to produce the home page, and I use index.html (Add index template · 7002ec94b4 - allthe.codes) to render. I probably don’t need to keep the lines in the main block in baseof.html, but it’s a nice reference.

Anyhow, tule is technically a Hugo theme now. I wonder if I can even load it via modules?!

1 Like
4

We’ll have our configuration live in it’s own repo: interi/home: interi homepages - allthe.codes

So far I’ve just added a config.yaml with the three default settings (Add config · 5d47e13e81 - allthe.codes):

baseURL: "https://home.interi.org/"
languageCode: "en-us"
title: "interi homepage"

Looking at Configure Hugo | Hugo, there are a whole lotta ways to split this up, but for home I’m gonna keep it simple until I can’t.

For right now, let’s just glance and see if there are any configuration settings that I want to change from their defaults:

  • disableHugoGeneratorInject (false) - oomph, that’s probably not a popular one to set, but I always do. I tell people I use Hugo, I don’t care about a popularity game based on large-scale webscraping.
  • metaDataFormat (“toml”) - I’ve never seen this one. I’d probably choose yaml, if I knew where it mattered; I thought front matter would be generated from archetypes.
  • module - I’ll need to follow the doc at Configure Modules | Hugo. I intend to load nearly everything from another repo, so this may be the bulk of this config/repo.
  • permalinks - Will need to set these up (URL Management | Hugo)
  • taxonomies - huh, hadn’t even thought about what we’d use for taxos. Maybe turn them off for now.

Well, that’s it for now. Those are the only ones I need to worry about at the moment.

I can disable a few things now, but I’ll need to look up more info for modules, won’t decide permalinks until I get a first section of content up, and I need to ask about metaDataFormat.

Here’s what it looks like now (Disable taxonomy and terms · 6de2180383 - allthe.codes):

baseURL: "https://home.interi.org/"
languageCode: "en-us"
title: "interi homepage"

disableHugoGeneratorInject: true
disableKinds:
- taxonomy
- taxonomyTerm
5

A quick answer:

I’ve removed one of two references from the docs. :slight_smile:

6

Okay, Hugo Modules. So, it’s kinda neat, but requires go to be installed, as it uses go modules as the base. An exception is to include all the source in _vendor, but that partially defeats using modules for pulling together a site, both theme components and content.

From using it, figuring out how to nest values in YAML, and getting a site up and running with them I can tell: I won’t be using it on all sites. Maybe not even many. Git submodules for theme components and content (if structured simply) is more than enough for many site profiles.

Fortunately for learning to use Hugo modules, I will be using it on home.interi.org. Why? Because I intend to pull in a bunch of content sources and I will be building the site on a local server and syncing to the server, meaning I can ensure hugo, git, and go are installed. It means to add another section to the site (such as a new person), I can just map out an import in config.yaml and the build with pull it together.

I got a site mostly built by adding the following (https://allthe.codes/interi/home/commit/6eb3fc9d2fff8901419cb0fc6fdc18bde6f457f7):

module:
  imports:
    - path: "allthe.codes/maiki/interi"
      disabled: false
      mounts:
      - source: "maiki"
        target: "content/maiki"
    - path: "allthe.codes/maiki/tule"
      disabled: false

The first path refers to my content repo (https://allthe.codes/maiki/interi) and the second to the theme I’m using (https://allthe.codes/maiki/tule); without a target the repo is loaded into themes.

When I load the test server (hugo server), I see the front page load.

Screenshot_2019-09-07%20interi%20homepage

The sitemap shows a section called maiki:

<url><loc>http://localhost:1313/maiki/</loc></url>

But it gives a 404, while the console reports, found no layout file for "HTML" for "section": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.

Which is to be expected, as I don’t have any other templates aside from index.html and single.html. Now I need a template to render a “section”…

7

I ran into a small side issue where setting theme as an option threw an error. I had seen folks set it in TOML, so I didn’t know if my YAML syntax was incorrect. And then a small correction to a recent tip:

This:

[module]
  [[module.imports]]
    path = "github.com/yihui/hugo-xmin"
  [[module.imports]]
    path = "github.com/yourname/my-shortcodes"

Is the same as:

theme = ["github.com/yihui/hugo-xmin",  "github.com/yourname/my-shortcodes" ]

You don’t need both.

Indeed, setting theme looks for a directory in themes, rather than just loading it from _vendor. We’ll need to update the docs or point that out.

8

Easier said than done, I just copied over single.html (https://allthe.codes/maiki/tule/commit/a7e5b333540ecc12471d199f3b9b3a7ba7f91040).

The first template looked up is layouts/_default/list.html, and for sections layouts/_default/section.html comes next. But I just wanted something to render the page via tule, for now. Normally a list page will, ya know, list something. And if it is a lot of something, perhaps paginate it. When I need that from tule I’ll add it.

As for the “user home page” sections, I haven’t gotten that far. When I add a second interi it will make more sense.