Publish is Live

After life got a table flip last year, finally got back to migrating this site.

Publish Is Live

Last year I was almost done migrating this site. My father took a turn for the worse (and died), so lots of life this past year has been about things other than technical blogs.

Anyhow, this site has been migrated from Jekyll (ruby) to Publish, a static site generator written in Swift.

The theme is from HTML5Up, and I will write about the process of migration, not to mention which parts of migrating that particular theme were challenging and what I learned in the process. I will also release my version of the theme, just not immediately. Now that I have a working copy, I want to pare down an example and create a new repository for that.

After, I may incorporate some of the changes in the Pixelarity version of the theme. and diverge my site further from the free theme.

Publish Theme Development Tips

Since I've just ported the theme I was using in Jekyll to Publish, I thought I'd mention a few tips I have for what makes a theme easier or more difficult to port.

Index and Posts Focused

Publish is very much designed around the paradigm that the site consists of:

  • A front page, which has a different format
  • Other pages, which may be in sections, which have an amorphous format
  • Posts, which may have tags, and are dated (once published)
  • Pages for each tag and a tag index

This basically follows the early WordPress concept of sites (except WordPress used categories instead of tags). So if your site format follows that generally, Publish will be easier to adapt, especially given how few themes are currently available that showcase more complex formats.

In the early days, people mostly used pages to create silos (portions of a website that link within that category, but mimize outside links, as this increases relevance on that one topic, and thus ranking—that was the theory, anyway).

Some Common Formats That Are More Work

One-page themes, especially those with multiple different kinds of feature blocks, each with its own content, are harder to do. The way Jekyll does these is to have the content in each feature block be in a separate Markdown file, then have those render into the feature blocks that comprise the page. Often, there's metadata in front that orders the sections.

Or, the other way Jekyll does it is to load the next block based on {% liquid tags %}, which Publish doesn't support. But that means you can put almost any arbitrary thing dynamically on a page. While that has some cool aspects, it does mean your Markdown gets a lot more complex.

There's always the ugly hack (which I have in fact done)

Tagged with: