Starting to rebuild my site to get off of Jekyll/GitHub pages. I think I have a static site generator that is simple and flexible. Here's how it works: by default it just recurses through a source directory, rendering markdown files into HTML and copying everything else verbatim. If it encounters a static site generation script while recursing though it invokes it instead, allowing for arbitrary custom logic.

For example, certain subpages require custom indexing, like my portfolio projects or my blog. Some subpages should actually clone a totally different repository and run some commands, EG in the case of generated documentation for projects. Coming up with a generic system to cover all these cases is a quagmire, so I'm thinking it's just simple default behavior plus software for customization.

one thing i want to add is a kind of git-integration where you can see past versions of each page. this will come with time though.

@nasser in the precursor to (my static site generator), i used git integration to display creation and edit dates on articles

now i only rely on inline metadata (a yaml chunk) because the git method doesn't differentiate between a content change and a refactor

@gaeel oh interesting! can you elaborate on that? what do you mean by a refactor in the context of a website/blog?

@nasser changes to the file structure or format of the inline metadata, for instance, which mean i have to move the files around or change them in a small way
interpreting any change to a file in the git history as "an update to the article" isn't helpful
the structure and metadata have crystallised now (which is also why i was able to release the generator as a publicly useable tool), and i don't expect to change these in breaking ways any more


@nasser that said, i probably wouldn't use git as a way to track "updates to articles" today either, many updates are typo or link rot fixes, which i don't think warrant a "article updated on <date>" mention

@nasser certainly not in the same way as adding an errata or addendum to an article, for instance

@gaeel hmm thats a level of granularity i never considered, honestly. i feel like i am OK with those? i like the idea of using git to get a "created" date which is fixed to the repository. if you wanted i suppose you could filter the commits based on commit message to filter out insignificant changes. ie commits with [typo] in the message do not contribute to the public "history"

@nasser yeah, that could work

i think i'm focusing more on a files-only system though, having part of the data encoded in files and another part encoded in the vcs complicates things

@gaeel yeah that's totally fair, that makes sense as well. your SSG looks really cool!

Sign in to participate in the conversation

cybrespace: the social hub of the information superhighway jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal support us on patreon or liberapay!